From nobody Tue Jul 1 07:59:35 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23471A05CB for ; Tue, 1 Jul 2014 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fpbwfo4H5Tm for ; Tue, 1 Jul 2014 07:59:32 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42331A0364 for ; Tue, 1 Jul 2014 07:59:31 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so7942642wib.6 for ; Tue, 01 Jul 2014 07:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ly9WDG7avYR9oseCMuvVAQxYRWhgAOKZ0v/aF3++f0U=; b=ZvfrLixQQSf8mqkA4VXDbihw+A9KTwnmktHt4keKprvrqIpxLxF9vbtwZ3eKZk8Mlu pNDo7jt8xpLNIOE8rMs7CY6evKmNq0mJHlvah7FaGHQs2E4JF0L4tuUPyKui39crmcZo Pl7lq7i2PrGKpiU81tLEPmWaBgzI2Jxhc3vr2MB0BE5SckCZhXAemKqzt6AINm1UQawB u7WTW5wDLwOuB9WbWDFaigNiQiNcYMfB0Zuxh4/tUR6KQJsXwwACFbol3d3WSiGTXWFD b8ncOICeSGKF7IC9pXxdCl+fgIrBXipT45FlVr48yDIP6uSyTb3sHl5ld98//iV5LMYV n6AQ== MIME-Version: 1.0 X-Received: by 10.194.7.167 with SMTP id k7mr51240153wja.11.1404226769813; Tue, 01 Jul 2014 07:59:29 -0700 (PDT) Received: by 10.216.139.132 with HTTP; Tue, 1 Jul 2014 07:59:29 -0700 (PDT) Date: Tue, 1 Jul 2014 10:59:29 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: aretana@cisco.com Content-Type: multipart/alternative; boundary=047d7b5d2f70cc87a604fd23058c Archived-At: http://mailarchive.ietf.org/arch/msg/spring/hS0jIjsb3yrAqM7tjhO1-9RrGwE Cc: spring@ietf.org Subject: [spring] Re.: SPRING OpenFlow interworking discussion X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 14:59:34 -0000 --047d7b5d2f70cc87a604fd23058c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Alvaro, Would there be any opportunity to discuss SPRING OpenFlow interworking during the Toronto (IETF-90) mtg.? It may be useful to include a statement like the following sentence in Sec. 6 (Interoperability with non-SPRING nodes) of the SPRING problem statement draft (draft-ietf-spring-problem-statement-01.txt). "Interoperability with openFlow (https://www.opennetworking.org/sdn -resources/onf-specifications/openflow) based non-SPRING nodes will be discussed in a future document." Many thanks in advance. Best. Bhumip Bhumip Khasnabish =E2=80=8B++++++++++++++++++++++++++++++++++++++++++++++++ [spring] I-D Action: draft-ietf-spring-problem-statement-01.txt ------------------------------ - *From*: internet-drafts at ietf.org - *To*: i-d-announce at ietf.org - *Cc*: spring at ietf.org - *Date*: Thu, 26 Jun 2014 06:09:12 -0700 - *List-id*: "Stacked Tunnels for Source Routing \(STATUS\)." > ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : SPRING Problem Statement and Requirements Authors : Stefano Previdi Clarence Filsfils Bruno Decraene Stephane Litkowski Martin Horneffer Ruediger Geib Rob Shakir Robert Raszuk Filename : draft-ietf-spring-problem-statement-01.txt Pages : 18 Date : 2014-06-26 Abstract: The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed'. This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ There's also a htmlized version available at:http://tools.ietf.org/html/draft-ietf-spring-problem-statement-01 A diff from the previous version is available at:http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-problem-statement-0= 1 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ --047d7b5d2f70cc87a604fd23058c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Alvaro,

Would there be any oppor= tunity to discuss
SPRING OpenFlow interworking during the Tor= onto (IETF-90) mtg.?=C2=A0

It may be useful to include a statement like
the following sent= ence in Sec. 6 (Interoperability with non-SPRING nodes) of the SPRING probl= em
statement draft (draft-ietf-spring-problem-statement-01.= txt).
=C2=A0
"Interoperability with openFlow (https://www.opennetworking.org/sdn-resources/onf-specifications/= openflow) based non-SPRING nodes will be discussed=C2=A0 in a future= document."

=C2=A0
Many thanks in advance.

Best.
=C2=A0
Bhumip=C2=A0=C2=A0

Bhumip Khasnabish
=C2=A0
=E2=80=8B+++++++++++++++++++++= +++++++++++++++++++++++++++

[spring] I-D Action: draft-ietf-spring-problem-statement-0= 1.txt

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
 This draft is a work item of the Source Packet Routing in Networking Worki=
ng Group of the IETF.

        Title           : SPRING Problem Statement and Requirements
        Authors         : Stefano Previdi
                          Clarence Filsfils
                          Bruno Decraene
                          Stephane Litkowski
                          Martin Horneffer
                          Ruediger Geib
                          Rob Shakir
                          Robert Raszuk
	Filename        : draft-ietf-spring-problem-stat=
ement-01.txt
	Pages           : 18
	Date            : 2014-06-26

Abstract:
   The ability for a node to specify a forwarding path, other than the
   normal shortest path, that a particular packet will traverse,
   benefits a number of network functions.  Source-based routing
   mechanisms have previously been specified for network protocols, but
   have not seen widespread adoption.  In this context, the term
   'source' means 'the point at which the explicit route is imp=
osed'.

   This document outlines various use cases, with their requirements,
   that need to be taken into account by the Source Packet Routing in
   Networking (SPRING) architecture for unicast traffic.  Multicast use-
   cases and requirements are out of scope of this document.



The IETF datatracker status page for this draft i=
s:
https://<=
span>datatracker.ietf.org/doc/draft-ietf-s=
pring-problem-statement/

There's also a htmlized version available at:
http://tools.=
ietf.org/html/draft-ietf-spring-problem-statement=
-01

A diff from the previous version is available at:
http:=
//www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-problem-statement-01


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/inter=
net-drafts/
--047d7b5d2f70cc87a604fd23058c-- From nobody Tue Jul 1 10:47:54 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000741A03A1 for ; Tue, 1 Jul 2014 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrJWh-_TPsyK for ; Tue, 1 Jul 2014 10:47:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735111A03B7 for ; Tue, 1 Jul 2014 10:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4360; q=dns/txt; s=iport; t=1404236870; x=1405446470; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ALAWZtsCmTydJQYyUf73d0vmMndXi9uE6k6SHWD2qVo=; b=FXVBIb6ZUor1oD57unrMiLVXDZ35wCDGm/irR/NMc+uriFwHjRosdj6k TezXVLeR4elJMWyeTJbFlYwxq2IfkQRVIy4h1W5dIwYLdLuwSAzbte4e+ u+bgIz6PSOyFNldTL/6NtqfQpXbq2wMc3f0rfBs6u/fVgDGVQ8q7CUNw0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAKXzslOtJV2U/2dsb2JhbABagkZHUlqrNwUBbplbAYENFnWEBAEBBHkQAgEIBDsHIREUEQIEDgWHZEoDEQ3CSg2GJRMEhW+HCR2CBgQHhEMFmGiBfo1xhhKDQoIw X-IronPort-AV: E=Sophos; i="5.01,583,1400025600"; d="scan'208,217"; a="57512565" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 01 Jul 2014 17:47:49 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s61HlnfE018268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 17:47:49 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.198]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 1 Jul 2014 12:47:49 -0500 From: "Alvaro Retana (aretana)" To: "B.Khasnabish@ieee.org" Thread-Topic: Re.: SPRING OpenFlow interworking discussion Thread-Index: AQHPlT0RUqEAqzw5fki9LzvjpppfR5uLj2yA Date: Tue, 1 Jul 2014 17:47:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_CFD86B435DE67aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/uL9Mer1C1eAVZryYEVnTULXiROE Cc: "spring@ietf.org" Subject: Re: [spring] Re.: SPRING OpenFlow interworking discussion X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 17:47:52 -0000 --_000_CFD86B435DE67aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 7/1/14 10:59 AM, "B.Khasnabish@ieee.org" <= vumip1@gmail.com> wrote: Bhumip: Hi! How are you? Would there be any opportunity to discuss SPRING OpenFlow interworking during the Toronto (IETF-90) mtg.? If you're asking about time in the meeting..then then answer might be "yes"= if there is a published draft to discuss and time in the agenda. So far w= e haven't ironed out the whole agenda. It may be useful to include a statement like the following sentence in Sec. 6 (Interoperability with non-SPRING nodes) o= f the SPRING problem statement draft (draft-ietf-spring-problem-statement-01.txt). "Interoperability with openFlow (https://www.opennetworking.org/sdn-resourc= es/onf-specifications/openflow) based non-SPRING nodes will be discussed i= n a future document." I'll let the authors of that draft comment..but this is a good time to put = use cases forward. Best regards! Alvaro. --_000_CFD86B435DE67aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <564230F71520FB42B2C2FEA616034061@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 7/1/14 10:59 AM, "B.K= hasnabish@ieee.org" <vumip1= @gmail.com> wrote:

Bhumip:

Hi!  How are you?

Would there be any opportunity to discuss
SPRING OpenFlow interworking during the Toronto (I= ETF-90) mtg.? 

If you're asking about time in the meeting..then then answer might be = "yes" if there is a published draft to discuss and time in the ag= enda.  So far we haven't ironed out the whole agenda.

It may be useful to include a statement like
the following sentence in Sec. 6 (Interoperability with non-SPRING no= des) of the SPRING problem
statement draft (draft-ietf-spring-problem-statement-01.= txt).
 
"Interoperability with openFlow (https://ww= w.opennetworking.org/sdn-resources/onf<= /span>-specifications/openflow) based non-SPRING nodes will be= discussed  in a future document."

I'll let the authors of that draft comment..but this is a good time to= put use cases forward.

Best regards!

Alvaro.
--_000_CFD86B435DE67aretanaciscocom_-- From nobody Wed Jul 2 07:15:23 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6A51A0146 for ; Wed, 2 Jul 2014 07:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFT9rqLsXKAd for ; Wed, 2 Jul 2014 07:15:15 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933B01A0126 for ; Wed, 2 Jul 2014 07:15:14 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jul 2014 16:15:12 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 2 Jul 2014 16:15:12 +0200 From: To: Date: Wed, 2 Jul 2014 16:15:11 +0200 Thread-Topic: New Version Notification for draft-geib-spring-oam-usecase-02.txt Thread-Index: Ac+V/5LrcSb58uMSQTy0ac0YBTLYNAAAAjuA Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Q2JygsSiOH7hRt-JA7Ovmto7LGA Cc: spring@ietf.org Subject: [spring] WG: New Version Notification for draft-geib-spring-oam-usecase-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 14:15:19 -0000 SGkgQWx2YXJvLA0KDQpwbGVhc2UgZmluZCBiZWxvdyB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIE9B TSB1c2UgY2FzZS4gVGhlcmUgaGFzIGJlZW4gbm8gY29tcGxldGVseSBuZXcgaW5wdXQuIA0KDQpJ J2QgbGlrZSB0byByZXF1ZXN0IFdHIHN0YXR1cyBmb3IgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkcmFm dC4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBO YWNocmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAyLiBKdWxpIDIwMTQg MTY6MTINCkFuOiBOYWdlbmRyYSBLdW1hcjsgR2VpYiwgUsO8ZGlnZXI7IE5hZ2VuZHJhIEt1bWFy OyBHZWliLCBSw7xkaWdlcjsgQ2FybG9zIFBpZ25hdGFybzsgQ2xhcmVuY2UgRmlsc2ZpbHM7IENh cmxvcyBQaWduYXRhcm87IENsYXJlbmNlIEZpbHNmaWxzDQpCZXRyZWZmOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlLTAyLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZS0wMi50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUnVlZGlnZXIgR2VpYiBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1nZWliLXNwcmlu Zy1vYW0tdXNlY2FzZQ0KUmV2aXNpb246CTAyDQpUaXRsZToJCVVzZSBjYXNlIGZvciBhIHNjYWxh YmxlIGFuZCB0b3BvbG9neSBhd2FyZSBNUExTIGRhdGEgcGxhbmUgbW9uaXRvcmluZyBzeXN0ZW0N CkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDINCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpQYWdlczoJCTEyDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UtMDIudHh0DQpTdGF0dXM6ICAg ICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VpYi1zcHJpbmct b2FtLXVzZWNhc2UvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UtMDINCkRpZmY6ICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZS0w Mg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGZlYXR1cmVzIGFuZCBh IHVzZSBjYXNlIG9mIGEgcGF0aCBtb25pdG9yaW5nDQogICBzeXN0ZW0uICBTZWdtZW50IGJhc2Vk IHJvdXRpbmcgZW5hYmxlcyBhIHNjYWxhYmxlIGFuZCBzaW1wbGUgbWV0aG9kDQogICB0byBtb25p dG9yIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcyBvZiB0aGUgY29tcGxldGUgc2V0IG9mIHBhdGhzDQog ICBiZWxvbmdpbmcgdG8gYSBzaW5nbGUgZG9tYWluLiAgQ29tcGFyZWQgd2l0aCBsZWdhY3kgTVBM UyBwaW5nIGFuZA0KICAgcGF0aCB0cmFjZSwgTVBMUyB0b3BvbG9neSBhd2FyZW5lc3MgcmVkdWNl cyBtYW5hZ2VtZW50IGFuZCBjb250cm9sDQogICBwbGFuZSBpbnZvbHZlbWVudCBvZiBPQU0gbWVh c3VyZW1lbnRzIHdoaWxlIGVuYWJsaW5nIG5ldyBPQU0NCiAgIGZlYXR1cmVzLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Jul 3 07:55:23 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BED1A0193 for ; Thu, 3 Jul 2014 07:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxe49dd1Zqxj for ; Thu, 3 Jul 2014 07:55:09 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DE61A0103 for ; Thu, 3 Jul 2014 07:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2224; q=dns/txt; s=iport; t=1404399309; x=1405608909; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=P1452P6JLmygLQV1+eGrPnVg3gqnuAeGSNJthjWo2vU=; b=g8m6+R1K0kveQhLREf+WLiOoc1ctmqHLsoyR2ubqSmT6bAv5GpXomHlJ DPACRpSesPpd2jdLZuxmB7Uk7lW4f05KnkWzG6dXxCgUtnY2ss1w7Ay7B PaZXSHxGt0gQY4pYrTmbjMQvcuKHCrI2vyhP5xsILDGtfXkwKilglLe/l s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkKAGxttVOtJV2U/2dsb2JhbABagw1SUwerMAwBAgEBAQUBAmwBmWaBChZ1hAMBAQEDATo9BwsCARkDAQIfEDIbAggCBBMJiDEICAXJIBeFcIk/gyeBFgWabYFIkkKCAYFCbIFE X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="58034917" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 03 Jul 2014 14:55:08 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s63Et8x1013387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jul 2014 14:55:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:55:08 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-previdi-6man-segment-routing-header-02.txt Thread-Index: AQHPlsX72yWpCzKt70OMlz5WTeSFrw== Date: Thu, 3 Jul 2014 14:55:07 +0000 Message-ID: <779A0EA4-6954-45B7-838F-1C01A5FA1C90@cisco.com> References: <20140703135025.18040.62470.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.207.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <878A4E03D0190C4C8BEB2036EEF62FCE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Vnq0XQAiDZxtLcusgHE-qd58JDI Subject: [spring] Fwd: New Version Notification for draft-previdi-6man-segment-routing-header-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:55:13 -0000 Begin forwarded message: > From: > Subject: New Version Notification for draft-previdi-6man-segment-routing-= header-02.txt > Date: July 3, 2014 3:50:25 PM GMT+02:00 > To: Stefano Previdi , Ida Leung , Brian Field , Clarence Filsfils , Stefano Previdi , Ida Leung , Brian Field , Clarence Fil= sfils >=20 >=20 > A new version of I-D, draft-previdi-6man-segment-routing-header-02.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-previdi-6man-segment-routing-header > Revision: 02 > Title: IPv6 Segment Routing Header (SRH) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-previdi-6man-se= gment-routing-header-02.txt > Status: https://datatracker.ietf.org/doc/draft-previdi-6man-segme= nt-routing-header/ > Htmlized: http://tools.ietf.org/html/draft-previdi-6man-segment-rou= ting-header-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-previdi-6man-seg= ment-routing-header-02 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending a SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > describes the Segment Routing Extension Header Type and how it is > used by SR capable nodes. >=20 >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Thu Jul 3 07:55:24 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F81A0193 for ; Thu, 3 Jul 2014 07:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONs6X3AknWQV for ; Thu, 3 Jul 2014 07:55:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1291A0194 for ; Thu, 3 Jul 2014 07:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2197; q=dns/txt; s=iport; t=1404399313; x=1405608913; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=/uwVgJKDsF94XOweD1+7MkpHdfAOtXH56CoX+09EbMc=; b=eIQAg+wSua93OlqL6OpuYyXKy2Xq1cfwRx/zSi0YNws882Nf5WkcQdj2 VjtVlCNnBArykVsNB/Q95Usz+nkSkpbmpPWbxalVs6SGKcHSQ3EG11xdU mGx2OhjsPP1N+S0tlm1EAMpndPmg3m/mjmTivqMl598nE37fOpGUQJ/dM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHABxutVOtJA2G/2dsb2JhbABagw1SWqswDAECAQEBBQECbAGZZoEKFnWEAwEBAQMBOj0HCwIBGQMBAh8QMhsCCAIEEwmIMQgNySEXhXCJP4MngRYFmm2BSJJCggGBQmyBRA X-IronPort-AV: E=Sophos;i="5.01,595,1400025600"; d="scan'208";a="337575857" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2014 14:54:57 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s63Esv2R006730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jul 2014 14:54:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 3 Jul 2014 09:54:57 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt Thread-Index: AQHPlsVPZVl9C4Wq3k2v4OyZldAypg== Date: Thu, 3 Jul 2014 14:54:56 +0000 Message-ID: <0AC25DD6-050F-46FC-883C-1F68DECFF3DC@cisco.com> References: <20140703134709.19452.24677.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.207.174] Content-Type: text/plain; charset="us-ascii" Content-ID: <0731DF15F07CFC43B607B0DA370D19B2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ej7Vj0ZvfldPFfV5PoyPQ653z6I Subject: [spring] Fwd: New Version Notification for draft-vyncke-6man-segment-routing-security-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:55:18 -0000 Begin forwarded message: > From: > Subject: New Version Notification for draft-vyncke-6man-segment-routing-s= ecurity-00.txt > Date: July 3, 2014 3:47:09 PM GMT+02:00 > To: Eric Vyncke , Ida Leung = , Brian Field , Stefano Previdi , Eric Vyncke , Stefano Previdi , Brian Field , Ida Leung >=20 >=20 > A new version of I-D, draft-vyncke-6man-segment-routing-security-00.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-vyncke-6man-segment-routing-security > Revision: 00 > Title: IPv6 Segment Routing Header (SRH) Security Considerations > Document date: 2014-07-03 > Group: Individual Submission > Pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-vyncke-6man-seg= ment-routing-security-00.txt > Status: https://datatracker.ietf.org/doc/draft-vyncke-6man-segmen= t-routing-security/ > Htmlized: http://tools.ietf.org/html/draft-vyncke-6man-segment-rout= ing-security-00 >=20 >=20 > Abstract: > Segment Routing (SR) allows a node to steer a packet through a > controlled set of instructions, called segments, by prepending a SR > header to the packet. A segment can represent any instruction, > topological or service-based. SR allows to enforce a flow through > any path (topological, or application/service based) while > maintaining per-flow state only at the ingress node to the SR domain. >=20 > Segment Routing can be applied to the IPv6 data plane with the > addition of a new type of Routing Extension Header. This draft > analyses the security aspects the Segment Routing Extension Header > Type and how it is used by SR capable nodes to deliver a secure > service. >=20 >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Thu Jul 3 08:22:57 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154F1A0290; Thu, 3 Jul 2014 08:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANbDzTUkSHHw; Thu, 3 Jul 2014 08:22:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC541A004B; Thu, 3 Jul 2014 08:22:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703152251.22827.50489.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 08:22:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/8Q1Up-eo69ejGXy-ZdkgUAaxz-U Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 15:22:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Ida Leung Stefano Previdi Mark Townsley Christian Martin Clarence Filsfils Roberta Maglione Filename : draft-ietf-spring-ipv6-use-cases-01.txt Pages : 13 Date : 2014-07-03 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 20:12:23 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6211A8BB6 for ; Thu, 3 Jul 2014 20:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w3NDjrJ163x for ; Thu, 3 Jul 2014 20:12:18 -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 A68A11A8BB2 for ; Thu, 3 Jul 2014 20:12:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT89277; Fri, 04 Jul 2014 03:12:15 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 04:12:14 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 11:12:07 +0800 From: Xuxiaohu To: "" Thread-Topic: The rationale of draft-xu-spring-islands-connection-over-ip Thread-Index: Ac+XNbvwgjeJ7UQ5TYug+cTuo+tEeQ== Date: Fri, 4 Jul 2014 03:12:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290298@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/YBf49tNZ7wGRUa74uYi81y7q3TA Subject: [spring] The rationale of draft-xu-spring-islands-connection-over-ip X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:12:20 -0000 Hi all, This draft (http://tools.ietf.org/html/draft-xu-spring-islands-connection-o= ver-ip-00) describes a use case about interconnecting spring islands over I= P networks. The rationale for this draft is as follows:=20 Suppose LSR A and LSR B are separated by an IP network. Assume LSR A receiv= es from LSR B a label binding L for a given FEC (e.g., one of LSR B's loopb= ack addresses) via T-LDP or L-BGP, when LSR A wants to forward a MPLS packe= t targeted for that FEC, it could forward that MPLS packet through an IP-ba= sed tunnel towards LSR B. In contrast, if LSR A receives the above label bi= nding originated by LSR B via IS-IS or OSPF, it could be looked as if this = label binding was learnt from a remote BGP or LDP peer. As such, LSR A coul= d forward the MPLS packet targeted for that FEC over an IP-based tunnel tow= ards LSR B as well. In fact, one of the claimed advantages of IPv6-SR is that it doesn't requir= e to upgrade all routers in the networks. With the above approach, we can a= chieve the same effect in the MPLS-SR.=20 Best regards, Xiaohu From nobody Thu Jul 3 23:55:07 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920F21B2C1D for ; Thu, 3 Jul 2014 23:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLtHk4zFKIBk for ; Thu, 3 Jul 2014 23:54:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCED61B2BDC for ; Thu, 3 Jul 2014 23:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1404456892; x=1405666492; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=SFZOiBkiqa318+K5jh6awv9VDNNGMpEcNZn2KN2Kt5c=; b=ZdtJSv3cOtl3U5WUFsSscNvVx8lx8oDx8GS4JtaW2uN/i7Q9urTxySyU nUf8X5ud4ICtN5qz6e5v3ujI+yfbLGwTlxZZNL4L3iJVFkS7jtKIV+0yl st5HvxZHnF+5AObFC8NhIWQETEKci+CMlqB6HvC0QWkW7YNjPAxHOuUeu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN9OtlOtJV2d/2dsb2JhbABagw1SWsYmgQsWdYQDAQEBAwE6PQcLAgEZAQIBAh8QMhcEAggCBBMJEogfCA3JaxePL4MngRYFmnaBSJJEggGBQmyBRA X-IronPort-AV: E=Sophos;i="5.01,599,1400025600"; d="scan'208";a="58281601" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 04 Jul 2014 06:54:52 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s646sqfR001039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 06:54:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.27]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 01:54:51 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-segment-routing-central-epe-02.txt Thread-Index: AQHPl1P17Tc3ap22wk2sH1GMe9iSUQ== Date: Fri, 4 Jul 2014 06:54:51 +0000 Message-ID: References: <20140704064823.1019.76861.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.95.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DA7BFEE942CAB48BC5043906D417DC9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/-YSPblOJdgOLV3hXwUdxdGkvbGw Subject: [spring] Fwd: New Version Notification for draft-filsfils-spring-segment-routing-central-epe-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:55:02 -0000 All, This is the Segment Routing Egress Peer Engineering draft. Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-filsfils-spring-segment-routi= ng-central-epe-02.txt > Date: July 4, 2014 8:48:23 AM GMT+02:00 > To: Stefano Previdi , "shaw@fb.com" , "S= teve Shaw" , Dmitry Afanasiev , Ebben Ari= es , Dmitry Afanasiev , Clarence Filsfils = , Daniel Ginsburg , Keyur Patel , Stefano Previdi , Keyur Patel , Clarence Filsfils , Ebben Aries , Daniel Ginsburg >=20 >=20 > A new version of I-D, draft-filsfils-spring-segment-routing-central-epe-0= 2.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-filsfils-spring-segment-routing-central-epe > Revision: 02 > Title: Segment Routing Centralized Egress Peer Engineering > Document date: 2014-07-04 > Group: Individual Submission > Pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-filsfils-spring= -segment-routing-central-epe-02.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-se= gment-routing-central-epe/ > Htmlized: http://tools.ietf.org/html/draft-filsfils-spring-segment-= routing-central-epe-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-filsfils-spring-= segment-routing-central-epe-02 >=20 > Abstract: > Segment Routing (SR) leverages source routing. A node steers a > packet through a controlled set of instructions, called segments, by > prepending the packet with an SR header. A segment can represent any > instruction topological or service-based. SR allows to enforce a > flow through any topological path and service chain while maintaining > per-flow state only at the ingress node of the SR domain. >=20 > The Segment Routing architecture can be directly applied to the MPLS > dataplane with no change on the forwarding plane. It requires minor > extension to the existing link-state routing protocols. >=20 > This document illustrates the application of Segment Routing to solve > the Egress Peer Engineering (EPE) requirement. The SR-based EPE > solution allows a centralized (SDN) controller to program any egress > peer policy at ingress border routers or at hosts within the domain. > This document is on the informational track. >=20 >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Fri Jul 4 02:28:44 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253A41B2CAE for ; Fri, 4 Jul 2014 02:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AshyirJtXTpV for ; Fri, 4 Jul 2014 02:28:42 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A61B2CAC for ; Fri, 4 Jul 2014 02:28:42 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rl12so1386124iec.0 for ; Fri, 04 Jul 2014 02:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wool3QaXZAilHePHVQCiJQXw3WZfLfO8MMgjAN5T8rk=; b=ft4eqMXQT8ChoU0oKt8KQWjA3aA7eOlS3scfO5+AkqDVrUwgDOX4iMTuY0yntJwT0L oVtFF7n3UYHq+KVBh5wLSIrSv3zKoQ0VTUpSsYpYLhK6o62nWILGLwrwGvacP9nKUyq0 CcqHKFyzcb8AbrMA22qaF0t7dyHkwLqL+eaSKuNFXz4o0kOXFCbVXROpM9SyspuPBEOK jn0eXhKAE7TAGHYkGk6JNOFrUmGKZO9kY9JWheeRob9ewzlTlpJjBiHvy1q787RJ453k Lp+2vHQ5xZA3OIABlrVBdRKh492d3tOb87czI+ePMNsVP8jHb+fY/wK30CCxKUHlhL2q E8Cg== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr17877590igb.21.1404466121587; Fri, 04 Jul 2014 02:28:41 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 4 Jul 2014 02:28:41 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290298@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290298@NKGEML512-MBS.china.huawei.com> Date: Fri, 4 Jul 2014 11:28:41 +0200 X-Google-Sender-Auth: ZPZB3wLHAtbZCv1489ooLbS17yk Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/spring/NjgZG2LgaUvIwHIV2Nqai1KrPq8 Cc: "" Subject: Re: [spring] The rationale of draft-xu-spring-islands-connection-over-ip X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:28:43 -0000 Hi Xu, We discussed this work before, however I have a new question ... It is an informational draft so you relay on proper configuration of RS nodes in the islands. Note that today you may have out of the box SR node supporting IPv4, IPv6 (say without SR) + MPLS. So you must select your operational default encapsulation and very likely such encapsulation will differ per next SR destination ! I therefor find it not really practical to recommend manual/i2rs/xml configuration and choice of encapsulation on a per SR node basis. I would therefor advise if there would be architectural consensus to go forward with the proposed in the draft idea to turn it into standards track and add a flag and encap info in SR advertisement itself indicating that given SR node may be reachable say via GRE, L2TPv3 or VXLAN encaps. That way your objective is accomplished via full protocol automation with minimal need for any per SR src/dst node manual config. Best, R. On Fri, Jul 4, 2014 at 5:12 AM, Xuxiaohu wrote: > Hi all, > > This draft (http://tools.ietf.org/html/draft-xu-spring-islands-connection= -over-ip-00) describes a use case about interconnecting spring islands over= IP networks. The rationale for this draft is as follows: > > Suppose LSR A and LSR B are separated by an IP network. Assume LSR A rece= ives from LSR B a label binding L for a given FEC (e.g., one of LSR B's loo= pback addresses) via T-LDP or L-BGP, when LSR A wants to forward a MPLS pac= ket targeted for that FEC, it could forward that MPLS packet through an IP-= based tunnel towards LSR B. In contrast, if LSR A receives the above label = binding originated by LSR B via IS-IS or OSPF, it could be looked as if thi= s label binding was learnt from a remote BGP or LDP peer. As such, LSR A co= uld forward the MPLS packet targeted for that FEC over an IP-based tunnel t= owards LSR B as well. > > In fact, one of the claimed advantages of IPv6-SR is that it doesn't requ= ire to upgrade all routers in the networks. With the above approach, we can= achieve the same effect in the MPLS-SR. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Fri Jul 4 02:47:25 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2F51B2CBC for ; Fri, 4 Jul 2014 02:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o0cwukmc2fY for ; Fri, 4 Jul 2014 02:47:22 -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 8F66A1B2C9C for ; Fri, 4 Jul 2014 02:47:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJP93496; Fri, 04 Jul 2014 09:47:20 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 10:47:19 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 17:47:15 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [spring] The rationale of draft-xu-spring-islands-connection-over-ip Thread-Index: Ac+XNbvwgjeJ7UQ5TYug+cTuo+tEef//4xuA//93EQA= Date: Fri, 4 Jul 2014 09:47:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082903CA@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08290298@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/OM6wIuePcO7ltojJcW-zxc-h9XY Cc: "" Subject: Re: [spring] The rationale of draft-xu-spring-islands-connection-over-ip X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:47:23 -0000 SGkgUm9iZXJ0LA0KDQpZb3VyIHN1Z2dlc3Rpb24gbG9va3MgZ29vZCB0byBtZS4gSW4gZmFjdCwg dGhlIGVuY2Fwc3VsYXRpb24gY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IHBhcnQgKGkuZS4sIHVz aW5nIGEgbmV3IHN1Yi1UTFYgb2YgdGhlIElTSVMgY2FwYWJpbGl0eSBUTFYgKSB3YXMgcHJldmlv dXNseSBjb250YWluZWQgaW4gdGhlIG9yaWdpbmFsIGRyYWZ0IGJ1dCBoYXMgYmVlbiByZW1vdmVk IGJlZm9yZSBzdWJtaXR0aW5nIGl0IHRvIHRoZSBJRVRGIGFzIGFuIGluZm9ybWF0aW9uYWwgZHJh ZnQuIEkgaGFkIHBsYW5uZWQgdG8gc3VibWl0IGFub3RoZXIgZHJhZnQgdGFsa2luZyBhYm91dCB0 aGUgZW5jYXBzdWxhdGlvbiBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQgb25jZSB0aGlzIHVzZSBj YXNlIGRyYWZ0IGlzIGFjY2VwdGVkLiBJZiB0aGUgV0cgY29uc2Vuc3VzIGlzIHRvIGNvdmVyIHRo ZXNlIHR3byBwYXJ0cyBpbiBvbmUgZG9jLCBpdCdzIGZpbmUgdG8gbWUuDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnJhc3p1a0Bn bWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBS YXN6dWsNClNlbnQ6IEZyaWRheSwgSnVseSAwNCwgMjAxNCA1OjI5IFBNDQpUbzogWHV4aWFvaHUN CkNjOiA8c3ByaW5nQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFRoZSByYXRpb25h bGUgb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwDQoNCkhpIFh1 LA0KDQpXZSBkaXNjdXNzZWQgdGhpcyB3b3JrIGJlZm9yZSwgaG93ZXZlciBJIGhhdmUgYSBuZXcg cXVlc3Rpb24gLi4uDQoNCkl0IGlzIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgc28geW91IHJlbGF5 IG9uIHByb3BlciBjb25maWd1cmF0aW9uIG9mIFJTIG5vZGVzIGluIHRoZSBpc2xhbmRzLg0KDQpO b3RlIHRoYXQgdG9kYXkgeW91IG1heSBoYXZlIG91dCBvZiB0aGUgYm94IFNSIG5vZGUgc3VwcG9y dGluZyBJUHY0LA0KSVB2NiAoc2F5IHdpdGhvdXQgU1IpICsgTVBMUy4gU28geW91IG11c3Qgc2Vs ZWN0IHlvdXIgb3BlcmF0aW9uYWwgZGVmYXVsdCBlbmNhcHN1bGF0aW9uIGFuZCB2ZXJ5IGxpa2Vs eSBzdWNoIGVuY2Fwc3VsYXRpb24gd2lsbCBkaWZmZXIgcGVyIG5leHQgU1IgZGVzdGluYXRpb24g IQ0KDQpJIHRoZXJlZm9yIGZpbmQgaXQgbm90IHJlYWxseSBwcmFjdGljYWwgdG8gcmVjb21tZW5k IG1hbnVhbC9pMnJzL3htbCBjb25maWd1cmF0aW9uIGFuZCBjaG9pY2Ugb2YgZW5jYXBzdWxhdGlv biBvbiBhIHBlciBTUiBub2RlIGJhc2lzLg0KDQpJIHdvdWxkIHRoZXJlZm9yIGFkdmlzZSBpZiB0 aGVyZSB3b3VsZCBiZSBhcmNoaXRlY3R1cmFsIGNvbnNlbnN1cyB0byBnbyBmb3J3YXJkIHdpdGgg dGhlIHByb3Bvc2VkIGluIHRoZSBkcmFmdCBpZGVhIHRvIHR1cm4gaXQgaW50byBzdGFuZGFyZHMg dHJhY2sgYW5kIGFkZCBhIGZsYWcgYW5kIGVuY2FwIGluZm8gaW4gU1IgYWR2ZXJ0aXNlbWVudCBp dHNlbGYgaW5kaWNhdGluZyB0aGF0IGdpdmVuIFNSIG5vZGUgbWF5IGJlIHJlYWNoYWJsZSBzYXkg dmlhIEdSRSwNCkwyVFB2MyBvciBWWExBTiBlbmNhcHMuDQoNClRoYXQgd2F5IHlvdXIgb2JqZWN0 aXZlIGlzIGFjY29tcGxpc2hlZCB2aWEgZnVsbCBwcm90b2NvbCBhdXRvbWF0aW9uIHdpdGggbWlu aW1hbCBuZWVkIGZvciBhbnkgcGVyIFNSIHNyYy9kc3Qgbm9kZSBtYW51YWwgY29uZmlnLg0KDQpC ZXN0LA0KUi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBGcmksIEp1bCA0LCAyMDE0IGF0IDU6 MTIgQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gSGkgYWxsLA0K Pg0KPiBUaGlzIGRyYWZ0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zcHJp bmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDApIGRlc2NyaWJlcyBhIHVzZSBjYXNlIGFi b3V0IGludGVyY29ubmVjdGluZyBzcHJpbmcgaXNsYW5kcyBvdmVyIElQIG5ldHdvcmtzLiBUaGUg cmF0aW9uYWxlIGZvciB0aGlzIGRyYWZ0IGlzIGFzIGZvbGxvd3M6DQo+DQo+IFN1cHBvc2UgTFNS IEEgYW5kIExTUiBCIGFyZSBzZXBhcmF0ZWQgYnkgYW4gSVAgbmV0d29yay4gQXNzdW1lIExTUiBB IHJlY2VpdmVzIGZyb20gTFNSIEIgYSBsYWJlbCBiaW5kaW5nIEwgZm9yIGEgZ2l2ZW4gRkVDIChl LmcuLCBvbmUgb2YgTFNSIEIncyBsb29wYmFjayBhZGRyZXNzZXMpIHZpYSBULUxEUCBvciBMLUJH UCwgd2hlbiBMU1IgQSB3YW50cyB0byBmb3J3YXJkIGEgTVBMUyBwYWNrZXQgdGFyZ2V0ZWQgZm9y IHRoYXQgRkVDLCBpdCBjb3VsZCBmb3J3YXJkIHRoYXQgTVBMUyBwYWNrZXQgdGhyb3VnaCBhbiBJ UC1iYXNlZCB0dW5uZWwgdG93YXJkcyBMU1IgQi4gSW4gY29udHJhc3QsIGlmIExTUiBBIHJlY2Vp dmVzIHRoZSBhYm92ZSBsYWJlbCBiaW5kaW5nIG9yaWdpbmF0ZWQgYnkgTFNSIEIgdmlhIElTLUlT IG9yIE9TUEYsIGl0IGNvdWxkIGJlIGxvb2tlZCBhcyBpZiB0aGlzIGxhYmVsIGJpbmRpbmcgd2Fz IGxlYXJudCBmcm9tIGEgcmVtb3RlIEJHUCBvciBMRFAgcGVlci4gQXMgc3VjaCwgTFNSIEEgY291 bGQgZm9yd2FyZCB0aGUgTVBMUyBwYWNrZXQgdGFyZ2V0ZWQgZm9yIHRoYXQgRkVDIG92ZXIgYW4g SVAtYmFzZWQgdHVubmVsIHRvd2FyZHMgTFNSIEIgYXMgd2VsbC4NCj4NCj4gSW4gZmFjdCwgb25l IG9mIHRoZSBjbGFpbWVkIGFkdmFudGFnZXMgb2YgSVB2Ni1TUiBpcyB0aGF0IGl0IGRvZXNuJ3Qg cmVxdWlyZSB0byB1cGdyYWRlIGFsbCByb3V0ZXJzIGluIHRoZSBuZXR3b3Jrcy4gV2l0aCB0aGUg YWJvdmUgYXBwcm9hY2gsIHdlIGNhbiBhY2hpZXZlIHRoZSBzYW1lIGVmZmVjdCBpbiB0aGUgTVBM Uy1TUi4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0K PiBzcHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmcNCg== From nobody Sat Jul 5 06:16:12 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0871A063D for ; Sat, 5 Jul 2014 06:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZk0rFD6LsVT for ; Sat, 5 Jul 2014 06:16:10 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E85D1A0601 for ; Sat, 5 Jul 2014 06:16:09 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so2574970wgg.29 for ; Sat, 05 Jul 2014 06:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XqA/oj28mG693IzHn+ZBGVdYBJ6DC9kIwHDBLjqEZVs=; b=HS1P28sT3c6lR4gzDHoI3qzU3dpK/nDyYggvglQx1cgOoe0I4umVNCYOh91HYoKlR6 lzlDIuN7TffY3XMJlRg0/5BkzGZ0aRajWPvj2s23o7s9+46MACg6hJKVksOc7VhP8OsU 4cFXr2xa8FtfOcPUegLJ7xVuuc954uAfl7NVg2jk5S789TORYv4x5Qftdct/PYdN5bFe /Ssa8GzMXoblKcqalNsALLXSeArYiH/kG6g/I7fgJyc1RJjM50gGPIzFIFhejNB5TNgI qWGkz/ppPGLQordhtZvbL/CyVLOYWTCbJcoGu488BHZCQq7zHruMxyDPh9YLbji6WQB1 IlEw== MIME-Version: 1.0 X-Received: by 10.194.161.136 with SMTP id xs8mr18408264wjb.31.1404566168110; Sat, 05 Jul 2014 06:16:08 -0700 (PDT) Received: by 10.216.139.132 with HTTP; Sat, 5 Jul 2014 06:16:08 -0700 (PDT) Date: Sat, 5 Jul 2014 09:16:08 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=089e013cc30a838af704fd720b82 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/YV4YuqcGXg6AorXd_5qB0Y06s-4 Cc: "spring@ietf.org" Subject: Re: [spring] Re.: SPRING OpenFlow interworking discussion X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 13:16:11 -0000 --089e013cc30a838af704fd720b82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8BDear =E2=80=8BAlvaro, Thank you. We are fine here now that Hurricane Arthur has moved out of our area. Yes, we are working on this (SPRING OpenFlow interworking) and look fwd. to publish a draft before the IETF90 mtg. dates. If it is possible to allocate few minutes near the end of the SPRING WG mtg. for open discussion, may be we can bring this topics up for further comments/ suggestions. Many thanks again. Best. Bhumip On Tue, Jul 1, 2014 at 1:47 PM, =E2=80=8B=E2=80=8B Alvaro Retana (aretana) wrote: > On 7/1/14 10:59 AM, "B.Khasnabish@ieee.org" wrote: > > Bhumip: > > Hi! How are you? > > Would there be any opportunity to discuss > SPRING OpenFlow interworking during the Toronto (IETF-90) mtg.? > > > If you're asking about time in the meeting..then then answer might be > "yes" if there is a published draft to discuss and time in the agenda. S= o > far we haven't ironed out the whole agenda. > > It may be useful to include a statement like > the following sentence in Sec. 6 (Interoperability with non-SPRING nodes) > of the SPRING problem > statement draft (draft-ietf-spring-problem-statement-01.txt). > > "Interoperability with openFlow (https://www.opennetworking.org/sdn > -resources/onf-specifications/openflow) based non-SPRING nodes will be > discussed in a future document." > > > I'll let the authors of that draft comment..but this is a good time to > put use cases forward. > > Best regards! > > Alvaro. > --089e013cc30a838af704fd720b82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8BDear =E2=80=8BAlvaro,
= =C2=A0
Thank you. We are fine here now that
Hurricane Arthur has moved= out of our area.
=C2=A0
Yes, we are working on this (SPRING OpenFlow interworkin= g) and look fwd. to publish
a draft before the IETF90 mtg. dates.
=C2=A0
If it is= possible to allocate few minutes near the end
of the SPRING WG mtg. for open discussion, may be
we can = bring this topics up for further comments/ suggestions.
=C2=A0
Many thanks again.
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0

On Tue, Jul 1= , 2014 at 1:47 PM,
=E2=80=8B=E2=80=8B
Alvaro Retana (aretana) <aretana@cisco.com>= wrote:
On 7/1/14 10:59 AM, "B.Khasnabish@ieee.org" <vumip1@gmail.com> wrote:

Bhumip:

Hi! =C2=A0How are you?

Would there be any opportunity to discuss
SPRING OpenFlow interworking during the Toronto (I= ETF-90) mtg.?=C2=A0

If you're asking about time in the meeting..then then answer= might be "yes" if there is a published draft to discuss and time= in the agenda. =C2=A0So far we haven't ironed out the whole agenda.

It may be useful to include a statement like
the following sentence in Sec. 6 (Interoperability with non-SPRING nod= es) of the SPRING problem
statement draft (draft-ietf-spring-problem-statement-01.<= span>txt).
=C2=A0
"Interoperability with openFlow (https://ww= w.opennetworking.org/sdn-resources/onf<= /span>-specifications/openflow) based non-SPRING nodes will be= discussed=C2=A0 in a future document."

I'll let the authors of that draft comment..but this is a go= od time to put use cases forward.

Best regards!

Alvaro.

--089e013cc30a838af704fd720b82-- From nobody Mon Jul 7 19:12:07 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29D1B29E9; Mon, 7 Jul 2014 19:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytvDyLjfiv_z; Mon, 7 Jul 2014 19:12:02 -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 68C841B29EA; Mon, 7 Jul 2014 19:12:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGW85141; Tue, 08 Jul 2014 02:12:00 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 03:11:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 10:11:53 +0800 From: Xuxiaohu To: Ron Parker Thread-Topic: Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF Thread-Index: AQHPmlH7odT5H7A+MEepJZdtU3RfXw== Date: Tue, 8 Jul 2014 02:11:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/iCTfEPSBOjLFOlzSVTJ8-Y9-rUI Cc: "" , "sfc@ietf.org" Subject: [spring] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 02:12:04 -0000 (Note that I changed the subject since this is a totally different topic) Hi Ron, I agree there are some cases where the underlay network is not MPLS-capable= . In those cases, you could actually just take the MPLS label stack which r= epresents a given SFP (http://tools.ietf.org/html/draft-xu-spring-sfc-use-c= ase-02) as an overlay, just like the SFC encapsulation header (http://tools= .ietf.org/html/draft-merged-sfc-architecture-00). The MPLS packets on the o= verlay could be transported over IP underlay networks with MPLS-over-IP tun= nels (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip= -00). IMHO, this MPLS label stack based (or SPRING based) SFC approach is a= concrete example of Transport Derived SFF (see below) as defined in sectio= n 4.3.1 of the SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-= architecture-00): 4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. Existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use a transport mechanism which carries the service path information from the SFC encapsulation, and information derived from the SFC encapsulation, to build transport information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, July 07, 2014 9:47 PM > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org' > Subject: Re: [sfc] New Version Notification for > draft-dunbar-sfc-fun-instances-restoration-00.txt >=20 > Qin, >=20 > I agree that RSVP-TE style MPLS is a close architectural match to what SF= C is > trying to achieve, and that an MPLS label stack in this context is likely= the most > efficient way to encode explicit source routing, packet-by-packet, while > preserving all the resiliency capabilities that are required for real-wor= ld SFC. >=20 > But one concern I have is the ubiquity, or lack thereof, of MPLS where SF= C > would be used. In mobile carrier environments, the SFC is seen as appli= cable > to the "Gi-LAN" set of value added services that are deployed between the > subscriber management system (i.e., GGSN/PDN-GW) and the Internet. In > some cases, this may be MPLS underpinning this part of the network, but i= n > others it is simple Ethernet or SDN overlay over Ethernet. >=20 > Please share your thoughts on this. >=20 > Thanks. >=20 > Ron >=20 From nobody Tue Jul 8 17:14:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450351A0190 for ; Tue, 8 Jul 2014 17:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADuj04LqH1i7 for ; Tue, 8 Jul 2014 17:13:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C2E1A0194 for ; Tue, 8 Jul 2014 17:13:36 -0700 (PDT) Received: from [172.29.33.9] (66.129.241.13) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 9 Jul 2014 00:13:34 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_2607852E-6242-4D38-9B22-AFB95A93C9D8" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 8 Jul 2014 20:13:24 -0400 Message-ID: References: To: "spring@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BLUPR08CA015.namprd08.prod.outlook.com (10.141.30.35) To BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0267E514F9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(164054003)(51704005)(377424004)(189002)(377454003)(199002)(497574002)(41574002)(24454002)(21056001)(76176999)(50986999)(15975445006)(99396002)(15202345003)(74662001)(82746002)(102836001)(62966002)(101416001)(33656002)(92566001)(84326002)(512954002)(92726001)(42186005)(74502001)(79102001)(76482001)(88136002)(77982001)(31966008)(77156001)(107046002)(50226001)(36756003)(16236675004)(89996001)(104166001)(2351001)(83072002)(87286001)(87976001)(83716003)(110136001)(85852003)(85306003)(106356001)(64706001)(20776003)(4396001)(57306001)(46102001)(86362001)(93916002)(95666004)(81542001)(105586002)(77096002)(19580405001)(83322001)(71186001)(81342001)(80022001)(19580395003)(104396001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB726; H:[172.29.33.9]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/pbMekYyOuoXYWBDFfEx5j8rwzHY Cc: "Alvaro Retana \(aretana\)" Subject: Re: [spring] IETF 90 Agenda Items (spring) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:13:39 -0000 --Apple-Mail=_2607852E-6242-4D38-9B22-AFB95A93C9D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, The draft agenda is available at = http://www.ietf.org/proceedings/90/agenda/agenda-90-spring. If you were = expecting a slot, please review. Also, please remember to provide your = slides no later than Monday July 21 (earlier is fine). Thanks, --John On Jun 27, 2014, at 4:47 PM, Alvaro Retana (aretana) = wrote: > Hi! >=20 > We have a 2-hour slot in Toronto on Wednesday afternoon: > WEDNESDAY, July 23, 2014 > 1300-1500 Afternoon Session I > Canadian RTG spring Source Packet Routing in Networking = WG >=20 > Send any requests for time to John and I. We will prioritize the = items already listed in the charter as milestones. Other items may be = considered if we have time. >=20 > Please note that we will be requiring two conditions to be part of the = final agenda: (1) your draft MUST have been published already, and (2) = you MUST provide the chairs with your slides by EOD on Monday, July 21, = 2014. We will also appreciate starting a discussion on the list so = everyone is aware of your draft and/or any updates. >=20 > Keep the following dates in mind: > 2014-07-04 (Friday): Internet Draft submission cut-off (for all = drafts, including -00) by UTC 23:59, upload using IETF ID Submission = Tool. > 2014-07-07 (Monday): Draft Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. > 2014-07-14 (Monday): Revised Working Group agendas due by UTC 23:59, = upload using IETF Meeting Materials Management Tool. > Thanks! >=20 > Alvaro. --Apple-Mail=_2607852E-6242-4D38-9B22-AFB95A93C9D8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" Folks,

The draft agenda is available at http://www.ietf.org/proceedings/90/agenda/agenda-90-spring. If you were expecting a slot, please review. Also, please remember to provide your slides no later than Monday July 21 (earlier is fine).

Thanks,

--John

On Jun 27, 2014, at 4:47 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:

Hi!

We have a 2-hour slot in Toronto on Wednesday afternoon:
WEDNESDAY, July 23, 2014
1300-1500  Afternoon Session I
Canadian        RTG 	spring      Source Packet Routing in Networking WG

Send any requests for time to John and I.  We will prioritize the items already listed in the charter as milestones. Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the final agenda: (1) your draft MUST have been published already, and (2) you MUST provide the chairs with your slides by EOD on Monday, July 21, 2014.  We will also appreciate starting a discussion on the list so everyone is aware of your draft and/or any updates.

Keep the following dates in mind:
Thanks!

Alvaro.
--Apple-Mail=_2607852E-6242-4D38-9B22-AFB95A93C9D8-- From nobody Tue Jul 8 21:00:49 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F881A0305; Tue, 8 Jul 2014 21:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kQ0xxZrhGIL; Tue, 8 Jul 2014 21:00:37 -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 0530A1A0302; Tue, 8 Jul 2014 21:00:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT73437; Wed, 09 Jul 2014 04:00:35 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 05:00:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 12:00:29 +0800 From: Xuxiaohu To: "" , "sfc@ietf.org" Thread-Topic: Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF Thread-Index: AQHPmlH7odT5H7A+MEepJZdtU3RfX5uWmeJw Date: Wed, 9 Jul 2014 04:00:29 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08291A4F@NKGEML512-MBS.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645D73306@dfweml701-chm.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829115C@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/pI4j5sC53FmKcD36OQop-I7hc_M Subject: Re: [spring] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 04:00:40 -0000 Hi all, The following are some drafts related to the SPRING-based SFC approach whic= h may be useful for you to get the whole picture of the SRPING-based SFC ap= proach. Any comments and suggestions are welcome. Use Case draft: http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02 SF Auto-discovery through IGP: http://tools.ietf.org/html/draft-xu-isis-service-function-adv-02 http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-02 SF Auto-discovery through DNS-SD: http://tools.ietf.org/html/draft-xu-dnssd-sf-discovery-01 SFP Computation through PCE: http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01 http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01 Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Tuesday, July 08, 2014 10:12 AM > To: Ron Parker > Cc: ; sfc@ietf.org > Subject: [sfc] Taking the MPLS label stack representing an SFP as an > overlay=3DTransport Derived SFF >=20 > (Note that I changed the subject since this is a totally different topic) >=20 > Hi Ron, >=20 > I agree there are some cases where the underlay network is not MPLS-capab= le. > In those cases, you could actually just take the MPLS label stack which > represents a given SFP > (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) as an overla= y, just > like the SFC encapsulation header > (http://tools.ietf.org/html/draft-merged-sfc-architecture-00). The MPLS p= ackets > on the overlay could be transported over IP underlay networks with > MPLS-over-IP tunnels > (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00= ). > IMHO, this MPLS label stack based (or SPRING based) SFC approach is a con= crete > example of Transport Derived SFF (see below) as defined in section 4.3.1 = of the > SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-architecture-= 00): >=20 > 4.3.1. Transport Derived SFF >=20 > Service function forwarding, as described above, directly depends > upon the use of the service path information contained in the SFC > encapsulation. Existing implementations may not be able to act on > the SFC encapsulation. These platforms may opt to use a transport > mechanism which carries the service path information from the SFC > encapsulation, and information derived from the SFC encapsulation, to > build transport information. >=20 > This results in the same architectural behavior and meaning for > service function forwarding and service function paths. It is the > responsibility of the control components to ensure that the transport > path executed in such a case is fully aligned with the path > identified by the information in the service chaining encapsulation. >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > > Sent: Monday, July 07, 2014 9:47 PM > > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org' > > Subject: Re: [sfc] New Version Notification for > > draft-dunbar-sfc-fun-instances-restoration-00.txt > > > > Qin, > > > > I agree that RSVP-TE style MPLS is a close architectural match to what > > SFC is trying to achieve, and that an MPLS label stack in this context > > is likely the most efficient way to encode explicit source routing, > > packet-by-packet, while preserving all the resiliency capabilities that= are > required for real-world SFC. > > > > But one concern I have is the ubiquity, or lack thereof, of MPLS where = SFC > > would be used. In mobile carrier environments, the SFC is seen as > applicable > > to the "Gi-LAN" set of value added services that are deployed between t= he > > subscriber management system (i.e., GGSN/PDN-GW) and the Internet. I= n > > some cases, this may be MPLS underpinning this part of the network, > > but in others it is simple Ethernet or SDN overlay over Ethernet. > > > > Please share your thoughts on this. > > > > Thanks. > > > > Ron > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jul 9 14:02:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE0D1B27C0 for ; Wed, 9 Jul 2014 14:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHOflsXJ0vV6 for ; Wed, 9 Jul 2014 14:02:05 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549641B27BB for ; Wed, 9 Jul 2014 14:02:05 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so9815122pad.35 for ; Wed, 09 Jul 2014 14:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=aDzlrZVC38lZ1zoBDyGgF6juDZUv2Fa4R3qcALU5Yhc=; b=o131bv7hsK5cf24U3RKk3ORH+c86rV68f/1/LpzcpBsSHf9jt9c9fAsvcGpc14Ng4R emPJB7n7LKGkjJJ/BdkP6V4HlsMgd2diao0tiTImroQsTVE5vltPVfd1oLmA4o2/t/HT dkelz0jZBrsSdEGaySZtoV3R18+UKCDJ4/X+zj5z+d2HXBUql5M8UUsVoaTqeA68W8t2 OJYzFRXMjQ05WOrWSXD97dpFUvt0IHwXOyjrdkXqsY5cnHgeLytFKvz80DZnBmZ/WfH3 OhNMT4T2YkdgGxWA/yAm7hzOfE3ujcGd8Njh/emHVBV0StgrZ+w1bu/ZDyjR13duwzGU eVFQ== X-Received: by 10.68.224.198 with SMTP id re6mr43473392pbc.8.1404939725001; Wed, 09 Jul 2014 14:02:05 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id qk9sm219590793pac.16.2014.07.09.14.02.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 14:02:04 -0700 (PDT) From: Sam Aldrin Content-Type: multipart/alternative; boundary="Apple-Mail=_B3BD4E2A-377A-42FF-87F4-211F279045CF" Date: Wed, 9 Jul 2014 14:02:01 -0700 Message-Id: <3654F7F3-C9AD-4FFF-8E1B-5D33B9768FED@gmail.com> To: draft-geib-spring-oam-usecase@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/36RSOo0f2JAvESEqskehjEL6tDI Cc: spring@ietf.org Subject: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 21:02:07 -0000 --Apple-Mail=_B3BD4E2A-377A-42FF-87F4-211F279045CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Authors, I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section #1 = it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and not = just providing use cases/scenarios. My understanding was, use case draft = should document scenarios where it will drive new requirements. = Solutions could be covered with existing toolset or defined newly, = depending on the GAP analysis. But that should be separate as there = could be more than 1 solution, where as this document could just focus = on use cases only. If infact this is supposed to be a solution document, then changing the = title would be more meaningful. That's my observation. 2. w.r.t. Section number #2, the same problem is being solved with = "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in this = section could be done with the proxy ping(solution wise) where, request = could be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding right? If not, how is it different here? 3. When the response is sent back to PMS which is not part of MPLS or = segment domain, there is a serious security aspect, which needs to = considered. I believe it applies to sending a request too. Will you be = documenting that aspect? 4. Sec 3.2 to monitor bundle links, one could perform that with RFC4379 = ping with multpath + proxy ping. Could you kindly differentiate if there = is something new the solution brings here? 5. sec #5, Is the requirement here only for PMS to learn the topology, = in the case of mixed env?=20 6. In sec 3.1,=20 Determining a path to be executed prior to a measurement may also be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths of an MPLS domain. If correct forwarding along the desired paths has to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But later = you say, RFC4379 functionality could be used. Could you clarify how = could you verify a path, if MPLS validation is not done. More text will = help. Also, more importantly, the text earlier to the above says, for = valid result, MPLS OAM has to be performed for topology changes etc. If = so, it contradicts here. 7. Last but not the least, how different is PMS from EMS and NMS? = Somehow I couldn=92t find the difference what PMS could do and NMS/EMS = couldn=92t. cheers -sam= --Apple-Mail=_B3BD4E2A-377A-42FF-87F4-211F279045CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Authors,

I have few questions about = this draft.

1. The title is confusing to me. It = says OAM use case but in section #1 it says the = following

<snip>
This document describes a solution to this problem =
statement and
   illustrates it with use-cases.

   The solution is described for a single IGP MPLS domain.

   The solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed LSP's.
<end snip>

In fact the draft is describing a solution to certain =
scenarios and not just providing use cases/scenarios. My understanding =
was, use case draft should document scenarios where it will drive new =
requirements. Solutions could be covered with existing toolset or =
defined newly, depending on the GAP analysis. But that should be =
separate as there could be more than 1 solution, where as this document =
could just focus on use cases only.

If infact this is supposed to be a solution document, =
then changing the title would be more meaningful. That's my =
observation.

2. w.r.t. Section number #2, the same problem is =
being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being =
described in this section could be done with the proxy ping(solution =
wise) where, request could be sent to monitor LER i and LER j segment, =
from a PMS. Is my understanding right? If not, how is it different =
here?

3. When the response is sent back to PMS which is not =
part of MPLS or segment domain, there is a serious security aspect, =
which needs to considered. I believe it applies to sending a request =
too. Will you be documenting that aspect?

4. Sec 3.2 to monitor bundle links, one could perform =
that with RFC4379 ping with multpath + proxy ping. Could you kindly =
differentiate if there is something new the solution brings here?

5. sec #5, Is the requirement here only for PMS to =
learn the topology, in the case of mixed env? 

6. In sec 3.1, 
<snip>
Determining a path to be executed prior to a =
measurement may also be
   done by setting up a label including all node SIDs along that path
   (if LER1 has Node SID 40 in the example and it should be passed
   between LER i and LER j, the label stack is 20 - 40 - 30 - 10).  The
   advantage of this method is, that it does not involve MPLS OAM
   functionality and it is independent of ECMP functionalities.  The
   method still is able to monitor all link combinations of all paths of
   an MPLS domain.  If correct forwarding along the desired paths has to
   be checked, RFC4739 functionality should be applied also in this
   case.

<end snip>

In the above you mention that it does not involve =
MPLS OAM. But later you say, RFC4379 functionality could be used. Could =
you clarify how could you verify a path, if MPLS validation is not done. =
More text will help. Also, more importantly, the text earlier to the =
above says, for valid result, MPLS OAM has to be performed for topology =
changes etc. If so, it contradicts here.

7. Last but not the least, how different is PMS from =
EMS and NMS? Somehow I couldn=92t find the difference what PMS could do =
and NMS/EMS couldn=92t.

cheers
-sam
= --Apple-Mail=_B3BD4E2A-377A-42FF-87F4-211F279045CF-- From nobody Thu Jul 10 07:16:19 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCBB1B2911 for ; Thu, 10 Jul 2014 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYcgjz752Jc8 for ; Thu, 10 Jul 2014 07:16:02 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9161B2904 for ; Thu, 10 Jul 2014 07:16:00 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jul 2014 16:15:36 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 10 Jul 2014 16:15:36 +0200 From: To: Date: Thu, 10 Jul 2014 16:15:35 +0200 Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7JFn8M7oEWSHSWy/YOOU0tAQAT5ZsQAA/kkXA= Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/PJuye03IefAHCcVub2spL_CYJy4 Cc: spring@ietf.org, draft-geib-spring-oam-usecase@tools.ietf.org Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 14:16:11 -0000 Hi Sam, my replies are marked [RG] and added to your text.=20 - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft. - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= ) Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. Regards,=20 Ruediger Sam Aldrin wrote: I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section = #1=20 it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and = not just=20 providing use cases/scenarios. My understanding was, use case draft = should=20 document scenarios where it will drive new requirements. Solutions c= ould=20 be covered with existing toolset or defined newly, depending on the = GAP=20 analysis. But that should be separate as there could be more than 1 = solution,=20 where as this document could just focus on use cases only. If infact this is supposed to be a solution document, then changing = the title=20 would be more meaningful. That's my observation. [RG] Thanks. It's a use case document. We'll review the text of section 1. 2. w.r.t. Section number #2, the same problem is being solved with=20 "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in thi= s=20 section could be done with the proxy ping(solution wise) where, requ= est could=20 be sent to monitor LER i and LER j segment, from a PMS. Is my unders= tanding=20 right? If not, how is it different here? [RG] The PMS is able to set up packets which stay in data plane and execute= a desired=20 chain of MPLS LSPs. [RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down a LSP or part of an LSP. [RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds functionality: a) You don't need an additional protocol or functionality like proxy-ping t= o check data=20 plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS imple= mentation.=20 b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379,=20 it can continue to execute arbitrary LSP combinations and the monitoring= packets stay=20 in data plane. Please point me to the text in proxy-ping offering this f= eature. =20 3. When the response is sent back to PMS which is not part of MPLS = or segment=20 domain, there is a serious security aspect, which needs to consider= ed. I believe=20 it applies to sending a request too. Will you be documenting that a= spect? [RG] That's a valid point. The domain external system is one option and the= team will deal with the security aspects raised by this option once we are= in solution space. We will not analyse this in depth for a use case docume= nt. 4. Sec 3.2 to monitor bundle links, one could perform that with RFC= 4379 ping=20 with multpath + proxy ping. Could you kindly differentiate if there= is something=20 new the solution brings here? [RG] The SR OAM author team has provided text how to monitor a bundled link= in the use case draft. You are a co-author of proxy-lsp. I couldn't find e= xplicit text on how to detect and monitor a bundled link in draft-proxy-lsp= . Please describe how proxy-lsp can be used to monitor a bundled link (sorr= y if this is obvious and I missed it). If there are differences to the SR O= AM approach, we'll discuss them. 5. sec #5, Is the requirement here only for PMS to learn the topol= ogy, in the=20 case of mixed env?=20 [RG] MPLS topology awareness is the precondition to set up packets with lab= el stacks executing a desired chain of LSPs. If suitable Label/FEC/node rel= ation is known to the PMS, that LSP can be executed from that node on by a = PMS monitoring packet. 6. In sec 3.1,=20 Determining a path to be executed prior to a measurement may also = be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). T= he advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths= of an MPLS domain. If correct forwarding along the desired paths has= to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But la= ter you say,=20 RFC4379 functionality could be used. Could you clarify how could y= ou verify a=20 path, if MPLS validation is not done. More text will help. Also, m= ore=20 importantly, the text earlier to the above says, for valid result,= MPLS=20 OAM has to be performed for topology changes etc. If so, it contra= dicts here. [RG] The text should say that - without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information. - if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied. If you understand this statement and the text in the draft states something= different, I'll try to reword it. 7. Last but not the least, how different is PMS from EMS and NMS?= =20 Somehow I couldn't find the difference what PMS could do and=20 NMS/EMS couldn't. [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses t= his topology awareness to create data plane packets executing LSP combinati= ons as desired by an operator. Had this feature been commercially available= , the company I work for wouldn't have been developing a PMS. From nobody Thu Jul 10 11:13:35 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3DF1A0174 for ; Thu, 10 Jul 2014 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxuNYsyO7bIl for ; Thu, 10 Jul 2014 11:13:32 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C0A1A0394 for ; Thu, 10 Jul 2014 11:13:30 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id w7so8104092qcr.2 for ; Thu, 10 Jul 2014 11:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nJmcQOdtm8hecPj5YDEnRct6q0UYtQc2MN4gD3nejhw=; b=eDFNKdO1ewYekHfG0smboJnj6iTstfaIv2ZWCRgiLDxhTTYzFBxx8/SC5YQsFf/XQt d0F2QdbWkA94iPdp6oO0lTcVARDJGyIErrvVk2VTEfgSd4GUlWhq+5TiihVKGJ01AWba aKEvz7xYgagCkDILKzQm0pZdzpXvFu9Var2MpAwG5+xx/xyGh0cvSD3pEWYDV4ia7Jpr b/8DMdScOfCjOfYIN1V6o+PVb3yU3h0N8xevJvUj51ZLH6YfM29CVXHBK7KEANZnJSVt SG3rxIxNBfbziZDdvC4CIfaxEQxibJH+4rhA5oFxUsE7PaHqiOg+qIDl8A3MymnuPlax gCgw== MIME-Version: 1.0 X-Received: by 10.140.25.226 with SMTP id 89mr124756qgt.62.1405016010206; Thu, 10 Jul 2014 11:13:30 -0700 (PDT) Received: by 10.96.70.106 with HTTP; Thu, 10 Jul 2014 11:13:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jul 2014 11:13:30 -0700 Message-ID: From: Sam Aldrin To: Ruediger.Geib@telekom.de Content-Type: multipart/alternative; boundary=001a11c13cfc31339b04fddac872 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ytQwkklPdn8u6nh0EX_4ze_1DQM Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:13:34 -0000 --001a11c13cfc31339b04fddac872 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, wrote: > Hi Sam, > > my replies are marked [RG] and added to your text. > > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for > every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our us= e > case can use any OAM (in particular, specific good uses for BFD, and ICMP= v6) > > Based on that, it=C2=B9s a solution with broader scope and better fit for > SPRING as a whole. %sam - I believe you say it is use case document below. Then solution is too premature at this point of time, as we haven't deliberated on the requirements either. > > As you write, SR based OAM partially offers similar functions as > proxy-lsp. Without requiring the additional messages and LER/LSR processi= ng > introduced by proxy-lsp. > Regards, > > Ruediger > > > Sam Aldrin wrote: > > I have few questions about this draft. > > 1. The title is confusing to me. It says OAM use case but in sectio= n > #1 > it says the following > > > This document describes a solution to this problem statement and > illustrates it with use-cases. > > The solution is described for a single IGP MPLS domain. > > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > > > In fact the draft is describing a solution to certain scenarios an= d > not just > providing use cases/scenarios. My understanding was, use case draf= t > should > document scenarios where it will drive new requirements. Solutions > could > be covered with existing toolset or defined newly, depending on th= e > GAP > analysis. But that should be separate as there could be more than = 1 > solution, > where as this document could just focus on use cases only. > > If infact this is supposed to be a solution document, then changin= g > the title > would be more meaningful. That's my observation. > > [RG] Thanks. It's a use case document. We'll review the text of section 1= . > %sam - OK. then I'd like to see any specific solution content removed, that way we dont have to discuss what other solutions does either or compare with :D > 2. w.r.t. Section number #2, the same problem is being solved with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in > this > section could be done with the proxy ping(solution wise) where, > request could > be sent to monitor LER i and LER j segment, from a PMS. Is my > understanding > right? If not, how is it different here? > > [RG] The PMS is able to set up packets which stay in data plane and > execute a desired > chain of MPLS LSPs. > %sam - Execute you mean traverse? or perform something else? > > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS > ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message to > be sent down a LSP or part of an LSP. > %sam - If it is proposing extensions, it has to be solution document and cannot claim to be use case document. Also this document is on information track. > > [RG] I take it as saying that if you'd like to remotely execute RFC4379 > functionality on any LSP, you could either use the PMS or proxy-ping. The > PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like proxy-ping > to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS > implementation. > %sam - RFC4379 performs validation of dataplane and also find out lot more errors. You need additional information to perform validation checks. For liveness detection, BFD is preferred tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validation of data plane to control plane, etc? (I think you agree to this in the later part of the doc also) > b) once PMS detected data plane liveliness and correctness of MPLS > topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the > monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering this > feature. > %sam - This you could perform even without proxy ping. The function you are describing is, how you use lsp ping rather than what lsp ping does. Again I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implementation. - perform ping with right selectors for the path and use TTL for limiting the hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy ping to start from LER i > > 3. When the response is sent back to PMS which is not part of MPL= S > or segment > domain, there is a serious security aspect, which needs to > considered. I believe > it applies to sending a request too. Will you be documenting that > aspect? > > [RG] That's a valid point. The domain external system is one option and > the team will deal with the security aspects raised by this option once w= e > are in solution space. We will not analyse this in depth for a use case > document. > %sam - nod > > 4. Sec 3.2 to monitor bundle links, one could perform that with > RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if > there is something > new the solution brings here? > > [RG] The SR OAM author team has provided text how to monitor a bundled > link in the use case draft. You are a co-author of proxy-lsp. I couldn't > find explicit text on how to detect and monitor a bundled link in > draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a > bundled link (sorry if this is obvious and I missed it). If there are > differences to the SR OAM approach, we'll discuss them. > %sam - The same steps described above could be used if each bundled link member is identified with a unique label. While performing tree trace or ping with multipath, LER i will respond with DDMAP info for each of the links and the multipath info for the same. If you say that each link member has same label stack, then you could use lsp selectors as defined in RFC4379, in this case it is local host dest ip addr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but cannot discern its link members, then you could only validate the interface and not its individual members. Same applies in your case too. Cannot see how it is different. > > > 5. sec #5, Is the requirement here only for PMS to learn the > topology, in the > case of mixed env? > > [RG] MPLS topology awareness is the precondition to set up packets with > label stacks executing a desired chain of LSPs. If suitable Label/FEC/nod= e > relation is known to the PMS, that LSP can be executed from that node on = by > a PMS monitoring packet. > %sam - So, you are saying that you still need to perform RFC4379 trace or treetrace to get topology. I do not think IGP extensions being proposed in SPRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and PMS packets going through, for a given LSP or Segment, how do you know there is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop because of the bells and whistles it carries along with the packet. > > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may als= o > be > done by setting up a label including all node SIDs along that pa= th > (if LER1 has Node SID 40 in the example and it should be passed > between LER i and LER j, the label stack is 20 - 40 - 30 - 10). > The > advantage of this method is, that it does not involve MPLS OAM > functionality and it is independent of ECMP functionalities. Th= e > method still is able to monitor all link combinations of all > paths of > an MPLS domain. If correct forwarding along the desired paths > has to > be checked, RFC4739 functionality should be applied also in this > case. > > > > In the above you mention that it does not involve MPLS OAM. But > later you say, > RFC4379 functionality could be used. Could you clarify how could > you verify a > path, if MPLS validation is not done. More text will help. Also, > more > importantly, the text earlier to the above says, for valid > result, MPLS > OAM has to be performed for topology changes etc. If so, it > contradicts here. > > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only based > on control plane information. > - if the operator wants to make sure that data plane corresponds to > control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states > something different, I'll try to reword it. > %sam - The problem I am having is, in the case of MPLS, for OAM, you have to validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use case is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. > > 7. Last but not the least, how different is PMS from EMS and NMS= ? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. > > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses > this topology awareness to create data plane packets executing LSP > combinations as desired by an operator. Had this feature been commerciall= y > available, the company I work for wouldn't have been developing a PMS. > %sam - There are tools which are part of NMS/OSS, which performs MPLS topology specific operations for a given set of LSP's. They perform Treetrace and perform ping with multipath. Also perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could automate the workflow without the need for OSS/PMS, by using probe technology. Will not say beyond that :D cheers -sam --001a11c13cfc31339b04fddac872 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ruediger,

Thanks for the quick respo= nse. Please find my responses inline.

<= br>
On Thu, Jul 10, 2014 at 7:15 AM, <= Ruediger.Geib@telekom.de> wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=C2=B9s a solution with broader scope and better fit for S= PRING as a whole.=C2=A0
%sam - I believe you say it is use= case document below. Then solution is too premature at this point of time,= as we haven't deliberated on the requirements either.=C2=A0

As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp.=C2=A0

Regards,

Ruediger


=C2=A0 =C2=A0 =C2=A0 Sam Aldrin wrote:

=C2=A0 =C2=A0 =C2=A0 I have few questions about this draft.

=C2=A0 =C2=A0 =C2=A0 1. The title is confusing to me. It says OAM use case = but in section #1
=C2=A0 =C2=A0 =C2=A0 it says the following

=C2=A0 =C2=A0 =C2=A0 <snip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document describes a solution to this probl= em statement and
=C2=A0 =C2=A0 =C2=A0 =C2=A0illustrates it with use-cases.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The solution is described for a single IGP MPLS = domain.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The solution applies to monitoring of LDP LSP= 9;s as well as to
=C2=A0 =C2=A0 =C2=A0 =C2=A0monitoring of Segment Routed LSP's.
=C2=A0 =C2=A0 =C2=A0 <end snip>

=C2=A0 =C2=A0 =C2=A0 =C2=A0In fact the draft is describing a solution to ce= rtain scenarios and not just
=C2=A0 =C2=A0 =C2=A0 =C2=A0providing use cases/scenarios. My understanding = was, use case draft should
=C2=A0 =C2=A0 =C2=A0 =C2=A0document scenarios where it will drive new requi= rements. Solutions could
=C2=A0 =C2=A0 =C2=A0 =C2=A0be covered with existing toolset or defined newl= y, depending on the GAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0analysis. But that should be separate as there c= ould be more than 1 solution,
=C2=A0 =C2=A0 =C2=A0 =C2=A0where as this document could just focus on use c= ases only.

=C2=A0 =C2=A0 =C2=A0 =C2=A0If infact this is supposed to be a solution docu= ment, then changing the title
=C2=A0 =C2=A0 =C2=A0 =C2=A0would be more meaningful. That's my observat= ion.

[RG] Thanks. It's a use case document. We'll review the text = of section 1.
%sam - OK. then I'd like to see any = specific solution content removed, that way we dont have to discuss what ot= her solutions does either or compare with :D


=C2=A0 =C2=A0 =C2=A0 =C2=A02. w.r.t. Section number #2, the same problem is= being solved with
=C2=A0 =C2=A0 =C2=A0 =C2=A0"draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0section could be done with the proxy ping(soluti= on wise) where, request could
=C2=A0 =C2=A0 =C2=A0 =C2=A0be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
=C2=A0 =C2=A0 =C2=A0 =C2=A0right? If not, how is it different here?

[RG] The PMS is able to set up packets which stay in data plane and e= xecute a desired
=C2=A0 =C2=A0 =C2=A0chain of MPLS LSPs.
%sam - Execute= you mean traverse? or perform something else?=C2=A0

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
=C2=A0 =C2=A0allow a third party to remotely cause an MPLS Echo Request mes= sage to
=C2=A0 =C2=A0be sent down a LSP or part of an LSP.
%sa= m - If it is proposing extensions, =C2=A0it has to be solution document =C2= =A0and cannot claim to be use case document. Also this document is on infor= mation track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379= functionality on any LSP, you could either use the PMS or proxy-ping. The = PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-pi= ng to check data
=C2=A0 =C2=A0plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.
%sam - RFC4379 performs validatio= n of dataplane and also find out lot more errors. You need additional infor= mation to perform validation checks. For liveness detection, BFD is preferr= ed tool, atleast in present deployments.So are you saying, PMS solution is = designed for liveness detection and not to perform validation of data plane= to control plane, etc? (I think you agree to this in the later part of the= doc also)
=C2=A0
b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379,
=C2=A0 =C2=A0it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
=C2=A0 =C2=A0in data plane. Please point me to the text in proxy-ping offer= ing this feature.
%sam - This you could perform even w= ithout proxy ping. The function you are describing is, how you use lsp ping= rather than what lsp ping does. Again I am not talking about non-mpls topo= logy.
To answer your question, how you perform.
- Perform treetrac= e with rfc4379 to get topology info
- pick any arbitary LSP paths= discovered along with its multipath implementation.
- perform pi= ng with right selectors for the path and use TTL for limiting the hop [LER = j].
- if you want to perform from LER i to LER j as in your draft, use pro= xy ping to start from LER i

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. When the response is sent back to PMS which = is not part of MPLS or segment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain, there is a serious security aspect, whi= ch needs to considered. I believe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external system is one opti= on and the team will deal with the security aspects raised by this option o= nce we are in solution space. We will not analyse this in depth for a use c= ase document.
%sam - nod=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with multpath + proxy ping. Could you kindly di= fferentiate if there is something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new the solution brings here?

[RG] The SR OAM author team has provided text how to monitor a bundle= d link in the use case draft. You are a co-author of proxy-lsp. I couldn= 9;t find explicit text on how to detect and monitor a bundled link in draft= -proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled = link (sorry if this is obvious and I missed it). If there are differences t= o the SR OAM approach, we'll discuss them.
%sam - The same steps described above could be used if ea= ch bundled link member is identified with a unique label. While performing = tree trace or ping with multipath, LER i will respond with DDMAP info for e= ach of the links and the multipath info for the same.
If you say that each link member has same label stack, then you could = use lsp selectors as defined in RFC4379, in this case it is local host dest= ip addr, to identify each link member.
Now if the MPLS forwardin= g layer sees the bundled link as one interface but cannot discern its link = members, then you could only validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is different.
=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case of mixed env?

[RG] MPLS topology awareness is the precondition to set up packets wi= th label stacks executing a desired chain of LSPs. If suitable Label/FEC/no= de relation is known to the PMS, that LSP can be executed from that node on= by a PMS monitoring packet.
%sam - So, you are saying that you still need to perform = RFC4379 trace or treetrace to get topology. I do not think IGP extensions b= eing proposed in SPRING export any of the info other than label stack.=C2= =A0
And the proposed PMS solution (not use case) is that, it performs on d= emand per segment, which Proxy ping also does, albeit only for MPLS topolog= y.
The case you are making is that no need of bells and whistles = of RFC4379.

Question I have for you is, if data plane packets are g= etting dropped and PMS packets going through, for a given LSP or Segment, h= ow do you know there is a problem? if you know, how do you figure out where= it is?
At least with RFC4379 and/or proxy ping, you could validate each hop b= ecause of the bells and whistles it carries along with the packet.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06. In sec 3.1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<snip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Determining a path to be executed prior t= o a measurement may also be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0done by setting up a label including all = node SIDs along that path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if LER1 has Node SID 40 in the example a= nd it should be passed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between LER i and LER j, the label stack = is 20 - 40 - 30 - 10). =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advantage of this method is, that it does= not involve MPLS OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functionality and it is independent of EC= MP functionalities. =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0method still is able to monitor all link = combinations of all paths of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an MPLS domain. =C2=A0If correct forwardi= ng along the desired paths has to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be checked, RFC4739 functionality should = be applied also in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<end snip>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the above you mention that it does not= involve MPLS OAM. But later you say,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC4379 functionality could be used. Coul= d you clarify how could you verify a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path, if MPLS validation is not done. Mor= e text will help. Also, more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0importantly, the text earlier to the abov= e says, for valid result, MPLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.
%sam - The prob= lem I am having is, in the case of MPLS, for OAM, you have to validate the = lsp.
I definitely see a specific need for SPRING, but what I feel is, the u= se case is too much catered to a specific envisioned solution.
On= ce you remove solution or suggested enhancements, hope it should be clear o= n what is being solved and scope out clear requirements for a solution.
For solution part, please publish a separate ID.
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07. Last but not the least, how different = is PMS from EMS and NMS?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Somehow I couldn't find the differenc= e what PMS could do and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topology aware = and uses this topology awareness to create data plane packets executing LSP= combinations as desired by an operator. Had this feature been commercially= available, the company I work for wouldn't have been developing a PMS.=
%sam - There are tools which are part of NMS/OSS, which p= erforms MPLS topology specific operations =C2=A0for a given set of LSP'= s. They perform Treetrace and perform ping with multipath. Also perform LSP= specific validation by crafting packets with data available with treetrace= and ping with multipath. You could automate the workflow without the need = for OSS/PMS, by using probe technology. Will not say beyond that :D

cheers
-sam


--001a11c13cfc31339b04fddac872-- From nobody Thu Jul 10 11:59:58 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4721B2972 for ; Thu, 10 Jul 2014 11:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.551 X-Spam-Level: X-Spam-Status: No, score=-114.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIgILSYCAHPK for ; Thu, 10 Jul 2014 11:59:40 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FB11A854D for ; Thu, 10 Jul 2014 11:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47044; q=dns/txt; s=iport; t=1405018791; x=1406228391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x5Tl799850jMWsfKvkbA+RVnjYY6zRFTbDlWpAEuIiY=; b=jFvU1TLCrhxHwE8jaAK49poaPJEGLtjldVO+0szucez8JFqVlJC7XepI siEtY89AzjI2q2w9bv+vrv0+PREZZY11eZySrtiF8YylsUG4RD6W5wzx8 NGcarIuZ0YlYN7vcDCNnIkCUWlmRRxhjTAvXcnhi2yiIy+52n4V//hbjn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAEHivlOtJV2b/2dsb2JhbABPCoJHIyRSWoJvvXaHSgEZdRZ1hAMBAQEEGgkKOgsHEAIBCBEBAwEBCxYBBgMCAgIwFAMGCAEBBAENBQgTiCcBrguZLReOaCsGByQGAQIEA4JuNoEWBZxIkk2DQ4FwJBw X-IronPort-AV: E=Sophos; i="5.01,639,1400025600"; d="scan'208,217"; a="59867165" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 10 Jul 2014 18:59:50 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6AIxctN011021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 18:59:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 13:59:38 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLw Date: Thu, 10 Jul 2014 18:59:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E262A73xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/4VvxbLnt2H1bPul2E1ScHaqcq-8 Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 18:59:45 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E262A73xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpKdXN0IHRvIHBvaW50IG91dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVu dCDigKYNCg0KVGhlIHRlc3QgcGFja2V0IGdlbmVyYXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0 d29yay1kZXZpY2UgY2FuIGhhdmUgdGhlIGNvbXBsZXRlIHNlZ21lbnQgc3RhY2sgb24gaG93IHRv IHRyYXZlcnNlIHRoZSBuZXR3b3JrIGFzIHdlbGwgYXMgaG93IHRvIGNvbWUgYmFjayB0byBzZWxm IHdpdGhvdXQgYW55IGZ1cnRoZXIgc2lnbmFsaW5nLCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24g bmV0d29yayBub2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuDQoNClRo YXQgbWFrZXMgdGhpcyBhcHByb2FjaCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB1c2luZyBwcm94eSBM U1AgcGluZy4NCg0KVGhpcyBjZXJ0YWlubHkgaGFzIHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2Fu IGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8g bW9uaXRvciB0aGUgbmV0d29yay4NCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQpGcm9tOiBzcHJpbmcg W21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4N ClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE0NClRvOiBSdWVkaWdlci5HZWli QHRlbGVrb20uZGUNCkNjOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQpT dWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIFJ1ZWRpZ2VyLA0KDQpUaGFua3Mg Zm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZS4N Cg0KT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwgPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBTYW0sDQoN Cm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuDQoNCi0g UHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBp cyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyArIElQdjYpLiBXZSdsbCBj bGFyaWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Lg0KLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBM U1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2UgY2FzZSBjYW4gdXNl IGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBmb3IgQkZELCBhbmQg SUNNUHY2KQ0KDQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGggYnJvYWRlciBz Y29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuDQolc2FtIC0gSSBiZWxp ZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cuIFRoZW4gc29sdXRpb24g aXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9mIHRpbWUsIGFzIHdlIGhhdmVuJ3QgZGVs aWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBlaXRoZXIuDQoNCkFzIHlvdSB3cml0ZSwgU1Ig YmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJveHktbHNw LiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBhbmQgTEVSL0xTUiBw cm9jZXNzaW5nIGludHJvZHVjZWQgYnkgcHJveHktbHNwLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdl cg0KDQoNCiAgICAgIFNhbSBBbGRyaW4gd3JvdGU6DQoNCiAgICAgIEkgaGF2ZSBmZXcgcXVlc3Rp b25zIGFib3V0IHRoaXMgZHJhZnQuDQoNCiAgICAgIDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcg dG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxDQogICAgICBpdCBz YXlzIHRoZSBmb2xsb3dpbmcNCg0KICAgICAgPHNuaXA+DQogICAgICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KICAgICAg IGlsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLg0KDQogICAgICAgVGhlIHNvbHV0aW9uIGlz IGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLg0KDQogICAgICAgVGhlIHNv bHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bw0K ICAgICAgIG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuDQogICAgICA8ZW5kIHNu aXA+DQoNCiAgICAgICBJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5nIGEgc29sdXRpb24g dG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0DQogICAgICAgcHJvdmlkaW5nIHVzZSBj YXNlcy9zY2VuYXJpb3MuIE15IHVuZGVyc3RhbmRpbmcgd2FzLCB1c2UgY2FzZSBkcmFmdCBzaG91 bGQNCiAgICAgICBkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBkcml2ZSBuZXcgcmVx dWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQNCiAgICAgICBiZSBjb3ZlcmVkIHdpdGggZXhpc3Rp bmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBlbmRpbmcgb24gdGhlIEdBUA0KICAgICAg IGFuYWx5c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhlcmUgY291bGQgYmUg bW9yZSB0aGFuIDEgc29sdXRpb24sDQogICAgICAgd2hlcmUgYXMgdGhpcyBkb2N1bWVudCBjb3Vs ZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Lg0KDQogICAgICAgSWYgaW5mYWN0IHRoaXMg aXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUg dGl0bGUNCiAgICAgICB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBteSBvYnNlcnZh dGlvbi4NCltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNhc2UgZG9jdW1lbnQuIFdlJ2xsIHJldmll dyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuDQolc2FtIC0gT0suIHRoZW4gSSdkIGxpa2UgdG8gc2Vl IGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIHRoYXQgd2F5IHdlIGRvbnQg aGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRpb25zIGRvZXMgZWl0aGVyIG9yIGNvbXBh cmUgd2l0aCA6RA0KDQoNCiAgICAgICAyLiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBz YW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIHdpdGgNCiAgICAgICAiZHJhZnQtaWV0Zi1tcGxz LXByb3h5LWxzcC1waW5nLTAyIiAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXMNCiAg ICAgICBzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJveHkgcGluZyhzb2x1dGlvbiB3 aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZA0KICAgICAgIGJlIHNlbnQgdG8gbW9uaXRvciBMRVIg aSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJzdGFuZGluZw0KICAg ICAgIHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT8NCltSR10gVGhlIFBN UyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0YSBwbGFuZSBhbmQg ZXhlY3V0ZSBhIGRlc2lyZWQNCiAgICAgY2hhaW4gb2YgTVBMUyBMU1BzLg0KJXNhbSAtIEV4ZWN1 dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVsc2U/DQoNCltSR10g UHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbCBleHRlbnNpb25z IHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG8NCiAgIGFsbG93IGEgdGhpcmQgcGFydHkgdG8gcmVt b3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bw0KICAgYmUgc2VudCBk b3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLg0KJXNhbSAtIElmIGl0IGlzIHByb3Bvc2luZyBl eHRlbnNpb25zLCAgaXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICBhbmQgY2Fubm90IGNs YWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24gaW5m b3JtYXRpb24gdHJhY2suDQoNCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0IGlmIHlvdSdk IGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55IExT UCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBUaGUgUE1TIGhv d2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkcw0KZnVuY3Rpb25hbGl0eToNCmEpIFlvdSBkb24ndCBu ZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBsaWtlIHByb3h5LXBp bmcgdG8gY2hlY2sgZGF0YQ0KICAgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3OSBpcyBmaW5lLiBE ZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxlbWVudGF0aW9uLg0KJXNhbSAtIFJG QzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxhbmUgYW5kIGFsc28gZmluZCBvdXQg bG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHBlcmZv cm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVm ZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRlcGxveW1lbnRzLlNvIGFyZSB5b3Ugc2F5 aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9yIGxpdmVuZXNzIGRldGVjdGlvbiBhbmQg bm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRhIHBsYW5lIHRvIGNvbnRyb2wgcGxhbmUs IGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMgaW4gdGhlIGxhdGVyIHBhcnQgb2YgdGhl IGRvYyBhbHNvKQ0KDQpiKSBvbmNlIFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3Mg YW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSwNCiAgIGl0IGNhbiBj b250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9u aXRvcmluZyBwYWNrZXRzIHN0YXkNCiAgIGluIGRhdGEgcGxhbmUuIFBsZWFzZSBwb2ludCBtZSB0 byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVhdHVyZS4NCiVzYW0gLSBU aGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rp b24geW91IGFyZSBkZXNjcmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGluZyByYXRoZXIgdGhh biB3aGF0IGxzcCBwaW5nIGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9uLW1w bHMgdG9wb2xvZ3kuDQpUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLg0K LSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5IGluZm8NCi0g cGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVs dGlwYXRoIGltcGxlbWVudGF0aW9uLg0KLSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxlY3Rv cnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIgal0u DQotIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIgaiBhcyBpbiB5b3Vy IGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpDQoNCiAgICAgICAgMy4g V2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBNUyB3aGljaCBpcyBub3QgcGFydCBv ZiBNUExTIG9yIHNlZ21lbnQNCiAgICAgICAgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2Vj dXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmUNCiAgICAg ICAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91IGJlIGRvY3Vt ZW50aW5nIHRoYXQgYXNwZWN0Pw0KW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRvbWFp biBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0gd2lsbCBkZWFsIHdp dGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJl IGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9y IGEgdXNlIGNhc2UgZG9jdW1lbnQuDQolc2FtIC0gbm9kDQoNCiAgICAgICAgNC4gU2VjIDMuMiB0 byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRoIFJGQzQz NzkgcGluZw0KICAgICAgICB3aXRoIG11bHRwYXRoICsgcHJveHkgcGluZy4gQ291bGQgeW91IGtp bmRseSBkaWZmZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZw0KICAgICAgICBuZXcgdGhl IHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KW1JHXSBUaGUgU1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBw cm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIHRoZSB1c2UgY2Fz ZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkgY291bGRuJ3QgZmlu ZCBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVkIGxp bmsgaW4gZHJhZnQtcHJveHktbHNwLiBQbGVhc2UgZGVzY3JpYmUgaG93IHByb3h5LWxzcCBjYW4g YmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIChzb3JyeSBpZiB0aGlzIGlzIG9idmlv dXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBP QU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS4NCiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBk ZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIg aXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUg dHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNwb25kIHdpdGggRERN QVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBhdGggaW5mbyBmb3Ig dGhlIHNhbWUuDQpJZiB5b3Ugc2F5IHRoYXQgZWFjaCBsaW5rIG1lbWJlciBoYXMgc2FtZSBsYWJl bCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBzZWxlY3RvcnMgYXMgZGVmaW5lZCBpbiBS RkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdCBkZXN0IGlwIGFkZHIsIHRvIGlk ZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQpOb3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBsYXll ciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBidXQgY2Fubm90IGRpc2Nl cm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2YWxpZGF0ZSB0aGUgaW50 ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy4NClNhbWUgYXBwbGllcyBpbiB5 b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuDQoNCg0KDQogICAg ICAgICA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVudCBoZXJlIG9ubHkgZm9yIFBNUyB0byBs ZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZQ0KICAgICAgICAgICAgY2FzZSBvZiBtaXhlZCBlbnY/ DQpbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24gdG8gc2V0 IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhlY3V0aW5nIGEgZGVzaXJlZCBjaGFpbiBv ZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9kZSByZWxhdGlvbiBpcyBrbm93biB0byB0 aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQ TVMgbW9uaXRvcmluZyBwYWNrZXQuDQolc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91 IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0cmFjZSB0byBnZXQg dG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2VkIGlu IFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFiZWwgc3RhY2suDQpB bmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBpcyB0aGF0LCBpdCBw ZXJmb3JtcyBvbiBkZW1hbmQgcGVyIHNlZ21lbnQsIHdoaWNoIFByb3h5IHBpbmcgYWxzbyBkb2Vz LCBhbGJlaXQgb25seSBmb3IgTVBMUyB0b3BvbG9neS4NClRoZSBjYXNlIHlvdSBhcmUgbWFraW5n IGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS4NCg0KUXVl c3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEgcGxhbmUgcGFja2V0cyBhcmUgZ2V0dGlu ZyBkcm9wcGVkIGFuZCBQTVMgcGFja2V0cyBnb2luZyB0aHJvdWdoLCBmb3IgYSBnaXZlbiBMU1Ag b3IgU2VnbWVudCwgaG93IGRvIHlvdSBrbm93IHRoZXJlIGlzIGEgcHJvYmxlbT8gaWYgeW91IGtu b3csIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBpdCBpcz8NCkF0IGxlYXN0IHdpdGggUkZD NDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIGJlY2F1 c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25nIHdpdGggdGhlIHBh Y2tldC4NCg0KDQoNCiAgICAgICAgIDYuIEluIHNlYyAzLjEsDQogICAgICAgICA8c25pcD4NCiAg ICAgICAgIERldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlvciB0byBhIG1lYXN1 cmVtZW50IG1heSBhbHNvIGJlDQogICAgICAgICBkb25lIGJ5IHNldHRpbmcgdXAgYSBsYWJlbCBp bmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IHBhdGgNCiAgICAgICAgIChpZiBMRVIx IGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxkIGJlIHBhc3NlZA0K ICAgICAgICAgYmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAt IDQwIC0gMzAgLSAxMCkuICBUaGUNCiAgICAgICAgIGFkdmFudGFnZSBvZiB0aGlzIG1ldGhvZCBp cywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNDQogICAgICAgICBmdW5jdGlvbmFs aXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gIFRoZQ0K ICAgICAgICAgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21iaW5h dGlvbnMgb2YgYWxsIHBhdGhzIG9mDQogICAgICAgICBhbiBNUExTIGRvbWFpbi4gIElmIGNvcnJl Y3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG8NCiAgICAgICAgIGJl IGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNvIGlu IHRoaXMNCiAgICAgICAgIGNhc2UuDQoNCiAgICAgICAgIDxlbmQgc25pcD4NCg0KICAgICAgICAg SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9B TS4gQnV0IGxhdGVyIHlvdSBzYXksDQogICAgICAgICBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgY291 bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IGNvdWxkIHlvdSB2ZXJpZnkgYQ0KICAg ICAgICAgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBNb3JlIHRleHQgd2ls bCBoZWxwLiBBbHNvLCBtb3JlDQogICAgICAgICBpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGll ciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUw0KICAgICAgICAgT0FN IGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRjLiBJZiBzbywgaXQg Y29udHJhZGljdHMgaGVyZS4NCltSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0DQotIHdpdGhv dXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVzIGEgc2V0IG9mIHBhdGhzIG9u bHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCi0gaWYgdGhlIG9wZXJhdG9y IHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVzcG9uZHMgdG8gY29udHJv bCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxpZWQuDQpJZiB5b3UgdW5k ZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRlcyBz b21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdvcmQgaXQuDQolc2FtIC0gVGhlIHBy b2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlvdSBo YXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQpJIGRlZmluaXRlbHkgc2VlIGEgc3BlY2lmaWMgbmVl ZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1c2UgY2FzZSBpcyB0b28gbXVj aCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1dGlvbi4NCk9uY2UgeW91IHJl bW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNob3VsZCBi ZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJlcXVp cmVtZW50cyBmb3IgYSBzb2x1dGlvbi4NCkZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVibGlz aCBhIHNlcGFyYXRlIElELg0KDQoNCiAgICAgICAgIDcuIExhc3QgYnV0IG5vdCB0aGUgbGVhc3Qs IGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFuZCBOTVM/DQogICAgICAgICBTb21laG93 IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQNCiAg ICAgICAgIE5NUy9FTVMgY291bGRuJ3QuDQpbUkddIEkndmUgbmV2ZXIgaGVhcmQgb2YgYW4gRU1T L05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCB1c2VzIHRoaXMgdG9wb2xvZ3kg YXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0aW5nIExTUCBjb21i aW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVu IGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29yayBmb3Igd291bGRuJ3Qg aGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQolc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNo IGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lm aWMgb3BlcmF0aW9ucyAgZm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5IHBlcmZvcm0gVHJl ZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0aXBhdGguIEFsc28gcGVyZm9ybSBMU1Ag c3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFi bGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0aCBtdWx0aXBhdGguIFlvdSBjb3VsZCBhdXRv bWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcg cHJvYmUgdGVjaG5vbG9neS4gV2lsbCBub3Qgc2F5IGJleW9uZCB0aGF0IDpEDQoNCmNoZWVycw0K LXNhbQ0KDQoNCg== --_000_CECE764681BE964CBE1DFF78F3CDD3941E262A73xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTYW0sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0 IHRvIHBvaW50IG91dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSB0ZXN0IHBhY2tldCBnZW5lcmF0ZWQgZnJvbSBhIFBNUy9OTVMvRU1TL25ldHdvcmstZGV2 aWNlIGNhbiBoYXZlIHRoZSBjb21wbGV0ZSBzZWdtZW50IHN0YWNrIG9uIGhvdyB0byB0cmF2ZXJz ZSB0aGUgbmV0d29yayBhcyB3ZWxsIGFzIGhvdyB0byBjb21lIGJhY2sgdG8NCiBzZWxmIHdpdGhv dXQgYW55IGZ1cnRoZXIgc2lnbmFsaW5nLCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0d29y ayBub2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGF0IG1ha2VzIHRoaXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkg TFNQIHBpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGNlcnRhaW5seSBoYXMgc29tZSBwcm9zIGFuZCBjb25z IGJ1dCBjYW4gYmUgcXVpdGUgdXNlZnVsIGFzIG9uZSBvZiB0aGUgT0FNcyAoeWVzIHBsdXJhbCkg dXNlZCB0byBtb25pdG9yIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U2FtIEFsZHJpbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgSnVseSAxMCwgMjAxNCAyOjEzIFBNPGJyPg0KPGI+VG86PC9iPiBSdWVkaWdlci5HZWli QHRlbGVrb20uZGU8YnI+DQo8Yj5DYzo8L2I+IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2Ft LXVzZWNhc2U8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSdWVk aWdlciw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5l LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAxMCwgMjAxNCBhdCA3OjE1IEFNLCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSIgdGFyZ2V0PSJfYmxhbmsi PlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU2FtLDxicj4NCjxicj4NCm15IHJlcGxpZXMgYXJlIG1h cmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuPGJyPg0KPGJyPg0KLSBQcm94eS1sc3At cGluZyBpcyBNUExTIG9ubHksIHdoaWxlIHRoZSBQTVMgYXJjaGl0ZWN0dXJlIGlzIGludGVuZGVk IGZvciBldmVyeSBTUiBkYXRhIHBsYW5lIChNUExTICYjNDM7IElQdjYpLiBXZSdsbCBjbGFyaWZ5 IHRoYXQgaW4gdGhlIGRyYWZ0Ljxicj4NCi0gUHJveHktbHNwLXBpbmcgaXMgZm9yIE1QTFMgTFNQ IFBpbmcgKFJGQyA0Mzc5IC8gUkZDIDY0MjQpLCB3aGlsZSBvdXIgdXNlIGNhc2UgY2FuIHVzZSBh bnkgT0FNIChpbiBwYXJ0aWN1bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9yIEJGRCwgYW5kIElD TVB2Nik8YnI+DQo8YnI+DQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGggYnJv YWRlciBzY29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JXNhbSAtIEkgYmVsaWV2 ZSB5b3Ugc2F5IGl0IGlzIHVzZSBjYXNlIGRvY3VtZW50IGJlbG93LiBUaGVuIHNvbHV0aW9uIGlz IHRvbyBwcmVtYXR1cmUgYXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyB3ZSBoYXZlbid0IGRlbGli ZXJhdGVkIG9uIHRoZSByZXF1aXJlbWVudHMgZWl0aGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQXMgeW91IHdy aXRlLCBTUiBiYXNlZCBPQU0gcGFydGlhbGx5IG9mZmVycyBzaW1pbGFyIGZ1bmN0aW9ucyBhcyBw cm94eS1sc3AuIFdpdGhvdXQgcmVxdWlyaW5nIHRoZSBhZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBM RVIvTFNSIHByb2Nlc3NpbmcgaW50cm9kdWNlZCBieSBwcm94eS1sc3AuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpSdWVkaWdlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2FtIEFsZHJpbiB3cm90ZTo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyBJIGhhdmUgZmV3IHF1ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0 Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDEuIFRoZSB0aXRsZSBpcyBjb25mdXNp bmcgdG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgaXQgc2F5cyB0aGUgZm9sbG93aW5nPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmx0O3NuaXAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3Rh dGVtZW50IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lsbHVzdHJhdGVzIGl0 IHdpdGggdXNlLWNhc2VzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Ro ZSBzb2x1dGlvbiBpcyBkZXNjcmliZWQgZm9yIGEgc2luZ2xlIElHUCBNUExTIGRvbWFpbi48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc29sdXRpb24gYXBwbGllcyB0 byBtb25pdG9yaW5nIG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bW9uaXRvcmluZyBvZiBTZWdtZW50IFJvdXRlZCBMU1Ancy48YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZW5kIHNuaXAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7SW4gZmFjdCB0aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNvbHV0 aW9uIHRvIGNlcnRhaW4gc2NlbmFyaW9zIGFuZCBub3QganVzdDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3Byb3ZpZGluZyB1c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5k aW5nIHdhcywgdXNlIGNhc2UgZHJhZnQgc2hvdWxkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZG9jdW1lbnQgc2NlbmFyaW9zIHdoZXJlIGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVpcmVt ZW50cy4gU29sdXRpb25zIGNvdWxkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUg Y292ZXJlZCB3aXRoIGV4aXN0aW5nIHRvb2xzZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5n IG9uIHRoZSBHQVA8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmFseXNpcy4gQnV0 IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhhbiAxIHNv bHV0aW9uLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZXJlIGFzIHRoaXMgZG9j dW1lbnQgY291bGQganVzdCBmb2N1cyBvbiB1c2UgY2FzZXMgb25seS48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJZiBpbmZhY3QgdGhpcyBpcyBzdXBwb3NlZCB0byBiZSBh IHNvbHV0aW9uIGRvY3VtZW50LCB0aGVuIGNoYW5naW5nIHRoZSB0aXRsZTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3dvdWxkIGJlIG1vcmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15IG9i c2VydmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b UkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZpZXcgdGhlIHRl eHQgb2Ygc2VjdGlvbiAxLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0gLSBPSy4gdGhlbiBJJ2QgbGlrZSB0byBzZWUgYW55IHNw ZWNpZmljIHNvbHV0aW9uIGNvbnRlbnQgcmVtb3ZlZCwgdGhhdCB3YXkgd2UgZG9udCBoYXZlIHRv IGRpc2N1c3Mgd2hhdCBvdGhlciBzb2x1dGlvbnMgZG9lcyBlaXRoZXIgb3IgY29tcGFyZSB3aXRo IDpEPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzIuIHcuci50LiBTZWN0aW9uIG51bWJlciAjMiwgdGhlIHNhbWUg cHJvYmxlbSBpcyBiZWluZyBzb2x2ZWQgd2l0aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZxdW90O2RyYWZ0LWlldGYtbXBscy1wcm94eS1sc3AtcGluZy0wMiZxdW90OyAuIFdoYXQg aXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJveHkgcGluZyhzb2x1dGlvbiB3aXNl KSB3aGVyZSwgcmVxdWVzdCBjb3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jl IHNlbnQgdG8gbW9uaXRvciBMRVIgaSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMg bXkgdW5kZXJzdGFuZGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JpZ2h0PyBJ ZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+W1JHXSBUaGUgUE1TIGlzIGFibGUgdG8gc2V0IHVwIHBhY2tl dHMgd2hpY2ggc3RheSBpbiBkYXRhIHBsYW5lIGFuZCBleGVjdXRlIGEgZGVzaXJlZDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7Y2hhaW4gb2YgTVBMUyBMU1BzLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0gLSBFeGVjdXRlIHlv dSBtZWFuIHRyYXZlcnNlPyBvciBwZXJmb3JtIHNvbWV0aGluZyBlbHNlPyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K W1JHXSBQcm94eS1sc3Agc2F5czogVGhpcyBkb2N1bWVudCBkZWZpbmVzIHByb3RvY29sIGV4dGVu c2lvbnMgdG8gTVBMUyBwaW5nIFtSRkM0Mzc5XSB0bzxicj4NCiZuYnNwOyAmbmJzcDthbGxvdyBh IHRoaXJkIHBhcnR5IHRvIHJlbW90ZWx5IGNhdXNlIGFuIE1QTFMgRWNobyBSZXF1ZXN0IG1lc3Nh Z2UgdG88YnI+DQombmJzcDsgJm5ic3A7YmUgc2VudCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4g TFNQLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiVzYW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9ucywgJm5ic3A7aXQgaGFz IHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICZuYnNwO2FuZCBjYW5ub3QgY2xhaW0gdG8gYmUgdXNl IGNhc2UgZG9jdW1lbnQuIEFsc28gdGhpcyBkb2N1bWVudCBpcyBvbiBpbmZvcm1hdGlvbiB0cmFj ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0IGlmIHlvdSdkIGxpa2UgdG8g cmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55IExTUCwgeW91IGNv dWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBUaGUgUE1TIGhvd2V2ZXIgc2lt cGxpZmllcyBhbmQgYWRkczxicj4NCmZ1bmN0aW9uYWxpdHk6PGJyPg0KYSkgWW91IGRvbid0IG5l ZWQgYW4gYWRkaXRpb25hbCBwcm90b2NvbCBvciBmdW5jdGlvbmFsaXR5IGxpa2UgcHJveHktcGlu ZyB0byBjaGVjayBkYXRhPGJyPg0KJm5ic3A7ICZuYnNwO3BsYW5lIGxpdmVsaW5lc3MsIFJGQzQz NzkgaXMgZmluZS4gRGV1dHNjaGUgVGVsZWtvbSBvcGVyYXRlcyBhIFBNUyBpbXBsZW1lbnRhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4lc2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIGRhdGFwbGFuZSBhbmQg YWxzbyBmaW5kIG91dCBsb3QgbW9yZSBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0aW9uYWwgaW5mb3Jt YXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNoZWNrcy4gRm9yIGxpdmVuZXNzIGRldGVjdGlv biwgQkZEIGlzIHByZWZlcnJlZCB0b29sLCBhdGxlYXN0IGluIHByZXNlbnQgZGVwbG95bWVudHMu U28gYXJlIHlvdSBzYXlpbmcsDQogUE1TIHNvbHV0aW9uIGlzIGRlc2lnbmVkIGZvciBsaXZlbmVz cyBkZXRlY3Rpb24gYW5kIG5vdCB0byBwZXJmb3JtIHZhbGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0 byBjb250cm9sIHBsYW5lLCBldGM/IChJIHRoaW5rIHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBs YXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxzbyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Yikgb25jZSBQTVMgZGV0ZWN0ZWQgZGF0YSBw bGFuZSBsaXZlbGluZXNzIGFuZCBjb3JyZWN0bmVzcyBvZiBNUExTIHRvcG9sb2d5IGJ5IFJGQzQz NzksPGJyPg0KJm5ic3A7ICZuYnNwO2l0IGNhbiBjb250aW51ZSB0byBleGVjdXRlIGFyYml0cmFy eSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9uaXRvcmluZyBwYWNrZXRzIHN0YXk8YnI+DQom bmJzcDsgJm5ic3A7aW4gZGF0YSBwbGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0ZXh0IGlu IHByb3h5LXBpbmcgb2ZmZXJpbmcgdGhpcyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0gLSBUaGlzIHlvdSBjb3Vs ZCBwZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rpb24geW91IGFyZSBk ZXNjcmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGluZyByYXRoZXIgdGhhbiB3aGF0IGxzcCBw aW5nIGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9uLW1wbHMgdG9wb2xvZ3ku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBh bnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRo IHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5IGluZm88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRp c2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBwZXJmb3JtIHBp bmcgd2l0aCByaWdodCBzZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1p dGluZyB0aGUgaG9wIFtMRVIgal0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBM RVIgaiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgMy4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBNUyB3 aGljaCBpcyBub3QgcGFydCBvZiBNUExTIG9yIHNlZ21lbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0LCB3 aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91 IGJlIGRvY3VtZW50aW5nIHRoYXQgYXNwZWN0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bUkddIFRoYXQncyBhIHZhbGlkIHBvaW50LiBUaGUgZG9tYWluIGV4 dGVybmFsIHN5c3RlbSBpcyBvbmUgb3B0aW9uIGFuZCB0aGUgdGVhbSB3aWxsIGRlYWwgd2l0aCB0 aGUgc2VjdXJpdHkgYXNwZWN0cyByYWlzZWQgYnkgdGhpcyBvcHRpb24gb25jZSB3ZSBhcmUgaW4g c29sdXRpb24gc3BhY2UuIFdlIHdpbGwgbm90IGFuYWx5c2UgdGhpcyBpbiBkZXB0aCBmb3IgYSB1 c2UgY2FzZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4lc2FtIC0gbm9kJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNC4gU2Vj IDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRo IFJGQzQzNzkgcGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIG11bHRw YXRoICYjNDM7IHByb3h5IHBpbmcuIENvdWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0 aGVyZSBpcyBzb21ldGhpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV3IHRo ZSBzb2x1dGlvbiBicmluZ3MgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+W1JHXSBUaGUgU1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBwcm92aWRlZCB0ZXh0 IGhvdyB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91 IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkgY291bGRuJ3QgZmluZCBleHBsaWNpdCB0 ZXh0IG9uIGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gZHJhZnQt cHJveHktbHNwLiBQbGVhc2UgZGVzY3JpYmUNCiBob3cgcHJveHktbHNwIGNhbiBiZSB1c2VkIHRv IG1vbml0b3IgYSBidW5kbGVkIGxpbmsgKHNvcnJ5IGlmIHRoaXMgaXMgb2J2aW91cyBhbmQgSSBt aXNzZWQgaXQpLiBJZiB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgdG8gdGhlIFNSIE9BTSBhcHByb2Fj aCwgd2UnbGwgZGlzY3VzcyB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmliZWQg YWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIgaXMgaWRlbnRp ZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgdHJhY2Ugb3Ig cGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNwb25kIHdpdGggRERNQVAgaW5mbyBm b3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBhdGgNCiBpbmZvIGZvciB0aGUgc2Ft ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IHlvdSBzYXkgdGhhdCBlYWNoIGxpbmsgbWVtYmVyIGhhcyBzYW1lIGxhYmVsIHN0YWNrLCB0aGVu IHlvdSBjb3VsZCB1c2UgbHNwIHNlbGVjdG9ycyBhcyBkZWZpbmVkIGluIFJGQzQzNzksIGluIHRo aXMgY2FzZSBpdCBpcyBsb2NhbCBob3N0IGRlc3QgaXAgYWRkciwgdG8gaWRlbnRpZnkgZWFjaCBs aW5rIG1lbWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5vdyBpZiB0aGUgTVBMUyBmb3J3YXJkaW5nIGxheWVyIHNlZXMgdGhlIGJ1bmRsZWQg bGluayBhcyBvbmUgaW50ZXJmYWNlIGJ1dCBjYW5ub3QgZGlzY2VybiBpdHMgbGluayBtZW1iZXJz LCB0aGVuIHlvdSBjb3VsZCBvbmx5IHZhbGlkYXRlIHRoZSBpbnRlcmZhY2UgYW5kIG5vdCBpdHMg aW5kaXZpZHVhbCBtZW1iZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2FtZSBhcHBsaWVzIGluIHlvdXIgY2FzZSB0b28uIENhbm5vdCBzZWUg aG93IGl0IGlzIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzUuIHNlYyAj NSwgSXMgdGhlIHJlcXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3Bv bG9neSwgaW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgY2FzZSBvZiBtaXhlZCBlbnY/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPltSR10gTVBMUyB0b3BvbG9neSBhd2FyZW5lc3MgaXMgdGhlIHByZWNvbmRpdGlv biB0byBzZXQgdXAgcGFja2V0cyB3aXRoIGxhYmVsIHN0YWNrcyBleGVjdXRpbmcgYSBkZXNpcmVk IGNoYWluIG9mIExTUHMuIElmIHN1aXRhYmxlIExhYmVsL0ZFQy9ub2RlIHJlbGF0aW9uIGlzIGtu b3duIHRvIHRoZSBQTVMsIHRoYXQgTFNQIGNhbiBiZSBleGVjdXRlZCBmcm9tIHRoYXQgbm9kZSBv biBieSBhIFBNUyBtb25pdG9yaW5nDQogcGFja2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiVzYW0gLSBTbywgeW91IGFyZSBzYXlp bmcgdGhhdCB5b3Ugc3RpbGwgbmVlZCB0byBwZXJmb3JtIFJGQzQzNzkgdHJhY2Ugb3IgdHJlZXRy YWNlIHRvIGdldCB0b3BvbG9neS4gSSBkbyBub3QgdGhpbmsgSUdQIGV4dGVuc2lvbnMgYmVpbmcg cHJvcG9zZWQgaW4gU1BSSU5HIGV4cG9ydCBhbnkgb2YgdGhlIGluZm8gb3RoZXIgdGhhbiBsYWJl bCBzdGFjay4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFuZCB0aGUgcHJvcG9zZWQgUE1TIHNvbHV0aW9uIChub3QgdXNlIGNhc2UpIGlz IHRoYXQsIGl0IHBlcmZvcm1zIG9uIGRlbWFuZCBwZXIgc2VnbWVudCwgd2hpY2ggUHJveHkgcGlu ZyBhbHNvIGRvZXMsIGFsYmVpdCBvbmx5IGZvciBNUExTIHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNhc2UgeW91IGFyZSBt YWtpbmcgaXMgdGhhdCBubyBuZWVkIG9mIGJlbGxzIGFuZCB3aGlzdGxlcyBvZiBSRkM0Mzc5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWVz dGlvbiBJIGhhdmUgZm9yIHlvdSBpcywgaWYgZGF0YSBwbGFuZSBwYWNrZXRzIGFyZSBnZXR0aW5n IGRyb3BwZWQgYW5kIFBNUyBwYWNrZXRzIGdvaW5nIHRocm91Z2gsIGZvciBhIGdpdmVuIExTUCBv ciBTZWdtZW50LCBob3cgZG8geW91IGtub3cgdGhlcmUgaXMgYSBwcm9ibGVtPyBpZiB5b3Uga25v dywgaG93IGRvIHlvdSBmaWd1cmUgb3V0IHdoZXJlIGl0IGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgbGVhc3Qgd2l0aCBSRkM0Mzc5IGFu ZC9vciBwcm94eSBwaW5nLCB5b3UgY291bGQgdmFsaWRhdGUgZWFjaCBob3AgYmVjYXVzZSBvZiB0 aGUgYmVsbHMgYW5kIHdoaXN0bGVzIGl0IGNhcnJpZXMgYWxvbmcgd2l0aCB0aGUgcGFja2V0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ni4gSW4gc2VjIDMuMSw8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3NuaXAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0RldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlv ciB0byBhIG1lYXN1cmVtZW50IG1heSBhbHNvIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RvbmUgYnkgc2V0dGluZyB1cCBhIGxhYmVsIGluY2x1ZGluZyBhbGwgbm9k ZSBTSURzIGFsb25nIHRoYXQgcGF0aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsoaWYgTEVSMSBoYXMgTm9kZSBTSUQgNDAgaW4gdGhlIGV4YW1wbGUgYW5kIGl0IHNob3Vs ZCBiZSBwYXNzZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmV0d2Vl biBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAtIDQwIC0gMzAgLSAxMCku ICZuYnNwO1RoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZHZhbnRh Z2Ugb2YgdGhpcyBtZXRob2QgaXMsIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmdW5jdGlvbmFsaXR5IGFuZCBp dCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gJm5ic3A7VGhlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21ldGhvZCBzdGlsbCBpcyBhYmxlIHRv IG1vbml0b3IgYWxsIGxpbmsgY29tYmluYXRpb25zIG9mIGFsbCBwYXRocyBvZjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbiBNUExTIGRvbWFpbi4gJm5ic3A7SWYgY29y cmVjdCBmb3J3YXJkaW5nIGFsb25nIHRoZSBkZXNpcmVkIHBhdGhzIGhhcyB0bzxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBjaGVja2VkLCBSRkM0NzM5IGZ1bmN0aW9u YWxpdHkgc2hvdWxkIGJlIGFwcGxpZWQgYWxzbyBpbiB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDtlbmQgc25pcCZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBu b3QgaW52b2x2ZSBNUExTIE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JGQzQzNzkgZnVuY3Rpb25hbGl0eSBjb3VsZCBiZSB1c2Vk LiBDb3VsZCB5b3UgY2xhcmlmeSBob3cgY291bGQgeW91IHZlcmlmeSBhPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhdGgsIGlmIE1QTFMgdmFsaWRhdGlvbiBpcyBub3Qg ZG9uZS4gTW9yZSB0ZXh0IHdpbGwgaGVscC4gQWxzbywgbW9yZTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGllciB0byB0aGUg YWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUzxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtPQU0gaGFzIHRvIGJlIHBlcmZvcm1lZCBmb3IgdG9wb2xvZ3kgY2hh bmdlcyBldGMuIElmIHNvLCBpdCBjb250cmFkaWN0cyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bUkddIFRoZSB0ZXh0IHNob3VsZCBzYXkgdGhhdDxi cj4NCi0gd2l0aG91dCBNUExTIE9BTSBmdW5jdGlvbnMsIHRoZSBQTVMgZXhlY3V0ZXMgYSBzZXQg b2YgcGF0aHMgb25seSBiYXNlZCBvbiBjb250cm9sIHBsYW5lIGluZm9ybWF0aW9uLjxicj4NCi0g aWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVz cG9uZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxp ZWQuPGJyPg0KSWYgeW91IHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQgYW5kIHRoZSB0ZXh0IGlu IHRoZSBkcmFmdCBzdGF0ZXMgc29tZXRoaW5nIGRpZmZlcmVudCwgSSdsbCB0cnkgdG8gcmV3b3Jk IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiVzYW0gLSBUaGUgcHJvYmxlbSBJIGFtIGhhdmluZyBpcywgaW4gdGhlIGNhc2Ugb2Yg TVBMUywgZm9yIE9BTSwgeW91IGhhdmUgdG8gdmFsaWRhdGUgdGhlIGxzcC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGVmaW5pdGVseSBzZWUg YSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVlbCBpcywgdGhlIHVzZSBj YXNlIGlzIHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZpc2lvbmVkIHNvbHV0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25j ZSB5b3UgcmVtb3ZlIHNvbHV0aW9uIG9yIHN1Z2dlc3RlZCBlbmhhbmNlbWVudHMsIGhvcGUgaXQg c2hvdWxkIGJlIGNsZWFyIG9uIHdoYXQgaXMgYmVpbmcgc29sdmVkIGFuZCBzY29wZSBvdXQgY2xl YXIgcmVxdWlyZW1lbnRzIGZvciBhIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHNvbHV0aW9uIHBhcnQsIHBsZWFzZSBwdWJs aXNoIGEgc2VwYXJhdGUgSUQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs3LiBMYXN0IGJ1dCBub3Qg dGhlIGxlYXN0LCBob3cgZGlmZmVyZW50IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTb21laG93IEkgY291bGRuJ3QgZmluZCB0 aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Tk1TL0VNUyBjb3VsZG4ndC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9O TVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3 YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmlu YXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUgYmVlbiBj b21tZXJjaWFsbHkgYXZhaWxhYmxlLCB0aGUgY29tcGFueQ0KIEkgd29yayBmb3Igd291bGRuJ3Qg aGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JXNhbSAtIFRoZXJlIGFyZSB0b29scyB3aGlj aCBhcmUgcGFydCBvZiBOTVMvT1NTLCB3aGljaCBwZXJmb3JtcyBNUExTIHRvcG9sb2d5IHNwZWNp ZmljIG9wZXJhdGlvbnMgJm5ic3A7Zm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5IHBlcmZv cm0gVHJlZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0aXBhdGguIEFsc28gcGVyZm9y bSBMU1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBwYWNrZXRzDQogd2l0aCBkYXRh IGF2YWlsYWJsZSB3aXRoIHRyZWV0cmFjZSBhbmQgcGluZyB3aXRoIG11bHRpcGF0aC4gWW91IGNv dWxkIGF1dG9tYXRlIHRoZSB3b3JrZmxvdyB3aXRob3V0IHRoZSBuZWVkIGZvciBPU1MvUE1TLCBi eSB1c2luZyBwcm9iZSB0ZWNobm9sb2d5LiBXaWxsIG5vdCBzYXkgYmV5b25kIHRoYXQgOkQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hlZXJz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tc2Ft PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_CECE764681BE964CBE1DFF78F3CDD3941E262A73xmbalnx01ciscoc_-- From nobody Thu Jul 10 12:10:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809E71B297E for ; Thu, 10 Jul 2014 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_jvK31Z_ABf for ; Thu, 10 Jul 2014 12:10:03 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DC1A854D for ; Thu, 10 Jul 2014 12:10:03 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id x13so18860qcv.40 for ; Thu, 10 Jul 2014 12:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cnIorTxohMedlmjBLdt4V2KexSqSsomCLPABIbQPLN4=; b=pDkdy5SbxwrEsbDVG87H6tUMhsWSKb6sam2F59WxEgh4eTl7PMhuxv+gZK3z9udpi6 jOD8nQvQuhQ+CcPR+u/9+lvUdW4KoCwQeBhYqDhe1n+4fKC4mJTD5vbXR6E84yA5etoS GvQ7Vy82sXwCepE0qAou8bnvgK+6OwvoRP8qrZ01z64HdPGfU8RBOg7r8z78lAe8XbbY xhY1rUChis3kc+y4bfukIuajGdFRNYNGGezqVSri8DeX82YU5n0q4kfceLbeCuRmFTTU yrdA6DJUny76BXZftDR0Jy5SrxnykNLdrZcrod1P6PeSv9GbEApNm0UJH5UXn19SU1zC AbAA== MIME-Version: 1.0 X-Received: by 10.140.48.75 with SMTP id n69mr17446220qga.107.1405019402324; Thu, 10 Jul 2014 12:10:02 -0700 (PDT) Received: by 10.96.70.106 with HTTP; Thu, 10 Jul 2014 12:10:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jul 2014 12:10:02 -0700 Message-ID: From: Sam Aldrin To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a11351db060d1d204fddb9237 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/YMtGFN6xYneSZv6ak-P9R5NwZ-U Cc: "Ruediger.Geib@telekom.de" , draft-geib-spring-oam-usecase , spring Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:10:07 -0000 --001a11351db060d1d204fddb9237 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nobo, Inline for my comments. On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) wrote: > Hi Sam, > > > > Just to point out one thing about this document =E2=80=A6 > > > > The test packet generated from a PMS/NMS/EMS/network-device can have the > complete segment stack on how to traverse the network as well as how to > come back to self without any further signaling, OAM state maintenance on > network nodes nor OAM involvement by network nodes. > That is fine as a requirement/usecase and we should limit the scope to that, than specifying how to solve it. > > > That makes this approach quite different from using proxy LSP ping. > You are talking about solution or use case? :D > > > This certainly has some pros and cons but can be quite useful as one of > the OAMs (yes plural) used to monitor the network. > Certainly. But I am struggling between use case and solution outlined in the document. Pick one :D -sam > > > Thanks! > > > > -Nobo > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Sam Aldrin > *Sent:* Thursday, July 10, 2014 2:13 PM > *To:* Ruediger.Geib@telekom.de > *Cc:* spring; draft-geib-spring-oam-usecase > *Subject:* Re: [spring] Questions > > > > Hi Ruediger, > > > > Thanks for the quick response. Please find my responses inline. > > > > On Thu, Jul 10, 2014 at 7:15 AM, wrote: > > Hi Sam, > > my replies are marked [RG] and added to your text. > > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for > every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our us= e > case can use any OAM (in particular, specific good uses for BFD, and ICMP= v6) > > Based on that, it=C2=B9s a solution with broader scope and better fit for > SPRING as a whole. > > %sam - I believe you say it is use case document below. Then solution is > too premature at this point of time, as we haven't deliberated on the > requirements either. > > > As you write, SR based OAM partially offers similar functions as > proxy-lsp. Without requiring the additional messages and LER/LSR processi= ng > introduced by proxy-lsp. > > > Regards, > > Ruediger > > > > Sam Aldrin wrote: > > I have few questions about this draft. > > 1. The title is confusing to me. It says OAM use case but in sectio= n > #1 > it says the following > > > This document describes a solution to this problem statement and > illustrates it with use-cases. > > The solution is described for a single IGP MPLS domain. > > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > > > In fact the draft is describing a solution to certain scenarios an= d > not just > providing use cases/scenarios. My understanding was, use case draf= t > should > document scenarios where it will drive new requirements. Solutions > could > be covered with existing toolset or defined newly, depending on th= e > GAP > analysis. But that should be separate as there could be more than = 1 > solution, > where as this document could just focus on use cases only. > > If infact this is supposed to be a solution document, then changin= g > the title > would be more meaningful. That's my observation. > > [RG] Thanks. It's a use case document. We'll review the text of section 1= . > > %sam - OK. then I'd like to see any specific solution content removed, > that way we dont have to discuss what other solutions does either or > compare with :D > > > > > 2. w.r.t. Section number #2, the same problem is being solved with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in > this > section could be done with the proxy ping(solution wise) where, > request could > be sent to monitor LER i and LER j segment, from a PMS. Is my > understanding > right? If not, how is it different here? > > [RG] The PMS is able to set up packets which stay in data plane and > execute a desired > chain of MPLS LSPs. > > %sam - Execute you mean traverse? or perform something else? > > > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS > ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message to > be sent down a LSP or part of an LSP. > > %sam - If it is proposing extensions, it has to be solution document > and cannot claim to be use case document. Also this document is on > information track. > > > [RG] I take it as saying that if you'd like to remotely execute RFC4379 > functionality on any LSP, you could either use the PMS or proxy-ping. The > PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like proxy-ping > to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS > implementation. > > %sam - RFC4379 performs validation of dataplane and also find out lot > more errors. You need additional information to perform validation checks= . > For liveness detection, BFD is preferred tool, atleast in present > deployments.So are you saying, PMS solution is designed for liveness > detection and not to perform validation of data plane to control plane, > etc? (I think you agree to this in the later part of the doc also) > > > > b) once PMS detected data plane liveliness and correctness of MPLS > topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the > monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering this > feature. > > %sam - This you could perform even without proxy ping. The function you > are describing is, how you use lsp ping rather than what lsp ping does. > Again I am not talking about non-mpls topology. > > To answer your question, how you perform. > > - Perform treetrace with rfc4379 to get topology info > > - pick any arbitary LSP paths discovered along with its multipath > implementation. > > - perform ping with right selectors for the path and use TTL for limiting > the hop [LER j]. > > - if you want to perform from LER i to LER j as in your draft, use proxy > ping to start from LER i > > > 3. When the response is sent back to PMS which is not part of MPL= S > or segment > domain, there is a serious security aspect, which needs to > considered. I believe > it applies to sending a request too. Will you be documenting that > aspect? > > [RG] That's a valid point. The domain external system is one option and > the team will deal with the security aspects raised by this option once w= e > are in solution space. We will not analyse this in depth for a use case > document. > > %sam - nod > > > 4. Sec 3.2 to monitor bundle links, one could perform that with > RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if > there is something > new the solution brings here? > > [RG] The SR OAM author team has provided text how to monitor a bundled > link in the use case draft. You are a co-author of proxy-lsp. I couldn't > find explicit text on how to detect and monitor a bundled link in > draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a > bundled link (sorry if this is obvious and I missed it). If there are > differences to the SR OAM approach, we'll discuss them. > > %sam - The same steps described above could be used if each bundled link > member is identified with a unique label. While performing tree trace or > ping with multipath, LER i will respond with DDMAP info for each of the > links and the multipath info for the same. > > If you say that each link member has same label stack, then you could use > lsp selectors as defined in RFC4379, in this case it is local host dest i= p > addr, to identify each link member. > > Now if the MPLS forwarding layer sees the bundled link as one interface > but cannot discern its link members, then you could only validate the > interface and not its individual members. > > Same applies in your case too. Cannot see how it is different. > > > > > > 5. sec #5, Is the requirement here only for PMS to learn the > topology, in the > case of mixed env? > > [RG] MPLS topology awareness is the precondition to set up packets with > label stacks executing a desired chain of LSPs. If suitable Label/FEC/nod= e > relation is known to the PMS, that LSP can be executed from that node on = by > a PMS monitoring packet. > > %sam - So, you are saying that you still need to perform RFC4379 trace > or treetrace to get topology. I do not think IGP extensions being propose= d > in SPRING export any of the info other than label stack. > > And the proposed PMS solution (not use case) is that, it performs on > demand per segment, which Proxy ping also does, albeit only for MPLS > topology. > > The case you are making is that no need of bells and whistles of RFC4379. > > > > Question I have for you is, if data plane packets are getting dropped and > PMS packets going through, for a given LSP or Segment, how do you know > there is a problem? if you know, how do you figure out where it is? > > At least with RFC4379 and/or proxy ping, you could validate each hop > because of the bells and whistles it carries along with the packet. > > > > > > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may als= o > be > done by setting up a label including all node SIDs along that pa= th > (if LER1 has Node SID 40 in the example and it should be passed > between LER i and LER j, the label stack is 20 - 40 - 30 - 10). > The > advantage of this method is, that it does not involve MPLS OAM > functionality and it is independent of ECMP functionalities. Th= e > method still is able to monitor all link combinations of all > paths of > an MPLS domain. If correct forwarding along the desired paths > has to > be checked, RFC4739 functionality should be applied also in this > case. > > > > In the above you mention that it does not involve MPLS OAM. But > later you say, > RFC4379 functionality could be used. Could you clarify how could > you verify a > path, if MPLS validation is not done. More text will help. Also, > more > importantly, the text earlier to the above says, for valid > result, MPLS > OAM has to be performed for topology changes etc. If so, it > contradicts here. > > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only based > on control plane information. > - if the operator wants to make sure that data plane corresponds to > control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states > something different, I'll try to reword it. > > %sam - The problem I am having is, in the case of MPLS, for OAM, you > have to validate the lsp. > > I definitely see a specific need for SPRING, but what I feel is, the use > case is too much catered to a specific envisioned solution. > > Once you remove solution or suggested enhancements, hope it should be > clear on what is being solved and scope out clear requirements for a > solution. > > For solution part, please publish a separate ID. > > > > > 7. Last but not the least, how different is PMS from EMS and NMS= ? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. > > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses > this topology awareness to create data plane packets executing LSP > combinations as desired by an operator. Had this feature been commerciall= y > available, the company I work for wouldn't have been developing a PMS. > > %sam - There are tools which are part of NMS/OSS, which performs MPLS > topology specific operations for a given set of LSP's. They perform > Treetrace and perform ping with multipath. Also perform LSP specific > validation by crafting packets with data available with treetrace and pin= g > with multipath. You could automate the workflow without the need for > OSS/PMS, by using probe technology. Will not say beyond that :D > > > > cheers > > -sam > > > > > --001a11351db060d1d204fddb9237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Inline for my comments.
<= div class=3D"gmail_extra">

On Thu, Jul 10= , 2014 at 11:59 AM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:

Hi Sam,

=C2=A0

Just to point out one thi= ng about this document =E2=80=A6

=C2=A0

The test packet generated= from a PMS/NMS/EMS/network-device can have the complete segment stack on h= ow to traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network nodes= nor OAM involvement by network nodes.

<= div>That is fine as a requirement/usecase and we should limit the scope to = that, than specifying how to solve it.

=C2=A0

That makes this approach = quite different from using proxy LSP ping.

You are talking about solution or use case? :D
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

This certainly has some p= ros and cons but can be quite useful as one of the OAMs (yes plural) used t= o monitor the network.

Certainly. But I am struggling between use ca= se and solution outlined in the document. Pick one :D

<= div>-sam=C2=A0

=C2=A0

Thanks!

=C2=A0

-Nobo

=C2=A0

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Thursday, July 10, 2014 2:13 PM
To: Ru= ediger.Geib@telekom.de
Cc: spring; draft-geib-spring-oam-usecase
Subject: Re: [spring] Questions

=C2=A0

Hi Ruediger,

=C2=A0

Thanks for the quick response. Please find my respon= ses inline.

=C2=A0<= /p>

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de= > wrote:

Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=C2=B9s a solution with broader scope and better fit for S= PRING as a whole.=C2=A0

%sam - I believe you say it is use case document bel= ow. Then solution is too premature at this point of time, as we haven't= deliberated on the requirements either.=C2=A0


As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp.=C2=A0


Regards,

Ruediger



=C2=A0 =C2=A0 =C2=A0 Sam Aldrin wrote:

=C2=A0 =C2=A0 =C2=A0 I have few questions about this draft.

=C2=A0 =C2=A0 =C2=A0 1. The title is confusing to me. It says OAM use case = but in section #1
=C2=A0 =C2=A0 =C2=A0 it says the following

=C2=A0 =C2=A0 =C2=A0 <snip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document describes a solution to this probl= em statement and
=C2=A0 =C2=A0 =C2=A0 =C2=A0illustrates it with use-cases.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The solution is described for a single IGP MPLS = domain.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The solution applies to monitoring of LDP LSP= 9;s as well as to
=C2=A0 =C2=A0 =C2=A0 =C2=A0monitoring of Segment Routed LSP's.
=C2=A0 =C2=A0 =C2=A0 <end snip>

=C2=A0 =C2=A0 =C2=A0 =C2=A0In fact the draft is describing a solution to ce= rtain scenarios and not just
=C2=A0 =C2=A0 =C2=A0 =C2=A0providing use cases/scenarios. My understanding = was, use case draft should
=C2=A0 =C2=A0 =C2=A0 =C2=A0document scenarios where it will drive new requi= rements. Solutions could
=C2=A0 =C2=A0 =C2=A0 =C2=A0be covered with existing toolset or defined newl= y, depending on the GAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0analysis. But that should be separate as there c= ould be more than 1 solution,
=C2=A0 =C2=A0 =C2=A0 =C2=A0where as this document could just focus on use c= ases only.

=C2=A0 =C2=A0 =C2=A0 =C2=A0If infact this is supposed to be a solution docu= ment, then changing the title
=C2=A0 =C2=A0 =C2=A0 =C2=A0would be more meaningful. That's my observat= ion.

[RG] Thanks. It's a use case document. We'll= review the text of section 1.

%sam - OK. then I'd like to see any specific sol= ution content removed, that way we dont have to discuss what other solution= s does either or compare with :D

=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A02. w.r.t. Section number #2, the same problem is= being solved with
=C2=A0 =C2=A0 =C2=A0 =C2=A0"draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0section could be done with the proxy ping(soluti= on wise) where, request could
=C2=A0 =C2=A0 =C2=A0 =C2=A0be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
=C2=A0 =C2=A0 =C2=A0 =C2=A0right? If not, how is it different here?<= u>

[RG] The PMS is able to set up packets which stay in= data plane and execute a desired
=C2=A0 =C2=A0 =C2=A0chain of MPLS LSPs.

%sam - Execute you mean traverse? or perform somethi= ng else?=C2=A0


[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
=C2=A0 =C2=A0allow a third party to remotely cause an MPLS Echo Request mes= sage to
=C2=A0 =C2=A0be sent down a LSP or part of an LSP.

%sam - If it is proposing extensions, =C2=A0it has t= o be solution document =C2=A0and cannot claim to be use case document. Also= this document is on information track.


[RG] I take it as saying that if you'd like to remotely execute RFC4379= functionality on any LSP, you could either use the PMS or proxy-ping. The = PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-pi= ng to check data
=C2=A0 =C2=A0plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.

%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to perform v= alidation checks. For liveness detection, BFD is preferred tool, atleast in= present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validat= ion of data plane to control plane, etc? (I think you agree to this in the = later part of the doc also)

=C2=A0

b) once PMS detected data plane liveliness and corre= ctness of MPLS topology by RFC4379,
=C2=A0 =C2=A0it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
=C2=A0 =C2=A0in data plane. Please point me to the text in proxy-ping offer= ing this feature.

%sam - This you could perform even without proxy pin= g. The function you are describing is, how you use lsp ping rather than wha= t lsp ping does. Again I am not talking about non-mpls topology.<= /u>

To answer your question, how you perform.<= /u>

- Perform treetrace with rfc4379 to get topology inf= o

- pick any arbitary LSP paths discovered along with = its multipath implementation.

- perform ping with right selectors for the path and= use TTL for limiting the hop [LER j].

- if you want to perform from LER i to LER j as in y= our draft, use proxy ping to start from LER i


=C2=A0 =C2=A0 =C2=A0 =C2=A0 3. When the response is sent back to PMS which = is not part of MPLS or segment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain, there is a serious security aspect, whi= ch needs to considered. I believe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external s= ystem is one option and the team will deal with the security aspects raised= by this option once we are in solution space. We will not analyse this in = depth for a use case document.

%sam - nod=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 with multpath + proxy ping. Could you kindly di= fferentiate if there is something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 new the solution brings here?

[RG] The SR OAM author team has provided text how to= monitor a bundled link in the use case draft. You are a co-author of proxy= -lsp. I couldn't find explicit text on how to detect and monitor a bund= led link in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is obvi= ous and I missed it). If there are differences to the SR OAM approach, we&#= 39;ll discuss them.

%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While perfor= ming tree trace or ping with multipath, LER i will respond with DDMAP info = for each of the links and the multipath info for the same.

If you say that each link member has same label stac= k, then you could use lsp selectors as defined in RFC4379, in this case it = is local host dest ip addr, to identify each link member.

Now if the MPLS forwarding layer sees the bundled li= nk as one interface but cannot discern its link members, then you could onl= y validate the interface and not its individual members.

Same applies in your case too. Cannot see how it is = different.

=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case of mixed env?<= /p>

[RG] MPLS topology awareness is the precondition to = set up packets with label stacks executing a desired chain of LSPs. If suit= able Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet.

%sam - So, you are saying that you still need to per= form RFC4379 trace or treetrace to get topology. I do not think IGP extensi= ons being proposed in SPRING export any of the info other than label stack.= =C2=A0

And the proposed PMS solution (not use case) is that= , it performs on demand per segment, which Proxy ping also does, albeit onl= y for MPLS topology.

The case you are making is that no need of bells and= whistles of RFC4379.

=C2=A0

Question I have for you is, if data plane packets ar= e getting dropped and PMS packets going through, for a given LSP or Segment= , how do you know there is a problem? if you know, how do you figure out wh= ere it is?

At least with RFC4379 and/or proxy ping, you could v= alidate each hop because of the bells and whistles it carries along with th= e packet.

=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06. In sec 3.1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<snip>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Determining a path to be executed prior t= o a measurement may also be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0done by setting up a label including all = node SIDs along that path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if LER1 has Node SID 40 in the example a= nd it should be passed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0between LER i and LER j, the label stack = is 20 - 40 - 30 - 10). =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0advantage of this method is, that it does= not involve MPLS OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functionality and it is independent of EC= MP functionalities. =C2=A0The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0method still is able to monitor all link = combinations of all paths of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an MPLS domain. =C2=A0If correct forwardi= ng along the desired paths has to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be checked, RFC4739 functionality should = be applied also in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<end snip>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the above you mention that it does not= involve MPLS OAM. But later you say,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC4379 functionality could be used. Coul= d you clarify how could you verify a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path, if MPLS validation is not done. Mor= e text will help. Also, more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0importantly, the text earlier to the abov= e says, for valid result, MPLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.

%sam - The problem I am having is, in the case of MP= LS, for OAM, you have to validate the lsp.

I definitely see a specific need for SPRING, but wha= t I feel is, the use case is too much catered to a specific envisioned solu= tion.

Once you remove solution or suggested enhancements, = hope it should be clear on what is being solved and scope out clear require= ments for a solution.

For solution part, please publish a separate ID.<= /u>

=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A07. Last but not the least, how different = is PMS from EMS and NMS?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Somehow I couldn't find the differenc= e what PMS could do and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPL= S topology aware and uses this topology awareness to create data plane pack= ets executing LSP combinations as desired by an operator. Had this feature = been commercially available, the company I work for wouldn't have been developing a PMS.

%sam - There are tools which are part of NMS/OSS, wh= ich performs MPLS topology specific operations =C2=A0for a given set of LSP= 's. They perform Treetrace and perform ping with multipath. Also perfor= m LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could auto= mate the workflow without the need for OSS/PMS, by using probe technology. = Will not say beyond that :D

=C2=A0

cheers

-sam

=C2=A0

=C2=A0


--001a11351db060d1d204fddb9237-- From nobody Thu Jul 10 12:46:26 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF261B29AC for ; Thu, 10 Jul 2014 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.551 X-Spam-Level: X-Spam-Status: No, score=-114.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC2tW696udWp for ; Thu, 10 Jul 2014 12:46:20 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198CA1B29A8 for ; Thu, 10 Jul 2014 12:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60960; q=dns/txt; s=iport; t=1405021583; x=1406231183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dFw+lNmNbWLCOA5KY0HIcGIsihR9mEIm7P3a3ZrtVcI=; b=hm/dYMRoALPqxDe0UFOG5ZbZCMc0nyDuNH0hL5Mhx8Rt2miKvHWh8wRP cDo4EJcozaDHr7D/zYRUgk7irAn81VEJfhYfiNbRMFwagbLU83c4iAFNL fnSsUhoZl0UMw6ZAFRc8jWrrjqQvlsuUeumulRzjQIl8yX/RctFgzzk/p Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAM7svlOtJV2R/2dsb2JhbABPCoJHIyRSWoJvvXaHSgEZdRZ1hAMBAQEEGgkKOgsHEAIBCBEBAwEBCxYBBgMCAgIfERQDBggCBA4FCBOIEwMRAa4Mkg0NhxgXjRmBTwUmBgckBgECBAOCbjaBFgWZAINIjDmGFINDgW8BHgYc X-IronPort-AV: E=Sophos; i="5.01,639,1400025600"; d="scan'208,217"; a="59879196" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-8.cisco.com with ESMTP; 10 Jul 2014 19:46:22 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6AJkIas003340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 19:46:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 14:46:18 -0500 From: "Nobo Akiya (nobo)" To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLw///FEwCAAEpvIA== Date: Thu, 10 Jul 2014 19:46:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E262B0Dxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/NUd77xIB-UJo_yls3RKH-XBf0PE Cc: "Ruediger.Geib@telekom.de" , draft-geib-spring-oam-usecase , spring Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 19:46:24 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E262B0Dxmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLA0KDQpJIGp1c3Qgd2FudGVkIHRvIHBvaW50IG91dCB0aGUga2V5IGRlc2NyaWJlZCBi ZWhhdmlvciwgd2FzbuKAmXQgc2F5aW5nIGFueXRoaW5nIGFib3V0IHdoZXRoZXIgdGhpcyBkb2N1 bWVudCBzaG91bGQgYmUgYSB1c2UtY2FzZSBkb2N1bWVudCBvciBhIHNvbHV0aW9uIGRvY3VtZW50 IOKYug0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCkZyb206IFNhbSBBbGRyaW4gW21haWx0bzphbGRy aW4uaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjEwIFBN DQpUbzogTm9ibyBBa2l5YSAobm9ibykNCkNjOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU7IHNw cmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNClN1YmplY3Q6IFJlOiBbc3ByaW5n XSBRdWVzdGlvbnMNCg0KSGkgTm9ibywNCg0KSW5saW5lIGZvciBteSBjb21tZW50cy4NCg0KT24g VGh1LCBKdWwgMTAsIDIwMTQgYXQgMTE6NTkgQU0sIE5vYm8gQWtpeWEgKG5vYm8pIDxub2JvQGNp c2NvLmNvbTxtYWlsdG86bm9ib0BjaXNjby5jb20+PiB3cm90ZToNCkhpIFNhbSwNCg0KSnVzdCB0 byBwb2ludCBvdXQgb25lIHRoaW5nIGFib3V0IHRoaXMgZG9jdW1lbnQg4oCmDQoNClRoZSB0ZXN0 IHBhY2tldCBnZW5lcmF0ZWQgZnJvbSBhIFBNUy9OTVMvRU1TL25ldHdvcmstZGV2aWNlIGNhbiBo YXZlIHRoZSBjb21wbGV0ZSBzZWdtZW50IHN0YWNrIG9uIGhvdyB0byB0cmF2ZXJzZSB0aGUgbmV0 d29yayBhcyB3ZWxsIGFzIGhvdyB0byBjb21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBmdXJ0 aGVyIHNpZ25hbGluZywgT0FNIHN0YXRlIG1haW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMgbm9y IE9BTSBpbnZvbHZlbWVudCBieSBuZXR3b3JrIG5vZGVzLg0KVGhhdCBpcyBmaW5lIGFzIGEgcmVx dWlyZW1lbnQvdXNlY2FzZSBhbmQgd2Ugc2hvdWxkIGxpbWl0IHRoZSBzY29wZSB0byB0aGF0LCB0 aGFuIHNwZWNpZnlpbmcgaG93IHRvIHNvbHZlIGl0Lg0KDQpUaGF0IG1ha2VzIHRoaXMgYXBwcm9h Y2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkgTFNQIHBpbmcuDQpZb3UgYXJlIHRh bGtpbmcgYWJvdXQgc29sdXRpb24gb3IgdXNlIGNhc2U/IDpEDQoNCg0KVGhpcyBjZXJ0YWlubHkg aGFzIHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2Yg dGhlIE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay4NCkNlcnRh aW5seS4gQnV0IEkgYW0gc3RydWdnbGluZyBiZXR3ZWVuIHVzZSBjYXNlIGFuZCBzb2x1dGlvbiBv dXRsaW5lZCBpbiB0aGUgZG9jdW1lbnQuIFBpY2sgb25lIDpEDQoNCi1zYW0NCg0KVGhhbmtzIQ0K DQotTm9ibw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgU2FtIEFsZHJpbg0K U2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjoxMyBQTQ0KVG86IFJ1ZWRpZ2VyLkdlaWJA dGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0KQ2M6IHNwcmluZzsg ZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBRdWVz dGlvbnMNCg0KSGkgUnVlZGlnZXIsDQoNClRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBQ bGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLg0KDQpPbiBUaHUsIEp1bCAxMCwgMjAxNCBh dCA3OjE1IEFNLCA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWli QHRlbGVrb20uZGU+PiB3cm90ZToNCkhpIFNhbSwNCg0KbXkgcmVwbGllcyBhcmUgbWFya2VkIFtS R10gYW5kIGFkZGVkIHRvIHlvdXIgdGV4dC4NCg0KLSBQcm94eS1sc3AtcGluZyBpcyBNUExTIG9u bHksIHdoaWxlIHRoZSBQTVMgYXJjaGl0ZWN0dXJlIGlzIGludGVuZGVkIGZvciBldmVyeSBTUiBk YXRhIHBsYW5lIChNUExTICsgSVB2NikuIFdlJ2xsIGNsYXJpZnkgdGhhdCBpbiB0aGUgZHJhZnQu DQotIFByb3h5LWxzcC1waW5nIGlzIGZvciBNUExTIExTUCBQaW5nIChSRkMgNDM3OSAvIFJGQyA2 NDI0KSwgd2hpbGUgb3VyIHVzZSBjYXNlIGNhbiB1c2UgYW55IE9BTSAoaW4gcGFydGljdWxhciwg c3BlY2lmaWMgZ29vZCB1c2VzIGZvciBCRkQsIGFuZCBJQ01QdjYpDQoNCkJhc2VkIG9uIHRoYXQs IGl0wrlzIGEgc29sdXRpb24gd2l0aCBicm9hZGVyIHNjb3BlIGFuZCBiZXR0ZXIgZml0IGZvciBT UFJJTkcgYXMgYSB3aG9sZS4NCiVzYW0gLSBJIGJlbGlldmUgeW91IHNheSBpdCBpcyB1c2UgY2Fz ZSBkb2N1bWVudCBiZWxvdy4gVGhlbiBzb2x1dGlvbiBpcyB0b28gcHJlbWF0dXJlIGF0IHRoaXMg cG9pbnQgb2YgdGltZSwgYXMgd2UgaGF2ZW4ndCBkZWxpYmVyYXRlZCBvbiB0aGUgcmVxdWlyZW1l bnRzIGVpdGhlci4NCg0KQXMgeW91IHdyaXRlLCBTUiBiYXNlZCBPQU0gcGFydGlhbGx5IG9mZmVy cyBzaW1pbGFyIGZ1bmN0aW9ucyBhcyBwcm94eS1sc3AuIFdpdGhvdXQgcmVxdWlyaW5nIHRoZSBh ZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBMRVIvTFNSIHByb2Nlc3NpbmcgaW50cm9kdWNlZCBieSBw cm94eS1sc3AuDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNCg0KICAgICAgU2FtIEFsZHJpbiB3 cm90ZToNCg0KICAgICAgSSBoYXZlIGZldyBxdWVzdGlvbnMgYWJvdXQgdGhpcyBkcmFmdC4NCg0K ICAgICAgMS4gVGhlIHRpdGxlIGlzIGNvbmZ1c2luZyB0byBtZS4gSXQgc2F5cyBPQU0gdXNlIGNh c2UgYnV0IGluIHNlY3Rpb24gIzENCiAgICAgIGl0IHNheXMgdGhlIGZvbGxvd2luZw0KDQogICAg ICA8c25pcD4NCiAgICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNvbHV0aW9uIHRvIHRo aXMgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kDQogICAgICAgaWxsdXN0cmF0ZXMgaXQgd2l0aCB1c2Ut Y2FzZXMuDQoNCiAgICAgICBUaGUgc29sdXRpb24gaXMgZGVzY3JpYmVkIGZvciBhIHNpbmdsZSBJ R1AgTVBMUyBkb21haW4uDQoNCiAgICAgICBUaGUgc29sdXRpb24gYXBwbGllcyB0byBtb25pdG9y aW5nIG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvDQogICAgICAgbW9uaXRvcmluZyBvZiBTZWdt ZW50IFJvdXRlZCBMU1Ancy4NCiAgICAgIDxlbmQgc25pcD4NCg0KICAgICAgIEluIGZhY3QgdGhl IGRyYWZ0IGlzIGRlc2NyaWJpbmcgYSBzb2x1dGlvbiB0byBjZXJ0YWluIHNjZW5hcmlvcyBhbmQg bm90IGp1c3QNCiAgICAgICBwcm92aWRpbmcgdXNlIGNhc2VzL3NjZW5hcmlvcy4gTXkgdW5kZXJz dGFuZGluZyB3YXMsIHVzZSBjYXNlIGRyYWZ0IHNob3VsZA0KICAgICAgIGRvY3VtZW50IHNjZW5h cmlvcyB3aGVyZSBpdCB3aWxsIGRyaXZlIG5ldyByZXF1aXJlbWVudHMuIFNvbHV0aW9ucyBjb3Vs ZA0KICAgICAgIGJlIGNvdmVyZWQgd2l0aCBleGlzdGluZyB0b29sc2V0IG9yIGRlZmluZWQgbmV3 bHksIGRlcGVuZGluZyBvbiB0aGUgR0FQDQogICAgICAgYW5hbHlzaXMuIEJ1dCB0aGF0IHNob3Vs ZCBiZSBzZXBhcmF0ZSBhcyB0aGVyZSBjb3VsZCBiZSBtb3JlIHRoYW4gMSBzb2x1dGlvbiwNCiAg ICAgICB3aGVyZSBhcyB0aGlzIGRvY3VtZW50IGNvdWxkIGp1c3QgZm9jdXMgb24gdXNlIGNhc2Vz IG9ubHkuDQoNCiAgICAgICBJZiBpbmZhY3QgdGhpcyBpcyBzdXBwb3NlZCB0byBiZSBhIHNvbHV0 aW9uIGRvY3VtZW50LCB0aGVuIGNoYW5naW5nIHRoZSB0aXRsZQ0KICAgICAgIHdvdWxkIGJlIG1v cmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15IG9ic2VydmF0aW9uLg0KW1JHXSBUaGFua3MuIEl0J3Mg YSB1c2UgY2FzZSBkb2N1bWVudC4gV2UnbGwgcmV2aWV3IHRoZSB0ZXh0IG9mIHNlY3Rpb24gMS4N CiVzYW0gLSBPSy4gdGhlbiBJJ2QgbGlrZSB0byBzZWUgYW55IHNwZWNpZmljIHNvbHV0aW9uIGNv bnRlbnQgcmVtb3ZlZCwgdGhhdCB3YXkgd2UgZG9udCBoYXZlIHRvIGRpc2N1c3Mgd2hhdCBvdGhl ciBzb2x1dGlvbnMgZG9lcyBlaXRoZXIgb3IgY29tcGFyZSB3aXRoIDpEDQoNCg0KICAgICAgIDIu IHcuci50LiBTZWN0aW9uIG51bWJlciAjMiwgdGhlIHNhbWUgcHJvYmxlbSBpcyBiZWluZyBzb2x2 ZWQgd2l0aA0KICAgICAgICJkcmFmdC1pZXRmLW1wbHMtcHJveHktbHNwLXBpbmctMDIiIC4gV2hh dCBpcyBiZWluZyBkZXNjcmliZWQgaW4gdGhpcw0KICAgICAgIHNlY3Rpb24gY291bGQgYmUgZG9u ZSB3aXRoIHRoZSBwcm94eSBwaW5nKHNvbHV0aW9uIHdpc2UpIHdoZXJlLCByZXF1ZXN0IGNvdWxk DQogICAgICAgYmUgc2VudCB0byBtb25pdG9yIExFUiBpIGFuZCBMRVIgaiBzZWdtZW50LCBmcm9t IGEgUE1TLiBJcyBteSB1bmRlcnN0YW5kaW5nDQogICAgICAgcmlnaHQ/IElmIG5vdCwgaG93IGlz IGl0IGRpZmZlcmVudCBoZXJlPw0KW1JHXSBUaGUgUE1TIGlzIGFibGUgdG8gc2V0IHVwIHBhY2tl dHMgd2hpY2ggc3RheSBpbiBkYXRhIHBsYW5lIGFuZCBleGVjdXRlIGEgZGVzaXJlZA0KICAgICBj aGFpbiBvZiBNUExTIExTUHMuDQolc2FtIC0gRXhlY3V0ZSB5b3UgbWVhbiB0cmF2ZXJzZT8gb3Ig cGVyZm9ybSBzb21ldGhpbmcgZWxzZT8NCg0KW1JHXSBQcm94eS1sc3Agc2F5czogVGhpcyBkb2N1 bWVudCBkZWZpbmVzIHByb3RvY29sIGV4dGVuc2lvbnMgdG8gTVBMUyBwaW5nIFtSRkM0Mzc5XSB0 bw0KICAgYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byByZW1vdGVseSBjYXVzZSBhbiBNUExTIEVjaG8g UmVxdWVzdCBtZXNzYWdlIHRvDQogICBiZSBzZW50IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBM U1AuDQolc2FtIC0gSWYgaXQgaXMgcHJvcG9zaW5nIGV4dGVuc2lvbnMsICBpdCBoYXMgdG8gYmUg c29sdXRpb24gZG9jdW1lbnQgIGFuZCBjYW5ub3QgY2xhaW0gdG8gYmUgdXNlIGNhc2UgZG9jdW1l bnQuIEFsc28gdGhpcyBkb2N1bWVudCBpcyBvbiBpbmZvcm1hdGlvbiB0cmFjay4NCg0KW1JHXSBJ IHRha2UgaXQgYXMgc2F5aW5nIHRoYXQgaWYgeW91J2QgbGlrZSB0byByZW1vdGVseSBleGVjdXRl IFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBvbiBhbnkgTFNQLCB5b3UgY291bGQgZWl0aGVyIHVzZSB0 aGUgUE1TIG9yIHByb3h5LXBpbmcuIFRoZSBQTVMgaG93ZXZlciBzaW1wbGlmaWVzIGFuZCBhZGRz DQpmdW5jdGlvbmFsaXR5Og0KYSkgWW91IGRvbid0IG5lZWQgYW4gYWRkaXRpb25hbCBwcm90b2Nv bCBvciBmdW5jdGlvbmFsaXR5IGxpa2UgcHJveHktcGluZyB0byBjaGVjayBkYXRhDQogICBwbGFu ZSBsaXZlbGluZXNzLCBSRkM0Mzc5IGlzIGZpbmUuIERldXRzY2hlIFRlbGVrb20gb3BlcmF0ZXMg YSBQTVMgaW1wbGVtZW50YXRpb24uDQolc2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2YWxpZGF0aW9u IG9mIGRhdGFwbGFuZSBhbmQgYWxzbyBmaW5kIG91dCBsb3QgbW9yZSBlcnJvcnMuIFlvdSBuZWVk IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNoZWNrcy4gRm9y IGxpdmVuZXNzIGRldGVjdGlvbiwgQkZEIGlzIHByZWZlcnJlZCB0b29sLCBhdGxlYXN0IGluIHBy ZXNlbnQgZGVwbG95bWVudHMuU28gYXJlIHlvdSBzYXlpbmcsIFBNUyBzb2x1dGlvbiBpcyBkZXNp Z25lZCBmb3IgbGl2ZW5lc3MgZGV0ZWN0aW9uIGFuZCBub3QgdG8gcGVyZm9ybSB2YWxpZGF0aW9u IG9mIGRhdGEgcGxhbmUgdG8gY29udHJvbCBwbGFuZSwgZXRjPyAoSSB0aGluayB5b3UgYWdyZWUg dG8gdGhpcyBpbiB0aGUgbGF0ZXIgcGFydCBvZiB0aGUgZG9jIGFsc28pDQoNCmIpIG9uY2UgUE1T IGRldGVjdGVkIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcyBhbmQgY29ycmVjdG5lc3Mgb2YgTVBMUyB0 b3BvbG9neSBieSBSRkM0Mzc5LA0KICAgaXQgY2FuIGNvbnRpbnVlIHRvIGV4ZWN1dGUgYXJiaXRy YXJ5IExTUCBjb21iaW5hdGlvbnMgYW5kIHRoZSBtb25pdG9yaW5nIHBhY2tldHMgc3RheQ0KICAg aW4gZGF0YSBwbGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0ZXh0IGluIHByb3h5LXBpbmcg b2ZmZXJpbmcgdGhpcyBmZWF0dXJlLg0KJXNhbSAtIFRoaXMgeW91IGNvdWxkIHBlcmZvcm0gZXZl biB3aXRob3V0IHByb3h5IHBpbmcuIFRoZSBmdW5jdGlvbiB5b3UgYXJlIGRlc2NyaWJpbmcgaXMs IGhvdyB5b3UgdXNlIGxzcCBwaW5nIHJhdGhlciB0aGFuIHdoYXQgbHNwIHBpbmcgZG9lcy4gQWdh aW4gSSBhbSBub3QgdGFsa2luZyBhYm91dCBub24tbXBscyB0b3BvbG9neS4NClRvIGFuc3dlciB5 b3VyIHF1ZXN0aW9uLCBob3cgeW91IHBlcmZvcm0uDQotIFBlcmZvcm0gdHJlZXRyYWNlIHdpdGgg cmZjNDM3OSB0byBnZXQgdG9wb2xvZ3kgaW5mbw0KLSBwaWNrIGFueSBhcmJpdGFyeSBMU1AgcGF0 aHMgZGlzY292ZXJlZCBhbG9uZyB3aXRoIGl0cyBtdWx0aXBhdGggaW1wbGVtZW50YXRpb24uDQot IHBlcmZvcm0gcGluZyB3aXRoIHJpZ2h0IHNlbGVjdG9ycyBmb3IgdGhlIHBhdGggYW5kIHVzZSBU VEwgZm9yIGxpbWl0aW5nIHRoZSBob3AgW0xFUiBqXS4NCi0gaWYgeW91IHdhbnQgdG8gcGVyZm9y bSBmcm9tIExFUiBpIHRvIExFUiBqIGFzIGluIHlvdXIgZHJhZnQsIHVzZSBwcm94eSBwaW5nIHRv IHN0YXJ0IGZyb20gTEVSIGkNCg0KICAgICAgICAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50 IGJhY2sgdG8gUE1TIHdoaWNoIGlzIG5vdCBwYXJ0IG9mIE1QTFMgb3Igc2VnbWVudA0KICAgICAg ICBkb21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1cml0eSBhc3BlY3QsIHdoaWNoIG5lZWRz IHRvIGNvbnNpZGVyZWQuIEkgYmVsaWV2ZQ0KICAgICAgICBpdCBhcHBsaWVzIHRvIHNlbmRpbmcg YSByZXF1ZXN0IHRvby4gV2lsbCB5b3UgYmUgZG9jdW1lbnRpbmcgdGhhdCBhc3BlY3Q/DQpbUkdd IFRoYXQncyBhIHZhbGlkIHBvaW50LiBUaGUgZG9tYWluIGV4dGVybmFsIHN5c3RlbSBpcyBvbmUg b3B0aW9uIGFuZCB0aGUgdGVhbSB3aWxsIGRlYWwgd2l0aCB0aGUgc2VjdXJpdHkgYXNwZWN0cyBy YWlzZWQgYnkgdGhpcyBvcHRpb24gb25jZSB3ZSBhcmUgaW4gc29sdXRpb24gc3BhY2UuIFdlIHdp bGwgbm90IGFuYWx5c2UgdGhpcyBpbiBkZXB0aCBmb3IgYSB1c2UgY2FzZSBkb2N1bWVudC4NCiVz YW0gLSBub2QNCg0KICAgICAgICA0LiBTZWMgMy4yIHRvIG1vbml0b3IgYnVuZGxlIGxpbmtzLCBv bmUgY291bGQgcGVyZm9ybSB0aGF0IHdpdGggUkZDNDM3OSBwaW5nDQogICAgICAgIHdpdGggbXVs dHBhdGggKyBwcm94eSBwaW5nLiBDb3VsZCB5b3Uga2luZGx5IGRpZmZlcmVudGlhdGUgaWYgdGhl cmUgaXMgc29tZXRoaW5nDQogICAgICAgIG5ldyB0aGUgc29sdXRpb24gYnJpbmdzIGhlcmU/DQpb UkddIFRoZSBTUiBPQU0gYXV0aG9yIHRlYW0gaGFzIHByb3ZpZGVkIHRleHQgaG93IHRvIG1vbml0 b3IgYSBidW5kbGVkIGxpbmsgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LiBZb3UgYXJlIGEgY28tYXV0 aG9yIG9mIHByb3h5LWxzcC4gSSBjb3VsZG4ndCBmaW5kIGV4cGxpY2l0IHRleHQgb24gaG93IHRv IGRldGVjdCBhbmQgbW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbiBkcmFmdC1wcm94eS1sc3AuIFBs ZWFzZSBkZXNjcmliZSBob3cgcHJveHktbHNwIGNhbiBiZSB1c2VkIHRvIG1vbml0b3IgYSBidW5k bGVkIGxpbmsgKHNvcnJ5IGlmIHRoaXMgaXMgb2J2aW91cyBhbmQgSSBtaXNzZWQgaXQpLiBJZiB0 aGVyZSBhcmUgZGlmZmVyZW5jZXMgdG8gdGhlIFNSIE9BTSBhcHByb2FjaCwgd2UnbGwgZGlzY3Vz cyB0aGVtLg0KJXNhbSAtIFRoZSBzYW1lIHN0ZXBzIGRlc2NyaWJlZCBhYm92ZSBjb3VsZCBiZSB1 c2VkIGlmIGVhY2ggYnVuZGxlZCBsaW5rIG1lbWJlciBpcyBpZGVudGlmaWVkIHdpdGggYSB1bmlx dWUgbGFiZWwuIFdoaWxlIHBlcmZvcm1pbmcgdHJlZSB0cmFjZSBvciBwaW5nIHdpdGggbXVsdGlw YXRoLCBMRVIgaSB3aWxsIHJlc3BvbmQgd2l0aCBERE1BUCBpbmZvIGZvciBlYWNoIG9mIHRoZSBs aW5rcyBhbmQgdGhlIG11bHRpcGF0aCBpbmZvIGZvciB0aGUgc2FtZS4NCklmIHlvdSBzYXkgdGhh dCBlYWNoIGxpbmsgbWVtYmVyIGhhcyBzYW1lIGxhYmVsIHN0YWNrLCB0aGVuIHlvdSBjb3VsZCB1 c2UgbHNwIHNlbGVjdG9ycyBhcyBkZWZpbmVkIGluIFJGQzQzNzksIGluIHRoaXMgY2FzZSBpdCBp cyBsb2NhbCBob3N0IGRlc3QgaXAgYWRkciwgdG8gaWRlbnRpZnkgZWFjaCBsaW5rIG1lbWJlci4N Ck5vdyBpZiB0aGUgTVBMUyBmb3J3YXJkaW5nIGxheWVyIHNlZXMgdGhlIGJ1bmRsZWQgbGluayBh cyBvbmUgaW50ZXJmYWNlIGJ1dCBjYW5ub3QgZGlzY2VybiBpdHMgbGluayBtZW1iZXJzLCB0aGVu IHlvdSBjb3VsZCBvbmx5IHZhbGlkYXRlIHRoZSBpbnRlcmZhY2UgYW5kIG5vdCBpdHMgaW5kaXZp ZHVhbCBtZW1iZXJzLg0KU2FtZSBhcHBsaWVzIGluIHlvdXIgY2FzZSB0b28uIENhbm5vdCBzZWUg aG93IGl0IGlzIGRpZmZlcmVudC4NCg0KDQoNCiAgICAgICAgIDUuIHNlYyAjNSwgSXMgdGhlIHJl cXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3BvbG9neSwgaW4gdGhl DQogICAgICAgICAgICBjYXNlIG9mIG1peGVkIGVudj8NCltSR10gTVBMUyB0b3BvbG9neSBhd2Fy ZW5lc3MgaXMgdGhlIHByZWNvbmRpdGlvbiB0byBzZXQgdXAgcGFja2V0cyB3aXRoIGxhYmVsIHN0 YWNrcyBleGVjdXRpbmcgYSBkZXNpcmVkIGNoYWluIG9mIExTUHMuIElmIHN1aXRhYmxlIExhYmVs L0ZFQy9ub2RlIHJlbGF0aW9uIGlzIGtub3duIHRvIHRoZSBQTVMsIHRoYXQgTFNQIGNhbiBiZSBl eGVjdXRlZCBmcm9tIHRoYXQgbm9kZSBvbiBieSBhIFBNUyBtb25pdG9yaW5nIHBhY2tldC4NCiVz YW0gLSBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCB5b3Ugc3RpbGwgbmVlZCB0byBwZXJmb3JtIFJG QzQzNzkgdHJhY2Ugb3IgdHJlZXRyYWNlIHRvIGdldCB0b3BvbG9neS4gSSBkbyBub3QgdGhpbmsg SUdQIGV4dGVuc2lvbnMgYmVpbmcgcHJvcG9zZWQgaW4gU1BSSU5HIGV4cG9ydCBhbnkgb2YgdGhl IGluZm8gb3RoZXIgdGhhbiBsYWJlbCBzdGFjay4NCkFuZCB0aGUgcHJvcG9zZWQgUE1TIHNvbHV0 aW9uIChub3QgdXNlIGNhc2UpIGlzIHRoYXQsIGl0IHBlcmZvcm1zIG9uIGRlbWFuZCBwZXIgc2Vn bWVudCwgd2hpY2ggUHJveHkgcGluZyBhbHNvIGRvZXMsIGFsYmVpdCBvbmx5IGZvciBNUExTIHRv cG9sb2d5Lg0KVGhlIGNhc2UgeW91IGFyZSBtYWtpbmcgaXMgdGhhdCBubyBuZWVkIG9mIGJlbGxz IGFuZCB3aGlzdGxlcyBvZiBSRkM0Mzc5Lg0KDQpRdWVzdGlvbiBJIGhhdmUgZm9yIHlvdSBpcywg aWYgZGF0YSBwbGFuZSBwYWNrZXRzIGFyZSBnZXR0aW5nIGRyb3BwZWQgYW5kIFBNUyBwYWNrZXRz IGdvaW5nIHRocm91Z2gsIGZvciBhIGdpdmVuIExTUCBvciBTZWdtZW50LCBob3cgZG8geW91IGtu b3cgdGhlcmUgaXMgYSBwcm9ibGVtPyBpZiB5b3Uga25vdywgaG93IGRvIHlvdSBmaWd1cmUgb3V0 IHdoZXJlIGl0IGlzPw0KQXQgbGVhc3Qgd2l0aCBSRkM0Mzc5IGFuZC9vciBwcm94eSBwaW5nLCB5 b3UgY291bGQgdmFsaWRhdGUgZWFjaCBob3AgYmVjYXVzZSBvZiB0aGUgYmVsbHMgYW5kIHdoaXN0 bGVzIGl0IGNhcnJpZXMgYWxvbmcgd2l0aCB0aGUgcGFja2V0Lg0KDQoNCg0KICAgICAgICAgNi4g SW4gc2VjIDMuMSwNCiAgICAgICAgIDxzbmlwPg0KICAgICAgICAgRGV0ZXJtaW5pbmcgYSBwYXRo IHRvIGJlIGV4ZWN1dGVkIHByaW9yIHRvIGEgbWVhc3VyZW1lbnQgbWF5IGFsc28gYmUNCiAgICAg ICAgIGRvbmUgYnkgc2V0dGluZyB1cCBhIGxhYmVsIGluY2x1ZGluZyBhbGwgbm9kZSBTSURzIGFs b25nIHRoYXQgcGF0aA0KICAgICAgICAgKGlmIExFUjEgaGFzIE5vZGUgU0lEIDQwIGluIHRoZSBl eGFtcGxlIGFuZCBpdCBzaG91bGQgYmUgcGFzc2VkDQogICAgICAgICBiZXR3ZWVuIExFUiBpIGFu ZCBMRVIgaiwgdGhlIGxhYmVsIHN0YWNrIGlzIDIwIC0gNDAgLSAzMCAtIDEwKS4gIFRoZQ0KICAg ICAgICAgYWR2YW50YWdlIG9mIHRoaXMgbWV0aG9kIGlzLCB0aGF0IGl0IGRvZXMgbm90IGludm9s dmUgTVBMUyBPQU0NCiAgICAgICAgIGZ1bmN0aW9uYWxpdHkgYW5kIGl0IGlzIGluZGVwZW5kZW50 IG9mIEVDTVAgZnVuY3Rpb25hbGl0aWVzLiAgVGhlDQogICAgICAgICBtZXRob2Qgc3RpbGwgaXMg YWJsZSB0byBtb25pdG9yIGFsbCBsaW5rIGNvbWJpbmF0aW9ucyBvZiBhbGwgcGF0aHMgb2YNCiAg ICAgICAgIGFuIE1QTFMgZG9tYWluLiAgSWYgY29ycmVjdCBmb3J3YXJkaW5nIGFsb25nIHRoZSBk ZXNpcmVkIHBhdGhzIGhhcyB0bw0KICAgICAgICAgYmUgY2hlY2tlZCwgUkZDNDczOSBmdW5jdGlv bmFsaXR5IHNob3VsZCBiZSBhcHBsaWVkIGFsc28gaW4gdGhpcw0KICAgICAgICAgY2FzZS4NCg0K ICAgICAgICAgPGVuZCBzbmlwPg0KDQogICAgICAgICBJbiB0aGUgYWJvdmUgeW91IG1lbnRpb24g dGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNLiBCdXQgbGF0ZXIgeW91IHNheSwNCiAg ICAgICAgIFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBjb3VsZCBiZSB1c2VkLiBDb3VsZCB5b3UgY2xh cmlmeSBob3cgY291bGQgeW91IHZlcmlmeSBhDQogICAgICAgICBwYXRoLCBpZiBNUExTIHZhbGlk YXRpb24gaXMgbm90IGRvbmUuIE1vcmUgdGV4dCB3aWxsIGhlbHAuIEFsc28sIG1vcmUNCiAgICAg ICAgIGltcG9ydGFudGx5LCB0aGUgdGV4dCBlYXJsaWVyIHRvIHRoZSBhYm92ZSBzYXlzLCBmb3Ig dmFsaWQgcmVzdWx0LCBNUExTDQogICAgICAgICBPQU0gaGFzIHRvIGJlIHBlcmZvcm1lZCBmb3Ig dG9wb2xvZ3kgY2hhbmdlcyBldGMuIElmIHNvLCBpdCBjb250cmFkaWN0cyBoZXJlLg0KW1JHXSBU aGUgdGV4dCBzaG91bGQgc2F5IHRoYXQNCi0gd2l0aG91dCBNUExTIE9BTSBmdW5jdGlvbnMsIHRo ZSBQTVMgZXhlY3V0ZXMgYSBzZXQgb2YgcGF0aHMgb25seSBiYXNlZCBvbiBjb250cm9sIHBsYW5l IGluZm9ybWF0aW9uLg0KLSBpZiB0aGUgb3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQg ZGF0YSBwbGFuZSBjb3JyZXNwb25kcyB0byBjb250cm9sIHBsYW5lLCBSRkM0NzM5IGZ1bmN0aW9u cyBzaG91bGQgYmUgYXBwbGllZC4NCklmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFu ZCB0aGUgdGV4dCBpbiB0aGUgZHJhZnQgc3RhdGVzIHNvbWV0aGluZyBkaWZmZXJlbnQsIEknbGwg dHJ5IHRvIHJld29yZCBpdC4NCiVzYW0gLSBUaGUgcHJvYmxlbSBJIGFtIGhhdmluZyBpcywgaW4g dGhlIGNhc2Ugb2YgTVBMUywgZm9yIE9BTSwgeW91IGhhdmUgdG8gdmFsaWRhdGUgdGhlIGxzcC4N CkkgZGVmaW5pdGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkg ZmVlbCBpcywgdGhlIHVzZSBjYXNlIGlzIHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBl bnZpc2lvbmVkIHNvbHV0aW9uLg0KT25jZSB5b3UgcmVtb3ZlIHNvbHV0aW9uIG9yIHN1Z2dlc3Rl ZCBlbmhhbmNlbWVudHMsIGhvcGUgaXQgc2hvdWxkIGJlIGNsZWFyIG9uIHdoYXQgaXMgYmVpbmcg c29sdmVkIGFuZCBzY29wZSBvdXQgY2xlYXIgcmVxdWlyZW1lbnRzIGZvciBhIHNvbHV0aW9uLg0K Rm9yIHNvbHV0aW9uIHBhcnQsIHBsZWFzZSBwdWJsaXNoIGEgc2VwYXJhdGUgSUQuDQoNCg0KICAg ICAgICAgNy4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZlcmVudCBpcyBQTVMgZnJv bSBFTVMgYW5kIE5NUz8NCiAgICAgICAgIFNvbWVob3cgSSBjb3VsZG4ndCBmaW5kIHRoZSBkaWZm ZXJlbmNlIHdoYXQgUE1TIGNvdWxkIGRvIGFuZA0KICAgICAgICAgTk1TL0VNUyBjb3VsZG4ndC4N CltSR10gSSd2ZSBuZXZlciBoZWFyZCBvZiBhbiBFTVMvTk1TIHdoaWNoIGlzIE1QTFMgdG9wb2xv Z3kgYXdhcmUgYW5kIHVzZXMgdGhpcyB0b3BvbG9neSBhd2FyZW5lc3MgdG8gY3JlYXRlIGRhdGEg cGxhbmUgcGFja2V0cyBleGVjdXRpbmcgTFNQIGNvbWJpbmF0aW9ucyBhcyBkZXNpcmVkIGJ5IGFu IG9wZXJhdG9yLiBIYWQgdGhpcyBmZWF0dXJlIGJlZW4gY29tbWVyY2lhbGx5IGF2YWlsYWJsZSwg dGhlIGNvbXBhbnkgSSB3b3JrIGZvciB3b3VsZG4ndCBoYXZlIGJlZW4gZGV2ZWxvcGluZyBhIFBN Uy4NCiVzYW0gLSBUaGVyZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hp Y2ggcGVyZm9ybXMgTVBMUyB0b3BvbG9neSBzcGVjaWZpYyBvcGVyYXRpb25zICBmb3IgYSBnaXZl biBzZXQgb2YgTFNQJ3MuIFRoZXkgcGVyZm9ybSBUcmVldHJhY2UgYW5kIHBlcmZvcm0gcGluZyB3 aXRoIG11bHRpcGF0aC4gQWxzbyBwZXJmb3JtIExTUCBzcGVjaWZpYyB2YWxpZGF0aW9uIGJ5IGNy YWZ0aW5nIHBhY2tldHMgd2l0aCBkYXRhIGF2YWlsYWJsZSB3aXRoIHRyZWV0cmFjZSBhbmQgcGlu ZyB3aXRoIG11bHRpcGF0aC4gWW91IGNvdWxkIGF1dG9tYXRlIHRoZSB3b3JrZmxvdyB3aXRob3V0 IHRoZSBuZWVkIGZvciBPU1MvUE1TLCBieSB1c2luZyBwcm9iZSB0ZWNobm9sb2d5LiBXaWxsIG5v dCBzYXkgYmV5b25kIHRoYXQgOkQNCg0KY2hlZXJzDQotc2FtDQoNCg0KDQo= --_000_CECE764681BE964CBE1DFF78F3CDD3941E262B0Dxmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgU2FtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBqdXN0IHdhbnRlZCB0byBwb2ludCBvdXQg dGhlIGtleSBkZXNjcmliZWQgYmVoYXZpb3IsIHdhc27igJl0IHNheWluZyBhbnl0aGluZyBhYm91 dCB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIGEgdXNlLWNhc2UgZG9jdW1lbnQgb3Ig YSBzb2x1dGlvbiBkb2N1bWVudA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi1Ob2JvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2FtIEFsZHJpbiBbbWFpbHRvOmFsZHJpbi5pZXRmQGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAzOjEw IFBNPGJyPg0KPGI+VG86PC9iPiBOb2JvIEFraXlhIChub2JvKTxicj4NCjxiPkNjOjwvYj4gUnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlOyBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2Vj YXNlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTm9ibyw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklubGluZSBmb3IgbXkg Y29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVsIDEwLCAyMDE0IGF0IDExOjU5 IEFNLCBOb2JvIEFraXlhIChub2JvKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vYm9AY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+bm9ib0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU2FtLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3Qg dG8gcG9pbnQgb3V0IG9uZSB0aGluZyBhYm91dCB0aGlzIGRvY3VtZW50IOKApjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoZSB0ZXN0IHBhY2tldCBnZW5lcmF0ZWQgZnJvbSBhIFBNUy9OTVMvRU1TL25ldHdvcmst ZGV2aWNlIGNhbiBoYXZlIHRoZSBjb21wbGV0ZSBzZWdtZW50IHN0YWNrIG9uDQogaG93IHRvIHRy YXZlcnNlIHRoZSBuZXR3b3JrIGFzIHdlbGwgYXMgaG93IHRvIGNvbWUgYmFjayB0byBzZWxmIHdp dGhvdXQgYW55IGZ1cnRoZXIgc2lnbmFsaW5nLCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0 d29yayBub2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGF0IGlzIGZpbmUgYXMgYSByZXF1aXJlbWVudC91c2VjYXNlIGFuZCB3ZSBzaG91bGQgbGlt aXQgdGhlIHNjb3BlIHRvIHRoYXQsIHRoYW4gc3BlY2lmeWluZyBob3cgdG8gc29sdmUgaXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQgbWFrZXMgdGhpcyBh cHByb2FjaCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB1c2luZyBwcm94eSBMU1AgcGluZy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgdGFsa2luZyBhYm91dCBzb2x1dGlvbiBvciB1c2Ug Y2FzZT8gOkQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlz IGNlcnRhaW5seSBoYXMgc29tZSBwcm9zIGFuZCBjb25zIGJ1dCBjYW4gYmUgcXVpdGUgdXNlZnVs IGFzIG9uZSBvZiB0aGUgT0FNcyAoeWVzIHBsdXJhbCkgdXNlZA0KIHRvIG1vbml0b3IgdGhlIG5l dHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DZXJ0YWlubHkuIEJ1dCBJIGFtIHN0cnVn Z2xpbmcgYmV0d2VlbiB1c2UgY2FzZSBhbmQgc29sdXRpb24gb3V0bGluZWQgaW4gdGhlIGRvY3Vt ZW50LiBQaWNrIG9uZSA6RDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tc2FtJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTm9ibzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBz cHJpbmcNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+U2FtIEFsZHJpbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAxMCwg MjAxNCAyOjEzIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86UnVlZGlnZXIuR2Vp YkB0ZWxla29tLmRlIiB0YXJnZXQ9Il9ibGFuayI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9h Pjxicj4NCjxiPkNjOjwvYj4gc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZTxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gUXVlc3Rpb25zPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhpIFJ1ZWRpZ2VyLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBQbGVhc2UgZmluZCBteSByZXNw b25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIFRodSwgSnVsIDEwLCAyMDE0IGF0IDc6MTUgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86UnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlIiB0YXJnZXQ9Il9ibGFuayI+UnVlZGlnZXIuR2VpYkB0ZWxl a29tLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkhpIFNhbSw8YnI+DQo8YnI+DQpteSByZXBsaWVzIGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRk ZWQgdG8geW91ciB0ZXh0Ljxicj4NCjxicj4NCi0gUHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5 LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBpcyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0 YSBwbGFuZSAoTVBMUyAmIzQzOyBJUHY2KS4gV2UnbGwgY2xhcmlmeSB0aGF0IGluIHRoZSBkcmFm dC48YnI+DQotIFByb3h5LWxzcC1waW5nIGlzIGZvciBNUExTIExTUCBQaW5nIChSRkMgNDM3OSAv IFJGQyA2NDI0KSwgd2hpbGUgb3VyIHVzZSBjYXNlIGNhbiB1c2UgYW55IE9BTSAoaW4gcGFydGlj dWxhciwgc3BlY2lmaWMgZ29vZCB1c2VzIGZvciBCRkQsIGFuZCBJQ01QdjYpPGJyPg0KPGJyPg0K QmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3aXRoIGJyb2FkZXIgc2NvcGUgYW5kIGJl dHRlciBmaXQgZm9yIFNQUklORyBhcyBhIHdob2xlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JXNhbSAtIEkgYmVsaWV2ZSB5b3Ugc2F5IGl0IGlz IHVzZSBjYXNlIGRvY3VtZW50IGJlbG93LiBUaGVuIHNvbHV0aW9uIGlzIHRvbyBwcmVtYXR1cmUg YXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyB3ZSBoYXZlbid0IGRlbGliZXJhdGVkIG9uIHRoZSBy ZXF1aXJlbWVudHMgZWl0aGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KQXMgeW91IHdyaXRlLCBTUiBiYXNlZCBPQU0gcGFydGlhbGx5IG9mZmVy cyBzaW1pbGFyIGZ1bmN0aW9ucyBhcyBwcm94eS1sc3AuIFdpdGhvdXQgcmVxdWlyaW5nIHRoZSBh ZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBMRVIvTFNSIHByb2Nlc3NpbmcgaW50cm9kdWNlZCBieSBw cm94eS1sc3AuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpSdWVkaWdlcjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg U2FtIEFsZHJpbiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBJIGhhdmUg ZmV3IHF1ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcgdG8gbWUuIEl0IHNheXMgT0FNIHVzZSBj YXNlIGJ1dCBpbiBzZWN0aW9uICMxPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXQgc2F5cyB0 aGUgZm9sbG93aW5nPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3NuaXAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGFuZDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2lsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLjxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBzb2x1dGlvbiBpcyBkZXNjcmliZWQgZm9y IGEgc2luZ2xlIElHUCBNUExTIGRvbWFpbi48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtUaGUgc29sdXRpb24gYXBwbGllcyB0byBtb25pdG9yaW5nIG9mIExEUCBMU1AncyBh cyB3ZWxsIGFzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bW9uaXRvcmluZyBv ZiBTZWdtZW50IFJvdXRlZCBMU1Ancy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZW5k IHNuaXAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gZmFjdCB0 aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNvbHV0aW9uIHRvIGNlcnRhaW4gc2NlbmFyaW9zIGFu ZCBub3QganVzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb3ZpZGluZyB1c2Ug Y2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNhc2UgZHJhZnQgc2hv dWxkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnQgc2NlbmFyaW9zIHdo ZXJlIGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVpcmVtZW50cy4gU29sdXRpb25zIGNvdWxkPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgY292ZXJlZCB3aXRoIGV4aXN0aW5nIHRvb2xz ZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5nIG9uIHRoZSBHQVA8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthbmFseXNpcy4gQnV0IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFz IHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhhbiAxIHNvbHV0aW9uLDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3doZXJlIGFzIHRoaXMgZG9jdW1lbnQgY291bGQganVzdCBmb2N1cyBvbiB1 c2UgY2FzZXMgb25seS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJZiBp bmZhY3QgdGhpcyBpcyBzdXBwb3NlZCB0byBiZSBhIHNvbHV0aW9uIGRvY3VtZW50LCB0aGVuIGNo YW5naW5nIHRoZSB0aXRsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dvdWxkIGJl IG1vcmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15IG9ic2VydmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNh c2UgZG9jdW1lbnQuIFdlJ2xsIHJldmlldyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4lc2Ft IC0gT0suIHRoZW4gSSdkIGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50 IHJlbW92ZWQsIHRoYXQgd2F5IHdlIGRvbnQgaGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29s dXRpb25zIGRvZXMgZWl0aGVyIG9yIGNvbXBhcmUgd2l0aCA6RDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsyLiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcg c29sdmVkIHdpdGg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtkcmFmdC1p ZXRmLW1wbHMtcHJveHktbHNwLXBpbmctMDImcXVvdDsgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJl ZCBpbiB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VjdGlvbiBjb3VsZCBi ZSBkb25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRpb24gd2lzZSkgd2hlcmUsIHJlcXVlc3Qg Y291bGQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBzZW50IHRvIG1vbml0b3Ig TEVSIGkgYW5kIExFUiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3RhbmRpbmc8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyaWdodD8gSWYgbm90LCBob3cgaXMgaXQg ZGlmZmVyZW50IGhlcmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+W1JHXSBUaGUgUE1TIGlzIGFibGUgdG8gc2V0IHVwIHBhY2tldHMgd2hpY2ggc3RheSBp biBkYXRhIHBsYW5lIGFuZCBleGVjdXRlIGEgZGVzaXJlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Y2hhaW4gb2YgTVBMUyBMU1BzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JXNhbSAtIEV4ZWN1dGUgeW91IG1lYW4gdHJhdmVy c2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVsc2U/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpbUkddIFByb3h5LWxzcCBzYXlzOiBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBNUExTIHBpbmcgW1JGQzQzNzldIHRv PGJyPg0KJm5ic3A7ICZuYnNwO2FsbG93IGEgdGhpcmQgcGFydHkgdG8gcmVtb3RlbHkgY2F1c2Ug YW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bzxicj4NCiZuYnNwOyAmbmJzcDtiZSBzZW50 IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBMU1AuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4lc2FtIC0gSWYgaXQgaXMgcHJvcG9z aW5nIGV4dGVuc2lvbnMsICZuYnNwO2l0IGhhcyB0byBiZSBzb2x1dGlvbiBkb2N1bWVudCAmbmJz cDthbmQgY2Fubm90IGNsYWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9j dW1lbnQgaXMgb24gaW5mb3JtYXRpb24gdHJhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YnI+DQpbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5b3Un ZCBsaWtlIHRvIHJlbW90ZWx5IGV4ZWN1dGUgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IG9uIGFueSBM U1AsIHlvdSBjb3VsZCBlaXRoZXIgdXNlIHRoZSBQTVMgb3IgcHJveHktcGluZy4gVGhlIFBNUyBo b3dldmVyIHNpbXBsaWZpZXMgYW5kIGFkZHM8YnI+DQpmdW5jdGlvbmFsaXR5Ojxicj4NCmEpIFlv dSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBsaWtl IHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDtwbGFuZSBsaXZlbGlu ZXNzLCBSRkM0Mzc5IGlzIGZpbmUuIERldXRzY2hlIFRlbGVrb20gb3BlcmF0ZXMgYSBQTVMgaW1w bGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4lc2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIGRh dGFwbGFuZSBhbmQgYWxzbyBmaW5kIG91dCBsb3QgbW9yZSBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNoZWNrcy4gRm9yIGxpdmVu ZXNzIGRldGVjdGlvbiwgQkZEIGlzIHByZWZlcnJlZA0KIHRvb2wsIGF0bGVhc3QgaW4gcHJlc2Vu dCBkZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1TIHNvbHV0aW9uIGlzIGRlc2lnbmVk IGZvciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5vdCB0byBwZXJmb3JtIHZhbGlkYXRpb24gb2Yg ZGF0YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBldGM/IChJIHRoaW5rIHlvdSBhZ3JlZSB0byB0 aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxzbyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5iKSBvbmNlIFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5l IGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSw8 YnI+DQombmJzcDsgJm5ic3A7aXQgY2FuIGNvbnRpbnVlIHRvIGV4ZWN1dGUgYXJiaXRyYXJ5IExT UCBjb21iaW5hdGlvbnMgYW5kIHRoZSBtb25pdG9yaW5nIHBhY2tldHMgc3RheTxicj4NCiZuYnNw OyAmbmJzcDtpbiBkYXRhIHBsYW5lLiBQbGVhc2UgcG9pbnQgbWUgdG8gdGhlIHRleHQgaW4gcHJv eHktcGluZyBvZmZlcmluZyB0aGlzIGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4lc2FtIC0gVGhpcyB5b3UgY291bGQg cGVyZm9ybSBldmVuIHdpdGhvdXQgcHJveHkgcGluZy4gVGhlIGZ1bmN0aW9uIHlvdSBhcmUgZGVz Y3JpYmluZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBsc3AgcGlu ZyBkb2VzLiBBZ2FpbiBJIGFtIG5vdCB0YWxraW5nIGFib3V0IG5vbi1tcGxzDQogdG9wb2xvZ3ku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRv IGFuc3dlciB5b3VyIHF1ZXN0aW9uLCBob3cgeW91IHBlcmZvcm0uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUGVyZm9ybSB0cmVldHJhY2Ug d2l0aCByZmM0Mzc5IHRvIGdldCB0b3BvbG9neSBpbmZvPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBh dGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIHBl cmZvcm0gcGluZyB3aXRoIHJpZ2h0IHNlbGVjdG9ycyBmb3IgdGhlIHBhdGggYW5kIHVzZSBUVEwg Zm9yIGxpbWl0aW5nIHRoZSBob3AgW0xFUiBqXS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBpZiB5b3Ugd2FudCB0byBwZXJmb3JtIGZyb20g TEVSIGkgdG8gTEVSIGogYXMgaW4geW91ciBkcmFmdCwgdXNlIHByb3h5IHBpbmcgdG8gc3RhcnQg ZnJvbSBMRVIgaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50 IGJhY2sgdG8gUE1TIHdoaWNoIGlzIG5vdCBwYXJ0IG9mIE1QTFMgb3Igc2VnbWVudDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkb21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1 cml0eSBhc3BlY3QsIHdoaWNoIG5lZWRzIHRvIGNvbnNpZGVyZWQuIEkgYmVsaWV2ZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpdCBhcHBsaWVzIHRvIHNlbmRpbmcgYSByZXF1ZXN0 IHRvby4gV2lsbCB5b3UgYmUgZG9jdW1lbnRpbmcgdGhhdCBhc3BlY3Q/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W1JHXSBUaGF0J3MgYSB2YWxpZCBwb2lu dC4gVGhlIGRvbWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0g d2lsbCBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9u IG9uY2Ugd2UgYXJlIGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsDQogbm90IGFuYWx5c2UgdGhp cyBpbiBkZXB0aCBmb3IgYSB1c2UgY2FzZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiVzYW0gLSBub2QmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgNC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25l IGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRoIFJGQzQzNzkgcGluZzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB3aXRoIG11bHRwYXRoICYjNDM7IHByb3h5IHBpbmcuIENvdWxkIHlvdSBr aW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmc8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgbmV3IHRoZSBzb2x1dGlvbiBicmluZ3MgaGVyZT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bUkddIFRoZSBTUiBPQU0gYXV0 aG9yIHRlYW0gaGFzIHByb3ZpZGVkIHRleHQgaG93IHRvIG1vbml0b3IgYSBidW5kbGVkIGxpbmsg aW4gdGhlIHVzZSBjYXNlIGRyYWZ0LiBZb3UgYXJlIGEgY28tYXV0aG9yIG9mIHByb3h5LWxzcC4g SSBjb3VsZG4ndCBmaW5kIGV4cGxpY2l0IHRleHQgb24gaG93IHRvIGRldGVjdA0KIGFuZCBtb25p dG9yIGEgYnVuZGxlZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhv dyBwcm94eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkg aWYgdGhpcyBpcyBvYnZpb3VzIGFuZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJl bmNlcyB0byB0aGUgU1IgT0FNIGFwcHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4lc2Ft IC0gVGhlIHNhbWUgc3RlcHMgZGVzY3JpYmVkIGFib3ZlIGNvdWxkIGJlIHVzZWQgaWYgZWFjaCBi dW5kbGVkIGxpbmsgbWVtYmVyIGlzIGlkZW50aWZpZWQgd2l0aCBhIHVuaXF1ZSBsYWJlbC4gV2hp bGUgcGVyZm9ybWluZyB0cmVlIHRyYWNlIG9yIHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdp bGwNCiByZXNwb25kIHdpdGggRERNQVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRo ZSBtdWx0aXBhdGggaW5mbyBmb3IgdGhlIHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSBzYXkgdGhhdCBlYWNoIGxpbmsgbWVt YmVyIGhhcyBzYW1lIGxhYmVsIHN0YWNrLCB0aGVuIHlvdSBjb3VsZCB1c2UgbHNwIHNlbGVjdG9y cyBhcyBkZWZpbmVkIGluIFJGQzQzNzksIGluIHRoaXMgY2FzZSBpdCBpcyBsb2NhbCBob3N0IGRl c3QgaXAgYWRkciwgdG8gaWRlbnRpZnkgZWFjaCBsaW5rDQogbWVtYmVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ob3cgaWYgdGhlIE1QTFMg Zm9yd2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBi dXQgY2Fubm90IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2 YWxpZGF0ZSB0aGUgaW50ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2FtZSBh cHBsaWVzIGluIHlvdXIgY2FzZSB0b28uIENhbm5vdCBzZWUgaG93IGl0IGlzIGRpZmZlcmVudC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzUuIHNlYyAjNSwgSXMgdGhlIHJlcXVp cmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3BvbG9neSwgaW4gdGhlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FzZSBvZiBtaXhl ZCBlbnY/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W1JH XSBNUExTIHRvcG9sb2d5IGF3YXJlbmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1cCBw YWNrZXRzIHdpdGggbGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQ cy4gSWYgc3VpdGFibGUgTGFiZWwvRkVDL25vZGUgcmVsYXRpb24gaXMga25vd24gdG8gdGhlIFBN UywNCiB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQTVMg bW9uaXRvcmluZyBwYWNrZXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4lc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91 IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0cmFjZSB0byBnZXQg dG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2VkIGlu IFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvDQogb3RoZXIgdGhhbiBsYWJlbCBzdGFjay4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QW5kIHRoZSBwcm9wb3NlZCBQTVMgc29sdXRpb24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwg aXQgcGVyZm9ybXMgb24gZGVtYW5kIHBlciBzZWdtZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28g ZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgdG9wb2xvZ3kuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjYXNlIHlvdSBhcmUgbWFraW5n IGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlF1ZXN0 aW9uIEkgaGF2ZSBmb3IgeW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMgYXJlIGdldHRpbmcg ZHJvcHBlZCBhbmQgUE1TIHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4gTFNQIG9y IFNlZ21lbnQsIGhvdyBkbyB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93 LA0KIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBpdCBpcz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgbGVhc3Qgd2l0aCBSRkM0Mzc5 IGFuZC9vciBwcm94eSBwaW5nLCB5b3UgY291bGQgdmFsaWRhdGUgZWFjaCBob3AgYmVjYXVzZSBv ZiB0aGUgYmVsbHMgYW5kIHdoaXN0bGVzIGl0IGNhcnJpZXMgYWxvbmcgd2l0aCB0aGUgcGFja2V0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ni4gSW4gc2VjIDMuMSw8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3NuaXAmZ3Q7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVj dXRlZCBwcmlvciB0byBhIG1lYXN1cmVtZW50IG1heSBhbHNvIGJlPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvbmUgYnkgc2V0dGluZyB1cCBhIGxhYmVsIGluY2x1ZGlu ZyBhbGwgbm9kZSBTSURzIGFsb25nIHRoYXQgcGF0aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsoaWYgTEVSMSBoYXMgTm9kZSBTSUQgNDAgaW4gdGhlIGV4YW1wbGUgYW5k IGl0IHNob3VsZCBiZSBwYXNzZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7YmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAtIDQwIC0g MzAgLSAxMCkuICZuYnNwO1RoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDthZHZhbnRhZ2Ugb2YgdGhpcyBtZXRob2QgaXMsIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBN UExTIE9BTTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmdW5jdGlvbmFs aXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gJm5ic3A7 VGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21ldGhvZCBzdGlsbCBp cyBhYmxlIHRvIG1vbml0b3IgYWxsIGxpbmsgY29tYmluYXRpb25zIG9mIGFsbCBwYXRocyBvZjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbiBNUExTIGRvbWFpbi4gJm5i c3A7SWYgY29ycmVjdCBmb3J3YXJkaW5nIGFsb25nIHRoZSBkZXNpcmVkIHBhdGhzIGhhcyB0bzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBjaGVja2VkLCBSRkM0NzM5 IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGFwcGxpZWQgYWxzbyBpbiB0aGlzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtlbmQgc25pcCZndDs8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQg aXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JGQzQzNzkgZnVuY3Rpb25hbGl0eSBjb3Vs ZCBiZSB1c2VkLiBDb3VsZCB5b3UgY2xhcmlmeSBob3cgY291bGQgeW91IHZlcmlmeSBhPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhdGgsIGlmIE1QTFMgdmFsaWRhdGlv biBpcyBub3QgZG9uZS4gTW9yZSB0ZXh0IHdpbGwgaGVscC4gQWxzbywgbW9yZTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGll ciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtPQU0gaGFzIHRvIGJlIHBlcmZvcm1lZCBmb3IgdG9w b2xvZ3kgY2hhbmdlcyBldGMuIElmIHNvLCBpdCBjb250cmFkaWN0cyBoZXJlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltSR10gVGhlIHRleHQgc2hvdWxk IHNheSB0aGF0PGJyPg0KLSB3aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVj dXRlcyBhIHNldCBvZiBwYXRocyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRp b24uPGJyPg0KLSBpZiB0aGUgb3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBw bGFuZSBjb3JyZXNwb25kcyB0byBjb250cm9sIHBsYW5lLCBSRkM0NzM5IGZ1bmN0aW9ucyBzaG91 bGQgYmUgYXBwbGllZC48YnI+DQpJZiB5b3UgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQg dGhlIHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRlcyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRy eSB0byByZXdvcmQgaXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4lc2FtIC0gVGhlIHByb2JsZW0gSSBhbSBoYXZpbmcgaXMsIGlu IHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlvdSBoYXZlIHRvIHZhbGlkYXRlIHRoZSBsc3Au PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg ZGVmaW5pdGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVl bCBpcywgdGhlIHVzZSBjYXNlIGlzIHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZp c2lvbmVkIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbmNlIHlvdSByZW1vdmUgc29sdXRpb24gb3Igc3VnZ2VzdGVkIGVuaGFu Y2VtZW50cywgaG9wZSBpdCBzaG91bGQgYmUgY2xlYXIgb24gd2hhdCBpcyBiZWluZyBzb2x2ZWQg YW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMgZm9yIGEgc29sdXRpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBzb2x1dGlv biBwYXJ0LCBwbGVhc2UgcHVibGlzaCBhIHNlcGFyYXRlIElELjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Ny4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZlcmVudCBpcyBQTVMg ZnJvbSBFTVMgYW5kIE5NUz88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 U29tZWhvdyBJIGNvdWxkbid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ugd2hhdCBQTVMgY291bGQgZG8g YW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05NUy9FTVMgY291bGRu J3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W1JHXSBJ J3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9OTVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2Fy ZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBw YWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmluYXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0 b3IuDQogSGFkIHRoaXMgZmVhdHVyZSBiZWVuIGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBj b21wYW55IEkgd29yayBmb3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4lc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNo IHBlcmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lmaWMgb3BlcmF0aW9ucyAmbmJzcDtmb3IgYSBn aXZlbiBzZXQgb2YgTFNQJ3MuIFRoZXkgcGVyZm9ybSBUcmVldHJhY2UgYW5kIHBlcmZvcm0gcGlu ZyB3aXRoIG11bHRpcGF0aC4NCiBBbHNvIHBlcmZvcm0gTFNQIHNwZWNpZmljIHZhbGlkYXRpb24g YnkgY3JhZnRpbmcgcGFja2V0cyB3aXRoIGRhdGEgYXZhaWxhYmxlIHdpdGggdHJlZXRyYWNlIGFu ZCBwaW5nIHdpdGggbXVsdGlwYXRoLiBZb3UgY291bGQgYXV0b21hdGUgdGhlIHdvcmtmbG93IHdp dGhvdXQgdGhlIG5lZWQgZm9yIE9TUy9QTVMsIGJ5IHVzaW5nIHByb2JlIHRlY2hub2xvZ3kuIFdp bGwgbm90IHNheSBiZXlvbmQgdGhhdCA6RDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Y2hlZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1zYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CECE764681BE964CBE1DFF78F3CDD3941E262B0Dxmbalnx01ciscoc_-- From nobody Fri Jul 11 00:15:35 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC11B2923 for ; Fri, 11 Jul 2014 00:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arY61DoGmrKS for ; Fri, 11 Jul 2014 00:15:25 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD5F1B2903 for ; Fri, 11 Jul 2014 00:15:22 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jul 2014 09:15:16 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 11 Jul 2014 09:15:16 +0200 From: To: , Date: Fri, 11 Jul 2014 09:15:14 +0200 Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLw///FEwCAAEpvIP//4WtQ Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8C84AAFHE111643EMEA1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/_2rGlNuvs5GETHBJKQCRaHnYsLk Cc: spring@ietf.org, draft-geib-spring-oam-usecase@tools.ietf.org Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 07:15:31 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8C84AAFHE111643EMEA1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTm9ibywgaGkgU2FtDQoNCnRoZSB1c2UgY2FzZSBpcyB0byBlbmFibGUgbW9uaXRvcmluZyBv ZiBhbiBNUExTIGRvbWFpbiB3aXRob3V0IGFjY2Vzc2luZyB0aGUgY29udHJvbCBwbGFuZS4gVG8g ZG8gc28sIGEgUE1TIG5lZWRzIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzLCB3aGljaCBpdCBnZXRz IGJ5IFNlZ21lbnQgUm91dGluZy4gVGhlIGRyYWZ0IHRvIHNvbWUgZXh0ZW50IGV4cGxhaW5zIGhv dyB0aGF0IGlzIGRvbmUsIHdpdGhvdXQgZ29pbmcgaW50byB0b28gbWFueSBkZXRhaWxzLCBJIHRo aW5rLg0KDQpNb25pdG9yaW5nIHdpdGhvdXQgY29udHJvbCBwbGFuZSBhY2Nlc3MgaXMgcGFydCBv ZiB0aGUgdXNlIGNhc2UsIG5vdCBwYXJ0IG9mIGEgc29sdXRpb24gZGlzY3Vzc2lvbiAodG8gc2F5 IGl0IGRpZmZlcmVudGx5OiB1c2luZyB0aGUgZGF0YSBwbGFuZSBmb3IgT0FNIHB1cnBvc2VzIGlz IG5vdCBhbiBvcHRpb24gd2hpY2ggbWF5IGJlIHJlbW92ZWQpLiBBcyBtYW55IFNSIGJhc2VkIE9B TSBmZWF0dXJlcyBjYW4gYmUgdXNlZCB3aXRob3V0IE9BTSBzcGVjaWZpYyBwcm90b2NvbHMgb3Ig ZnVuY3Rpb25zIGJlaW5nIGFkZGVkIHRvIFNlZ21lbnQgUm91dGluZywgSSB0aGluayBpdOKAmXMg cGVyZmVjdGx5IG9rIHRvIGZvcm11bGF0ZSB0aGUgdXNlIGNhc2UgYXMgaXMuIFRoZSBtYWluIHJl cXVpcmVtZW50IGlzOiBzcGVjaWZ5IFNlZ21lbnQgUm91dGluZy4gVGhlbiBvbmUgbWF5IGFkZCBP QU0gYm94ZXMgd2hpY2ggYXBwbHkgU1IgZmVhdHVyZXMuDQoNClJGQzQzNzkgY291bGQgYWxzbyBt b25pdG9yIExTUHMsIGJ1dCBpdCByZXF1aXJlcyB1c2luZyB0aGUgY29udHJvbCBwbGFuZSBhbmQg cHJveHktbHNwLXBpbmcgYWRkcyBjb250cm9sIHBsYW5lIGJhc2VkIGZ1bmN0aW9uYWxpdHkgdG8g UkZDNDM3OS4gSXQgaXMgYW4gYXBwcm9hY2ggcmVzdWx0aW5nIGluIHNpbWlsYXIgZmVhdHVyZXMs IGJ1dCBpdCBpcyBjb250cm9sIHBsYW5lIGJhc2VkLiBUaGlzIGlzIGEgZGlmZmVyZW50IHVzZSBj YXNlLg0KDQpJZiBhbiBvcGVyYXRvciBuZWVkcyB0byB2YWxpZGF0ZSB0aGF0IGEgcGFja2V0IHRy YXZlbHMgYSBjZXJ0YWluIHBhdGggb3IgdHJhY2UgdGhlIHBhdGggYSBsb3N0IHBhY2tldCBoYXMg dGFrZW4sIHRoZW4gUkZDNDM3OSBmdW5jdGlvbmFsaXR5IGlzIG5lZWRlZC4gSXTigJlzIGEgZGlm ZmVyZW5jZSB3aGV0aGVyIFJGQzQzNzkgaXMgYXBwbGllZCBvbmx5IGF0IG9mZiBwZWFrIHRpbWVz IG9yIGFmdGVyIGEgZGF0YSBwbGFuZSBvbmx5IG1vbml0b3JpbmcgcGFja2V0IGhhcyBiZWVuIGxv c3QgYWxvbmcgb25lIHBhdGggb3Igd2hldGhlciB0aGF0IGhhcyB0byBiZSBkb25lIGNvbnN0YW50 bHkuDQoNClJlZ2FyZHMsDQoNClJ1ZWRpZ2VyDQoNClZvbjogTm9ibyBBa2l5YSAobm9ibykgW21h aWx0bzpub2JvQGNpc2NvLmNvbV0NCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAxMC4gSnVsaSAyMDE0 IDIxOjQ2DQpBbjogU2FtIEFsZHJpbg0KQ2M6IEdlaWIsIFLDvGRpZ2VyOyBzcHJpbmc7IGRyYWZ0 LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQpCZXRyZWZmOiBSRTogW3NwcmluZ10gUXVlc3Rpb25z DQoNCkhpIFNhbSwNCg0KSSBqdXN0IHdhbnRlZCB0byBwb2ludCBvdXQgdGhlIGtleSBkZXNjcmli ZWQgYmVoYXZpb3IsIHdhc27igJl0IHNheWluZyBhbnl0aGluZyBhYm91dCB3aGV0aGVyIHRoaXMg ZG9jdW1lbnQgc2hvdWxkIGJlIGEgdXNlLWNhc2UgZG9jdW1lbnQgb3IgYSBzb2x1dGlvbiBkb2N1 bWVudCDimLoNCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQpGcm9tOiBTYW0gQWxkcmluIFttYWlsdG86 YWxkcmluLmlldGZAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMzox MCBQTQ0KVG86IE5vYm8gQWtpeWEgKG5vYm8pDQpDYzogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl PG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+OyBzcHJpbmc7IGRyYWZ0LWdlaWItc3By aW5nLW9hbS11c2VjYXNlDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIE5v Ym8sDQoNCklubGluZSBmb3IgbXkgY29tbWVudHMuDQoNCk9uIFRodSwgSnVsIDEwLCAyMDE0IGF0 IDExOjU5IEFNLCBOb2JvIEFraXlhIChub2JvKSA8bm9ib0BjaXNjby5jb208bWFpbHRvOm5vYm9A Y2lzY28uY29tPj4gd3JvdGU6DQpIaSBTYW0sDQoNCkp1c3QgdG8gcG9pbnQgb3V0IG9uZSB0aGlu ZyBhYm91dCB0aGlzIGRvY3VtZW50IOKApg0KDQpUaGUgdGVzdCBwYWNrZXQgZ2VuZXJhdGVkIGZy b20gYSBQTVMvTk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4gaGF2ZSB0aGUgY29tcGxldGUgc2Vn bWVudCBzdGFjayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdvcmsgYXMgd2VsbCBhcyBob3cg dG8gY29tZSBiYWNrIHRvIHNlbGYgd2l0aG91dCBhbnkgZnVydGhlciBzaWduYWxpbmcsIE9BTSBz dGF0ZSBtYWludGVuYW5jZSBvbiBuZXR3b3JrIG5vZGVzIG5vciBPQU0gaW52b2x2ZW1lbnQgYnkg bmV0d29yayBub2Rlcy4NClRoYXQgaXMgZmluZSBhcyBhIHJlcXVpcmVtZW50L3VzZWNhc2UgYW5k IHdlIHNob3VsZCBsaW1pdCB0aGUgc2NvcGUgdG8gdGhhdCwgdGhhbiBzcGVjaWZ5aW5nIGhvdyB0 byBzb2x2ZSBpdC4NCg0KVGhhdCBtYWtlcyB0aGlzIGFwcHJvYWNoIHF1aXRlIGRpZmZlcmVudCBm cm9tIHVzaW5nIHByb3h5IExTUCBwaW5nLg0KWW91IGFyZSB0YWxraW5nIGFib3V0IHNvbHV0aW9u IG9yIHVzZSBjYXNlPyA6RA0KDQoNClRoaXMgY2VydGFpbmx5IGhhcyBzb21lIHByb3MgYW5kIGNv bnMgYnV0IGNhbiBiZSBxdWl0ZSB1c2VmdWwgYXMgb25lIG9mIHRoZSBPQU1zICh5ZXMgcGx1cmFs KSB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQpDZXJ0YWlubHkuIEJ1dCBJIGFtIHN0cnVn Z2xpbmcgYmV0d2VlbiB1c2UgY2FzZSBhbmQgc29sdXRpb24gb3V0bGluZWQgaW4gdGhlIGRvY3Vt ZW50LiBQaWNrIG9uZSA6RA0KDQotc2FtDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KRnJvbTogc3By aW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5 IDEwLCAyMDE0IDI6MTMgUE0NClRvOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU8bWFpbHRvOlJ1 ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4NCkNjOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9h bS11c2VjYXNlDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIFJ1ZWRpZ2Vy LA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9u c2VzIGlubGluZS4NCg0KT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwgPFJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPj4gd3JvdGU6 DQpIaSBTYW0sDQoNCm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3Vy IHRleHQuDQoNCi0gUHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFy Y2hpdGVjdHVyZSBpcyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyArIElQ djYpLiBXZSdsbCBjbGFyaWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Lg0KLSBQcm94eS1sc3AtcGluZyBp cyBmb3IgTVBMUyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2Ug Y2FzZSBjYW4gdXNlIGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBm b3IgQkZELCBhbmQgSUNNUHY2KQ0KDQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdp dGggYnJvYWRlciBzY29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuDQol c2FtIC0gSSBiZWxpZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cuIFRo ZW4gc29sdXRpb24gaXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9mIHRpbWUsIGFzIHdl IGhhdmVuJ3QgZGVsaWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBlaXRoZXIuDQoNCkFzIHlv dSB3cml0ZSwgU1IgYmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMg YXMgcHJveHktbHNwLiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBh bmQgTEVSL0xTUiBwcm9jZXNzaW5nIGludHJvZHVjZWQgYnkgcHJveHktbHNwLg0KDQpSZWdhcmRz LA0KDQpSdWVkaWdlcg0KDQoNCiAgICAgIFNhbSBBbGRyaW4gd3JvdGU6DQoNCiAgICAgIEkgaGF2 ZSBmZXcgcXVlc3Rpb25zIGFib3V0IHRoaXMgZHJhZnQuDQoNCiAgICAgIDEuIFRoZSB0aXRsZSBp cyBjb25mdXNpbmcgdG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMx DQogICAgICBpdCBzYXlzIHRoZSBmb2xsb3dpbmcNCg0KICAgICAgPHNuaXA+DQogICAgICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50 IGFuZA0KICAgICAgIGlsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLg0KDQogICAgICAgVGhl IHNvbHV0aW9uIGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLg0KDQog ICAgICAgVGhlIHNvbHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMg d2VsbCBhcyB0bw0KICAgICAgIG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuDQog ICAgICA8ZW5kIHNuaXA+DQoNCiAgICAgICBJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5n IGEgc29sdXRpb24gdG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0DQogICAgICAgcHJv dmlkaW5nIHVzZSBjYXNlcy9zY2VuYXJpb3MuIE15IHVuZGVyc3RhbmRpbmcgd2FzLCB1c2UgY2Fz ZSBkcmFmdCBzaG91bGQNCiAgICAgICBkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBk cml2ZSBuZXcgcmVxdWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQNCiAgICAgICBiZSBjb3ZlcmVk IHdpdGggZXhpc3RpbmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBlbmRpbmcgb24gdGhl IEdBUA0KICAgICAgIGFuYWx5c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhl cmUgY291bGQgYmUgbW9yZSB0aGFuIDEgc29sdXRpb24sDQogICAgICAgd2hlcmUgYXMgdGhpcyBk b2N1bWVudCBjb3VsZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Lg0KDQogICAgICAgSWYg aW5mYWN0IHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBj aGFuZ2luZyB0aGUgdGl0bGUNCiAgICAgICB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQn cyBteSBvYnNlcnZhdGlvbi4NCltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNhc2UgZG9jdW1lbnQu IFdlJ2xsIHJldmlldyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuDQolc2FtIC0gT0suIHRoZW4gSSdk IGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIHRoYXQg d2F5IHdlIGRvbnQgaGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRpb25zIGRvZXMgZWl0 aGVyIG9yIGNvbXBhcmUgd2l0aCA6RA0KDQoNCiAgICAgICAyLiB3LnIudC4gU2VjdGlvbiBudW1i ZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIHdpdGgNCiAgICAgICAiZHJh ZnQtaWV0Zi1tcGxzLXByb3h5LWxzcC1waW5nLTAyIiAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVk IGluIHRoaXMNCiAgICAgICBzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJveHkgcGlu Zyhzb2x1dGlvbiB3aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZA0KICAgICAgIGJlIHNlbnQgdG8g bW9uaXRvciBMRVIgaSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJz dGFuZGluZw0KICAgICAgIHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT8N CltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0 YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQNCiAgICAgY2hhaW4gb2YgTVBMUyBMU1BzLg0K JXNhbSAtIEV4ZWN1dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVs c2U/DQoNCltSR10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2Nv bCBleHRlbnNpb25zIHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG8NCiAgIGFsbG93IGEgdGhpcmQg cGFydHkgdG8gcmVtb3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bw0K ICAgYmUgc2VudCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLg0KJXNhbSAtIElmIGl0IGlz IHByb3Bvc2luZyBleHRlbnNpb25zLCAgaXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICBh bmQgY2Fubm90IGNsYWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1l bnQgaXMgb24gaW5mb3JtYXRpb24gdHJhY2suDQoNCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0 aGF0IGlmIHlvdSdkIGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxp dHkgb24gYW55IExTUCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5n LiBUaGUgUE1TIGhvd2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkcw0KZnVuY3Rpb25hbGl0eToNCmEp IFlvdSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBs aWtlIHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YQ0KICAgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3 OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxlbWVudGF0aW9u Lg0KJXNhbSAtIFJGQzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxhbmUgYW5kIGFs c28gZmluZCBvdXQgbG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24s IEJGRCBpcyBwcmVmZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRlcGxveW1lbnRzLlNv IGFyZSB5b3Ugc2F5aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9yIGxpdmVuZXNzIGRl dGVjdGlvbiBhbmQgbm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRhIHBsYW5lIHRvIGNv bnRyb2wgcGxhbmUsIGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMgaW4gdGhlIGxhdGVy IHBhcnQgb2YgdGhlIGRvYyBhbHNvKQ0KDQpiKSBvbmNlIFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5l IGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSwN CiAgIGl0IGNhbiBjb250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25z IGFuZCB0aGUgbW9uaXRvcmluZyBwYWNrZXRzIHN0YXkNCiAgIGluIGRhdGEgcGxhbmUuIFBsZWFz ZSBwb2ludCBtZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVhdHVy ZS4NCiVzYW0gLSBUaGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5n LiBUaGUgZnVuY3Rpb24geW91IGFyZSBkZXNjcmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGlu ZyByYXRoZXIgdGhhbiB3aGF0IGxzcCBwaW5nIGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcg YWJvdXQgbm9uLW1wbHMgdG9wb2xvZ3kuDQpUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlv dSBwZXJmb3JtLg0KLSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9s b2d5IGluZm8NCi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVyZWQgYWxvbmcg d2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLg0KLSBwZXJmb3JtIHBpbmcgd2l0aCBy aWdodCBzZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUg aG9wIFtMRVIgal0uDQotIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIg aiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpDQoN CiAgICAgICAgMy4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBNUyB3aGljaCBp cyBub3QgcGFydCBvZiBNUExTIG9yIHNlZ21lbnQNCiAgICAgICAgZG9tYWluLCB0aGVyZSBpcyBh IHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJl bGlldmUNCiAgICAgICAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwg eW91IGJlIGRvY3VtZW50aW5nIHRoYXQgYXNwZWN0Pw0KW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2lu dC4gVGhlIGRvbWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0g d2lsbCBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9u IG9uY2Ugd2UgYXJlIGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMg aW4gZGVwdGggZm9yIGEgdXNlIGNhc2UgZG9jdW1lbnQuDQolc2FtIC0gbm9kDQoNCiAgICAgICAg NC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhh dCB3aXRoIFJGQzQzNzkgcGluZw0KICAgICAgICB3aXRoIG11bHRwYXRoICsgcHJveHkgcGluZy4g Q291bGQgeW91IGtpbmRseSBkaWZmZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZw0KICAg ICAgICBuZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KW1JHXSBUaGUgU1IgT0FNIGF1dGhv ciB0ZWFtIGhhcyBwcm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGlu IHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkg Y291bGRuJ3QgZmluZCBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3Ig YSBidW5kbGVkIGxpbmsgaW4gZHJhZnQtcHJveHktbHNwLiBQbGVhc2UgZGVzY3JpYmUgaG93IHBy b3h5LWxzcCBjYW4gYmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIChzb3JyeSBpZiB0 aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2Vz IHRvIHRoZSBTUiBPQU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS4NCiVzYW0gLSBUaGUg c2FtZSBzdGVwcyBkZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQg bGluayBtZW1iZXIgaXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJm b3JtaW5nIHRyZWUgdHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNw b25kIHdpdGggRERNQVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBh dGggaW5mbyBmb3IgdGhlIHNhbWUuDQpJZiB5b3Ugc2F5IHRoYXQgZWFjaCBsaW5rIG1lbWJlciBo YXMgc2FtZSBsYWJlbCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBzZWxlY3RvcnMgYXMg ZGVmaW5lZCBpbiBSRkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdCBkZXN0IGlw IGFkZHIsIHRvIGlkZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQpOb3cgaWYgdGhlIE1QTFMgZm9y d2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBidXQg Y2Fubm90IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2YWxp ZGF0ZSB0aGUgaW50ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy4NClNhbWUg YXBwbGllcyBpbiB5b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQu DQoNCg0KDQogICAgICAgICA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVudCBoZXJlIG9ubHkg Zm9yIFBNUyB0byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZQ0KICAgICAgICAgICAgY2FzZSBv ZiBtaXhlZCBlbnY/DQpbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25k aXRpb24gdG8gc2V0IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhlY3V0aW5nIGEgZGVz aXJlZCBjaGFpbiBvZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9kZSByZWxhdGlvbiBp cyBrbm93biB0byB0aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5v ZGUgb24gYnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuDQolc2FtIC0gU28sIHlvdSBhcmUgc2F5 aW5nIHRoYXQgeW91IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0 cmFjZSB0byBnZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5n IHByb3Bvc2VkIGluIFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFi ZWwgc3RhY2suDQpBbmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBp cyB0aGF0LCBpdCBwZXJmb3JtcyBvbiBkZW1hbmQgcGVyIHNlZ21lbnQsIHdoaWNoIFByb3h5IHBp bmcgYWxzbyBkb2VzLCBhbGJlaXQgb25seSBmb3IgTVBMUyB0b3BvbG9neS4NClRoZSBjYXNlIHlv dSBhcmUgbWFraW5nIGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZD NDM3OS4NCg0KUXVlc3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEgcGxhbmUgcGFja2V0 cyBhcmUgZ2V0dGluZyBkcm9wcGVkIGFuZCBQTVMgcGFja2V0cyBnb2luZyB0aHJvdWdoLCBmb3Ig YSBnaXZlbiBMU1Agb3IgU2VnbWVudCwgaG93IGRvIHlvdSBrbm93IHRoZXJlIGlzIGEgcHJvYmxl bT8gaWYgeW91IGtub3csIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBpdCBpcz8NCkF0IGxl YXN0IHdpdGggUkZDNDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxkIHZhbGlkYXRlIGVh Y2ggaG9wIGJlY2F1c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25n IHdpdGggdGhlIHBhY2tldC4NCg0KDQoNCiAgICAgICAgIDYuIEluIHNlYyAzLjEsDQogICAgICAg ICA8c25pcD4NCiAgICAgICAgIERldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlv ciB0byBhIG1lYXN1cmVtZW50IG1heSBhbHNvIGJlDQogICAgICAgICBkb25lIGJ5IHNldHRpbmcg dXAgYSBsYWJlbCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IHBhdGgNCiAgICAg ICAgIChpZiBMRVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxk IGJlIHBhc3NlZA0KICAgICAgICAgYmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBz dGFjayBpcyAyMCAtIDQwIC0gMzAgLSAxMCkuICBUaGUNCiAgICAgICAgIGFkdmFudGFnZSBvZiB0 aGlzIG1ldGhvZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNDQogICAgICAg ICBmdW5jdGlvbmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxp dGllcy4gIFRoZQ0KICAgICAgICAgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwg bGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9mDQogICAgICAgICBhbiBNUExTIGRvbWFp bi4gIElmIGNvcnJlY3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG8N CiAgICAgICAgIGJlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBw bGllZCBhbHNvIGluIHRoaXMNCiAgICAgICAgIGNhc2UuDQoNCiAgICAgICAgIDxlbmQgc25pcD4N Cg0KICAgICAgICAgSW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBub3QgaW52 b2x2ZSBNUExTIE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksDQogICAgICAgICBSRkM0Mzc5IGZ1bmN0 aW9uYWxpdHkgY291bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IGNvdWxkIHlvdSB2 ZXJpZnkgYQ0KICAgICAgICAgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBN b3JlIHRleHQgd2lsbCBoZWxwLiBBbHNvLCBtb3JlDQogICAgICAgICBpbXBvcnRhbnRseSwgdGhl IHRleHQgZWFybGllciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUw0K ICAgICAgICAgT0FNIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRj LiBJZiBzbywgaXQgY29udHJhZGljdHMgaGVyZS4NCltSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0 aGF0DQotIHdpdGhvdXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVzIGEgc2V0 IG9mIHBhdGhzIG9ubHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCi0gaWYg dGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVzcG9u ZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxpZWQu DQpJZiB5b3UgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRleHQgaW4gdGhlIGRy YWZ0IHN0YXRlcyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdvcmQgaXQuDQol c2FtIC0gVGhlIHByb2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1QTFMsIGZv ciBPQU0sIHlvdSBoYXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQpJIGRlZmluaXRlbHkgc2VlIGEg c3BlY2lmaWMgbmVlZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1c2UgY2Fz ZSBpcyB0b28gbXVjaCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1dGlvbi4N Ck9uY2UgeW91IHJlbW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3Bl IGl0IHNob3VsZCBiZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0 IGNsZWFyIHJlcXVpcmVtZW50cyBmb3IgYSBzb2x1dGlvbi4NCkZvciBzb2x1dGlvbiBwYXJ0LCBw bGVhc2UgcHVibGlzaCBhIHNlcGFyYXRlIElELg0KDQoNCiAgICAgICAgIDcuIExhc3QgYnV0IG5v dCB0aGUgbGVhc3QsIGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFuZCBOTVM/DQogICAg ICAgICBTb21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3Vs ZCBkbyBhbmQNCiAgICAgICAgIE5NUy9FTVMgY291bGRuJ3QuDQpbUkddIEkndmUgbmV2ZXIgaGVh cmQgb2YgYW4gRU1TL05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCB1c2VzIHRo aXMgdG9wb2xvZ3kgYXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0 aW5nIExTUCBjb21iaW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMg ZmVhdHVyZSBiZWVuIGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29yayBm b3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQolc2FtIC0gVGhlcmUgYXJl IHRvb2xzIHdoaWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMgdG9w b2xvZ3kgc3BlY2lmaWMgb3BlcmF0aW9ucyAgZm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5 IHBlcmZvcm0gVHJlZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0aXBhdGguIEFsc28g cGVyZm9ybSBMU1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBwYWNrZXRzIHdpdGgg ZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0aCBtdWx0aXBhdGguIFlv dSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BN UywgYnkgdXNpbmcgcHJvYmUgdGVjaG5vbG9neS4gV2lsbCBub3Qgc2F5IGJleW9uZCB0aGF0IDpE DQoNCmNoZWVycw0KLXNhbQ0KDQoNCg0K --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8C84AAFHE111643EMEA1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlNwcmVjaGJsYXNlbnRleHQgWmNobiI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlNwcmVjaGJsYXNlbnRleHRa Y2huDQoJe21zby1zdHlsZS1uYW1lOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazpTcHJlY2hibGFzZW50ZXh0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Ux OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRl eHQsIGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9REUg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIE5vYm8sIGhpIFNh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPnRoZSB1c2UgY2FzZSBp cyB0byBlbmFibGUgbW9uaXRvcmluZyBvZiBhbiBNUExTIGRvbWFpbiB3aXRob3V0IGFjY2Vzc2lu ZyB0aGUgY29udHJvbCBwbGFuZS4gVG8gZG8gc28sIGEgUE1TIG5lZWRzIE1QTFMgdG9wb2xvZ3kg YXdhcmVuZXNzLCB3aGljaCBpdCBnZXRzIGJ5IFNlZ21lbnQgUm91dGluZy4gVGhlIGRyYWZ0IHRv IHNvbWUgZXh0ZW50IGV4cGxhaW5zIGhvdyB0aGF0IGlzIGRvbmUsIHdpdGhvdXQgZ29pbmcgaW50 byB0b28gbWFueSBkZXRhaWxzLCBJIHRoaW5rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPk1vbml0b3Jpbmcgd2l0aG91dCBjb250cm9sIHBsYW5lIGFjY2VzcyBpcyBw YXJ0IG9mIHRoZSB1c2UgY2FzZSwgbm90IHBhcnQgb2YgYSBzb2x1dGlvbiBkaXNjdXNzaW9uICh0 byBzYXkgaXQgZGlmZmVyZW50bHk6IHVzaW5nIHRoZSBkYXRhIHBsYW5lIGZvciBPQU0gcHVycG9z ZXMgaXMgbm90IGFuIG9wdGlvbiB3aGljaCBtYXkgYmUgcmVtb3ZlZCkuIEFzIG1hbnkgU1IgYmFz ZWQgT0FNIGZlYXR1cmVzIGNhbiBiZSB1c2VkIHdpdGhvdXQgT0FNIHNwZWNpZmljIHByb3RvY29s cyBvciBmdW5jdGlvbnMgYmVpbmcgYWRkZWQgdG8gU2VnbWVudCBSb3V0aW5nLCBJIHRoaW5rIGl0 4oCZcyBwZXJmZWN0bHkgb2sgdG8gZm9ybXVsYXRlIHRoZSB1c2UgY2FzZSBhcyBpcy4gVGhlIG1h aW4gcmVxdWlyZW1lbnQgaXM6IHNwZWNpZnkgU2VnbWVudCBSb3V0aW5nLiBUaGVuIG9uZSBtYXkg YWRkIE9BTSBib3hlcyB3aGljaCBhcHBseSBTUiBmZWF0dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SRkM0Mzc5IGNvdWxkIGFsc28gbW9uaXRvciBMU1BzLCBi dXQgaXQgcmVxdWlyZXMgdXNpbmcgdGhlIGNvbnRyb2wgcGxhbmUgYW5kIHByb3h5LWxzcC1waW5n IGFkZHMgY29udHJvbCBwbGFuZSBiYXNlZCBmdW5jdGlvbmFsaXR5IHRvIFJGQzQzNzkuIEl0IGlz IGFuIGFwcHJvYWNoIHJlc3VsdGluZyBpbiBzaW1pbGFyIGZlYXR1cmVzLCBidXQgaXQgaXMgY29u dHJvbCBwbGFuZSBiYXNlZC4gVGhpcyBpcyBhIGRpZmZlcmVudCB1c2UgY2FzZS4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgYW4gb3BlcmF0b3IgbmVlZHMgdG8g dmFsaWRhdGUgdGhhdCBhIHBhY2tldCB0cmF2ZWxzIGEgY2VydGFpbiBwYXRoIG9yIHRyYWNlIHRo ZSBwYXRoIGEgbG9zdCBwYWNrZXQgaGFzIHRha2VuLCB0aGVuIFJGQzQzNzkgZnVuY3Rpb25hbGl0 eSBpcyBuZWVkZWQuIEl04oCZcyBhIGRpZmZlcmVuY2Ugd2hldGhlciBSRkM0Mzc5IGlzIGFwcGxp ZWQgb25seSBhdCBvZmYgcGVhayB0aW1lcyBvciBhZnRlciBhIGRhdGEgcGxhbmUgb25seSBtb25p dG9yaW5nIHBhY2tldCBoYXMgYmVlbiBsb3N0IGFsb25nIG9uZSBwYXRoIG9yIHdoZXRoZXIgdGhh dCBoYXMgdG8gYmUgZG9uZSBjb25zdGFudGx5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlJ1ZWRpZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE5vYm8gQWtpeWEgKG5vYm8pIFttYWlsdG86 bm9ib0BjaXNjby5jb21dIDxicj48Yj5HZXNlbmRldDo8L2I+IERvbm5lcnN0YWcsIDEwLiBKdWxp IDIwMTQgMjE6NDY8YnI+PGI+QW46PC9iPiBTYW0gQWxkcmluPGJyPjxiPkNjOjwvYj4gR2VpYiwg UsO8ZGlnZXI7IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2U8YnI+PGI+QmV0 cmVmZjo8L2I+IFJFOiBbc3ByaW5nXSBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgU2FtLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkganVzdCB3YW50ZWQgdG8gcG9p bnQgb3V0IHRoZSBrZXkgZGVzY3JpYmVkIGJlaGF2aW9yLCB3YXNu4oCZdCBzYXlpbmcgYW55dGhp bmcgYWJvdXQgd2hldGhlciB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBhIHVzZS1jYXNlIGRvY3Vt ZW50IG9yIGEgc29sdXRpb24gZG9jdW1lbnQgPC9zcGFuPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPko8 L3NwYW4+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Eg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4tTm9ibzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gU2FtIEFsZHJpbiBbPGEgaHJlZj0ibWFpbHRvOmFs ZHJpbi5pZXRmQGdtYWlsLmNvbSI+bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbTwvYT5dIDxi cj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMzoxMCBQTTxicj48Yj5Ubzo8 L2I+IE5vYm8gQWtpeWEgKG5vYm8pPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOlJ1ZWRp Z2VyLkdlaWJAdGVsZWtvbS5kZSI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPjsgc3ByaW5n OyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZTxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtz cHJpbmddIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5IaSBOb2JvLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUNBPklubGluZSBmb3IgbXkgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gbGFuZz1FTi1DQT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5PbiBUaHUsIEp1bCAxMCwgMjAxNCBh dCAxMTo1OSBBTSwgTm9ibyBBa2l5YSAobm9ibykgJmx0OzxhIGhyZWY9Im1haWx0bzpub2JvQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5vYm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBs YW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGkgU2FtLDwvc3Bhbj48c3BhbiBsYW5nPUVOLUNB PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVO LUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tQ0E+PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0Egc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5KdXN0IHRvIHBvaW50IG91dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1 bWVudCDigKY8L3NwYW4+PHNwYW4gbGFuZz1FTi1DQT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHRlc3QgcGFj a2V0IGdlbmVyYXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1kZXZpY2UgY2FuIGhhdmUg dGhlIGNvbXBsZXRlIHNlZ21lbnQgc3RhY2sgb24gaG93IHRvIHRyYXZlcnNlIHRoZSBuZXR3b3Jr IGFzIHdlbGwgYXMgaG93IHRvIGNvbWUgYmFjayB0byBzZWxmIHdpdGhvdXQgYW55IGZ1cnRoZXIg c2lnbmFsaW5nLCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0d29yayBub2RlcyBub3IgT0FN IGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuPC9zcGFuPjxzcGFuIGxhbmc9RU4tQ0E+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQ0E+VGhhdCBpcyBmaW5lIGFzIGEgcmVxdWlyZW1lbnQvdXNlY2FzZSBhbmQg d2Ugc2hvdWxkIGxpbWl0IHRoZSBzY29wZSB0byB0aGF0LCB0aGFuIHNwZWNpZnlpbmcgaG93IHRv IHNvbHZlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhdCBtYWtlcyB0aGlzIGFwcHJvYWNoIHF1 aXRlIGRpZmZlcmVudCBmcm9tIHVzaW5nIHByb3h5IExTUCBwaW5nLjwvc3Bhbj48c3BhbiBsYW5n PUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5Zb3UgYXJlIHRhbGtpbmcgYWJv dXQgc29sdXRpb24gb3IgdXNlIGNhc2U/IDpEPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9RU4tQ0E+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGlzIGNlcnRhaW5seSBoYXMgc29tZSBwcm9zIGFuZCBjb25zIGJ1dCBjYW4gYmUg cXVpdGUgdXNlZnVsIGFzIG9uZSBvZiB0aGUgT0FNcyAoeWVzIHBsdXJhbCkgdXNlZCB0byBtb25p dG9yIHRoZSBuZXR3b3JrLjwvc3Bhbj48c3BhbiBsYW5nPUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1DQT5DZXJ0YWlubHkuIEJ1dCBJIGFtIHN0cnVnZ2xpbmcgYmV0d2VlbiB1c2Ug Y2FzZSBhbmQgc29sdXRpb24gb3V0bGluZWQgaW4gdGhlIGRvY3VtZW50LiBQaWNrIG9uZSA6RDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPi1zYW0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1DQT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlRoYW5rcyE8L3NwYW4+PHNwYW4gbGFuZz1FTi1DQT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LU5vYm88L3NwYW4+ PHNwYW4gbGFuZz1FTi1DQT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPUVOLUNBPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBzcHJpbmcg W21haWx0bzo8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+ U2FtIEFsZHJpbjxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjoxMyBQ TTxicj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUi IHRhcmdldD0iX2JsYW5rIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+PGJyPjxiPkNjOjwv Yj4gc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZTxicj48Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczwvc3Bhbj48c3BhbiBsYW5nPUVOLUNBPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gbGFuZz1FTi1DQT4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPkhpIFJ1ZWRpZ2VyLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gbGFuZz1FTi1DQT5UaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQg bXkgcmVzcG9uc2VzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNBPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+T24gVGh1LCBKdWwgMTAs IDIwMTQgYXQgNzoxNSBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVr b20uZGUiIHRhcmdldD0iX2JsYW5rIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFu Zz1FTi1DQT5IaSBTYW0sPGJyPjxicj5teSByZXBsaWVzIGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRk ZWQgdG8geW91ciB0ZXh0Ljxicj48YnI+LSBQcm94eS1sc3AtcGluZyBpcyBNUExTIG9ubHksIHdo aWxlIHRoZSBQTVMgYXJjaGl0ZWN0dXJlIGlzIGludGVuZGVkIGZvciBldmVyeSBTUiBkYXRhIHBs YW5lIChNUExTICsgSVB2NikuIFdlJ2xsIGNsYXJpZnkgdGhhdCBpbiB0aGUgZHJhZnQuPGJyPi0g UHJveHktbHNwLXBpbmcgaXMgZm9yIE1QTFMgTFNQIFBpbmcgKFJGQyA0Mzc5IC8gUkZDIDY0MjQp LCB3aGlsZSBvdXIgdXNlIGNhc2UgY2FuIHVzZSBhbnkgT0FNIChpbiBwYXJ0aWN1bGFyLCBzcGVj aWZpYyBnb29kIHVzZXMgZm9yIEJGRCwgYW5kIElDTVB2Nik8YnI+PGJyPkJhc2VkIG9uIHRoYXQs IGl0wrlzIGEgc29sdXRpb24gd2l0aCBicm9hZGVyIHNjb3BlIGFuZCBiZXR0ZXIgZml0IGZvciBT UFJJTkcgYXMgYSB3aG9sZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBJIGJlbGlldmUgeW91IHNheSBp dCBpcyB1c2UgY2FzZSBkb2N1bWVudCBiZWxvdy4gVGhlbiBzb2x1dGlvbiBpcyB0b28gcHJlbWF0 dXJlIGF0IHRoaXMgcG9pbnQgb2YgdGltZSwgYXMgd2UgaGF2ZW4ndCBkZWxpYmVyYXRlZCBvbiB0 aGUgcmVxdWlyZW1lbnRzIGVpdGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT48YnI+QXMgeW91IHdyaXRlLCBTUiBiYXNlZCBP QU0gcGFydGlhbGx5IG9mZmVycyBzaW1pbGFyIGZ1bmN0aW9ucyBhcyBwcm94eS1sc3AuIFdpdGhv dXQgcmVxdWlyaW5nIHRoZSBhZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBMRVIvTFNSIHByb2Nlc3Np bmcgaW50cm9kdWNlZCBieSBwcm94eS1sc3AuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPjxicj5SZWdhcmRzLDxicj48 YnI+UnVlZGlnZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3Bh biBsYW5nPUVOLUNBPjxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU2FtIEFsZHJpbiB3cm90 ZTo8YnI+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSBmZXcgcXVlc3Rpb25zIGFib3V0 IHRoaXMgZHJhZnQuPGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBUaGUgdGl0bGUgaXMg Y29uZnVzaW5nIHRvIG1lLiBJdCBzYXlzIE9BTSB1c2UgY2FzZSBidXQgaW4gc2VjdGlvbiAjMTxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpdCBzYXlzIHRoZSBmb2xsb3dpbmc8YnI+PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDtzbmlwJmd0Ozxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSBzdGF0 ZW1lbnQgYW5kPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lsbHVzdHJhdGVzIGl0IHdp dGggdXNlLWNhc2VzLjxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNvbHV0 aW9uIGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLjxicj48YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNvbHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmlu ZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bzxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDttb25pdG9yaW5nIG9mIFNlZ21lbnQgUm91dGVkIExTUCdzLjxicj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7ZW5kIHNuaXAmZ3Q7PGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJ biBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5nIGEgc29sdXRpb24gdG8gY2VydGFpbiBzY2Vu YXJpb3MgYW5kIG5vdCBqdXN0PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Byb3ZpZGlu ZyB1c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNhc2UgZHJh ZnQgc2hvdWxkPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50IHNjZW5hcmlv cyB3aGVyZSBpdCB3aWxsIGRyaXZlIG5ldyByZXF1aXJlbWVudHMuIFNvbHV0aW9ucyBjb3VsZDxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBjb3ZlcmVkIHdpdGggZXhpc3RpbmcgdG9v bHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBlbmRpbmcgb24gdGhlIEdBUDxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthbmFseXNpcy4gQnV0IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFz IHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhhbiAxIHNvbHV0aW9uLDxicj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt3aGVyZSBhcyB0aGlzIGRvY3VtZW50IGNvdWxkIGp1c3QgZm9jdXMgb24gdXNl IGNhc2VzIG9ubHkuPGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJZiBpbmZhY3Qg dGhpcyBpcyBzdXBwb3NlZCB0byBiZSBhIHNvbHV0aW9uIGRvY3VtZW50LCB0aGVuIGNoYW5naW5n IHRoZSB0aXRsZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3b3VsZCBiZSBtb3JlIG1l YW5pbmdmdWwuIFRoYXQncyBteSBvYnNlcnZhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT5bUkddIFRoYW5rcy4gSXQn cyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAx LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBPSy4gdGhlbiBJJ2QgbGlrZSB0byBzZWUgYW55 IHNwZWNpZmljIHNvbHV0aW9uIGNvbnRlbnQgcmVtb3ZlZCwgdGhhdCB3YXkgd2UgZG9udCBoYXZl IHRvIGRpc2N1c3Mgd2hhdCBvdGhlciBzb2x1dGlvbnMgZG9lcyBlaXRoZXIgb3IgY29tcGFyZSB3 aXRoIDpEPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1DQT4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNBPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsy LiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29s dmVkIHdpdGg8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7ZHJhZnQtaWV0Zi1t cGxzLXByb3h5LWxzcC1waW5nLTAyJnF1b3Q7IC4gV2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaW4g dGhpczxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWN0aW9uIGNvdWxkIGJlIGRvbmUg d2l0aCB0aGUgcHJveHkgcGluZyhzb2x1dGlvbiB3aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZDxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBzZW50IHRvIG1vbml0b3IgTEVSIGkgYW5k IExFUiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3RhbmRpbmc8YnI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmlnaHQ/IElmIG5vdCwgaG93IGlzIGl0IGRpZmZlcmVudCBo ZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBsYW5nPUVOLUNBPltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNo IHN0YXkgaW4gZGF0YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQ8YnI+Jm5ic3A7ICZuYnNw OyAmbmJzcDtjaGFpbiBvZiBNUExTIExTUHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+JXNhbSAtIEV4 ZWN1dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVsc2U/Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+ PGJyPltSR10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbCBl eHRlbnNpb25zIHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG88YnI+Jm5ic3A7ICZuYnNwO2FsbG93 IGEgdGhpcmQgcGFydHkgdG8gcmVtb3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVz c2FnZSB0bzxicj4mbmJzcDsgJm5ic3A7YmUgc2VudCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4g TFNQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5z aW9ucywgJm5ic3A7aXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICZuYnNwO2FuZCBjYW5u b3QgY2xhaW0gdG8gYmUgdXNlIGNhc2UgZG9jdW1lbnQuIEFsc28gdGhpcyBkb2N1bWVudCBpcyBv biBpbmZvcm1hdGlvbiB0cmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVv dGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1DQT48YnI+W1JHXSBJIHRha2UgaXQgYXMgc2F5aW5nIHRoYXQgaWYg eW91J2QgbGlrZSB0byByZW1vdGVseSBleGVjdXRlIFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBvbiBh bnkgTFNQLCB5b3UgY291bGQgZWl0aGVyIHVzZSB0aGUgUE1TIG9yIHByb3h5LXBpbmcuIFRoZSBQ TVMgaG93ZXZlciBzaW1wbGlmaWVzIGFuZCBhZGRzPGJyPmZ1bmN0aW9uYWxpdHk6PGJyPmEpIFlv dSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBsaWtl IHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YTxicj4mbmJzcDsgJm5ic3A7cGxhbmUgbGl2ZWxpbmVz cywgUkZDNDM3OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxl bWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBSRkM0Mzc5IHBlcmZvcm1zIHZh bGlkYXRpb24gb2YgZGF0YXBsYW5lIGFuZCBhbHNvIGZpbmQgb3V0IGxvdCBtb3JlIGVycm9ycy4g WW91IG5lZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBwZXJmb3JtIHZhbGlkYXRpb24gY2hl Y2tzLiBGb3IgbGl2ZW5lc3MgZGV0ZWN0aW9uLCBCRkQgaXMgcHJlZmVycmVkIHRvb2wsIGF0bGVh c3QgaW4gcHJlc2VudCBkZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1TIHNvbHV0aW9u IGlzIGRlc2lnbmVkIGZvciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5vdCB0byBwZXJmb3JtIHZh bGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBldGM/IChJIHRoaW5rIHlv dSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxzbyk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5n PUVOLUNBPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBsYW5nPUVOLUNBPmIpIG9uY2UgUE1TIGRldGVjdGVkIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcyBh bmQgY29ycmVjdG5lc3Mgb2YgTVBMUyB0b3BvbG9neSBieSBSRkM0Mzc5LDxicj4mbmJzcDsgJm5i c3A7aXQgY2FuIGNvbnRpbnVlIHRvIGV4ZWN1dGUgYXJiaXRyYXJ5IExTUCBjb21iaW5hdGlvbnMg YW5kIHRoZSBtb25pdG9yaW5nIHBhY2tldHMgc3RheTxicj4mbmJzcDsgJm5ic3A7aW4gZGF0YSBw bGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0ZXh0IGluIHByb3h5LXBpbmcgb2ZmZXJpbmcg dGhpcyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBUaGlzIHlvdSBjb3VsZCBw ZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rpb24geW91IGFyZSBkZXNj cmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGluZyByYXRoZXIgdGhhbiB3aGF0IGxzcCBwaW5n IGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9uLW1wbHMgdG9wb2xvZ3kuPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g bGFuZz1FTi1DQT5UbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxh bmc9RU4tQ0E+LSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5 IGluZm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBsYW5nPUVOLUNBPi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVy ZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+ LSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2Ug VFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIgal0uPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT4tIGlmIHlvdSB3 YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIgaiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2Ug cHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1DQT48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDMuIFdoZW4gdGhlIHJlc3BvbnNlIGlzIHNlbnQgYmFjayB0byBQTVMgd2hpY2ggaXMgbm90 IHBhcnQgb2YgTVBMUyBvciBzZWdtZW50PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBk b21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1cml0eSBhc3BlY3QsIHdoaWNoIG5lZWRzIHRv IGNvbnNpZGVyZWQuIEkgYmVsaWV2ZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaXQg YXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91IGJlIGRvY3VtZW50aW5n IHRoYXQgYXNwZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBsYW5nPUVOLUNBPltSR10gVGhhdCdzIGEgdmFsaWQgcG9pbnQuIFRoZSBkb21h aW4gZXh0ZXJuYWwgc3lzdGVtIGlzIG9uZSBvcHRpb24gYW5kIHRoZSB0ZWFtIHdpbGwgZGVhbCB3 aXRoIHRoZSBzZWN1cml0eSBhc3BlY3RzIHJhaXNlZCBieSB0aGlzIG9wdGlvbiBvbmNlIHdlIGFy ZSBpbiBzb2x1dGlvbiBzcGFjZS4gV2Ugd2lsbCBub3QgYW5hbHlzZSB0aGlzIGluIGRlcHRoIGZv ciBhIHVzZSBjYXNlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBub2QmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNB Pjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1 bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRoIFJGQzQzNzkgcGluZzxicj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2l0aCBtdWx0cGF0aCArIHByb3h5IHBpbmcuIENv dWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmc8YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldyB0aGUgc29sdXRpb24gYnJpbmdzIGhlcmU/PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9 RU4tQ0E+W1JHXSBUaGUgU1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBwcm92aWRlZCB0ZXh0IGhvdyB0 byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBh IGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkgY291bGRuJ3QgZmluZCBleHBsaWNpdCB0ZXh0IG9u IGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gZHJhZnQtcHJveHkt bHNwLiBQbGVhc2UgZGVzY3JpYmUgaG93IHByb3h5LWxzcCBjYW4gYmUgdXNlZCB0byBtb25pdG9y IGEgYnVuZGxlZCBsaW5rIChzb3JyeSBpZiB0aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0 KS4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBPQU0gYXBwcm9hY2gsIHdlJ2xs IGRpc2N1c3MgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT4lc2FtIC0gVGhlIHNhbWUgc3RlcHMg ZGVzY3JpYmVkIGFib3ZlIGNvdWxkIGJlIHVzZWQgaWYgZWFjaCBidW5kbGVkIGxpbmsgbWVtYmVy IGlzIGlkZW50aWZpZWQgd2l0aCBhIHVuaXF1ZSBsYWJlbC4gV2hpbGUgcGVyZm9ybWluZyB0cmVl IHRyYWNlIG9yIHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRoIERE TUFQIGluZm8gZm9yIGVhY2ggb2YgdGhlIGxpbmtzIGFuZCB0aGUgbXVsdGlwYXRoIGluZm8gZm9y IHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+SWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIg aGFzIHNhbWUgbGFiZWwgc3RhY2ssIHRoZW4geW91IGNvdWxkIHVzZSBsc3Agc2VsZWN0b3JzIGFz IGRlZmluZWQgaW4gUkZDNDM3OSwgaW4gdGhpcyBjYXNlIGl0IGlzIGxvY2FsIGhvc3QgZGVzdCBp cCBhZGRyLCB0byBpZGVudGlmeSBlYWNoIGxpbmsgbWVtYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+Tm93IGlm IHRoZSBNUExTIGZvcndhcmRpbmcgbGF5ZXIgc2VlcyB0aGUgYnVuZGxlZCBsaW5rIGFzIG9uZSBp bnRlcmZhY2UgYnV0IGNhbm5vdCBkaXNjZXJuIGl0cyBsaW5rIG1lbWJlcnMsIHRoZW4geW91IGNv dWxkIG9ubHkgdmFsaWRhdGUgdGhlIGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRpdmlkdWFsIG1l bWJlcnMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1DQT5TYW1lIGFwcGxpZXMgaW4geW91ciBjYXNlIHRvby4gQ2Fubm90 IHNlZSBob3cgaXQgaXMgZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1DQT48YnI+PGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVu dCBoZXJlIG9ubHkgZm9yIFBNUyB0byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZTxicj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXNlIG9mIG1peGVkIGVudj88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFu Zz1FTi1DQT5bUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24g dG8gc2V0IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhlY3V0aW5nIGEgZGVzaXJlZCBj aGFpbiBvZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9kZSByZWxhdGlvbiBpcyBrbm93 biB0byB0aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUgb24g YnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPjwvYmxvY2tx dW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+JXNhbSAtIFNv LCB5b3UgYXJlIHNheWluZyB0aGF0IHlvdSBzdGlsbCBuZWVkIHRvIHBlcmZvcm0gUkZDNDM3OSB0 cmFjZSBvciB0cmVldHJhY2UgdG8gZ2V0IHRvcG9sb2d5LiBJIGRvIG5vdCB0aGluayBJR1AgZXh0 ZW5zaW9ucyBiZWluZyBwcm9wb3NlZCBpbiBTUFJJTkcgZXhwb3J0IGFueSBvZiB0aGUgaW5mbyBv dGhlciB0aGFuIGxhYmVsIHN0YWNrLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+QW5kIHRoZSBwcm9wb3Nl ZCBQTVMgc29sdXRpb24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwgaXQgcGVyZm9ybXMgb24gZGVt YW5kIHBlciBzZWdtZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28gZG9lcywgYWxiZWl0IG9ubHkg Zm9yIE1QTFMgdG9wb2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT5UaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBp cyB0aGF0IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9mIFJGQzQzNzkuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1F Ti1DQT4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPlF1ZXN0aW9uIEkgaGF2ZSBmb3IgeW91IGlzLCBpZiBk YXRhIHBsYW5lIHBhY2tldHMgYXJlIGdldHRpbmcgZHJvcHBlZCBhbmQgUE1TIHBhY2tldHMgZ29p bmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4gTFNQIG9yIFNlZ21lbnQsIGhvdyBkbyB5b3Uga25vdyB0 aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cgZG8geW91IGZpZ3VyZSBvdXQgd2hl cmUgaXQgaXM/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gbGFuZz1FTi1DQT5BdCBsZWFzdCB3aXRoIFJGQzQzNzkgYW5kL29yIHByb3h5 IHBpbmcsIHlvdSBjb3VsZCB2YWxpZGF0ZSBlYWNoIGhvcCBiZWNhdXNlIG9mIHRoZSBiZWxscyBh bmQgd2hpc3RsZXMgaXQgY2FycmllcyBhbG9uZyB3aXRoIHRoZSBwYWNrZXQuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1D QT4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBsYW5n PUVOLUNBPjxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzYuIEluIHNl YyAzLjEsPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c25pcCZndDs8 YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RldGVybWluaW5nIGEgcGF0aCB0 byBiZSBleGVjdXRlZCBwcmlvciB0byBhIG1lYXN1cmVtZW50IG1heSBhbHNvIGJlPGJyPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb25lIGJ5IHNldHRpbmcgdXAgYSBsYWJlbCBp bmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IHBhdGg8YnI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyhpZiBMRVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBs ZSBhbmQgaXQgc2hvdWxkIGJlIHBhc3NlZDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7YmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAtIDQw IC0gMzAgLSAxMCkuICZuYnNwO1RoZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7YWR2YW50YWdlIG9mIHRoaXMgbWV0aG9kIGlzLCB0aGF0IGl0IGRvZXMgbm90IGludm9sdmUg TVBMUyBPQU08YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Z1bmN0aW9uYWxp dHkgYW5kIGl0IGlzIGluZGVwZW5kZW50IG9mIEVDTVAgZnVuY3Rpb25hbGl0aWVzLiAmbmJzcDtU aGU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21ldGhvZCBzdGlsbCBpcyBh YmxlIHRvIG1vbml0b3IgYWxsIGxpbmsgY29tYmluYXRpb25zIG9mIGFsbCBwYXRocyBvZjxicj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW4gTVBMUyBkb21haW4uICZuYnNwO0lm IGNvcnJlY3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG88YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rp b25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNvIGluIHRoaXM8YnI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2UuPGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O2VuZCBzbmlwJmd0Ozxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0luIHRoZSBhYm92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMgbm90IGludm9s dmUgTVBMUyBPQU0uIEJ1dCBsYXRlciB5b3Ugc2F5LDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7UkZDNDM3OSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlIHVzZWQuIENvdWxkIHlv dSBjbGFyaWZ5IGhvdyBjb3VsZCB5b3UgdmVyaWZ5IGE8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3BhdGgsIGlmIE1QTFMgdmFsaWRhdGlvbiBpcyBub3QgZG9uZS4gTW9yZSB0 ZXh0IHdpbGwgaGVscC4gQWxzbywgbW9yZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW1wb3J0YW50bHksIHRoZSB0ZXh0IGVhcmxpZXIgdG8gdGhlIGFib3ZlIHNheXMsIGZv ciB2YWxpZCByZXN1bHQsIE1QTFM8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O09BTSBoYXMgdG8gYmUgcGVyZm9ybWVkIGZvciB0b3BvbG9neSBjaGFuZ2VzIGV0Yy4gSWYgc28s IGl0IGNvbnRyYWRpY3RzIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+W1JHXSBUaGUgdGV4dCBzaG91bGQgc2F5IHRo YXQ8YnI+LSB3aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVjdXRlcyBhIHNl dCBvZiBwYXRocyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24uPGJyPi0g aWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVz cG9uZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxp ZWQuPGJyPklmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUgdGV4dCBpbiB0 aGUgZHJhZnQgc3RhdGVzIHNvbWV0aGluZyBkaWZmZXJlbnQsIEknbGwgdHJ5IHRvIHJld29yZCBp dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gbGFuZz1FTi1DQT4lc2FtIC0gVGhlIHByb2JsZW0gSSBhbSBoYXZpbmcgaXMs IGluIHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlvdSBoYXZlIHRvIHZhbGlkYXRlIHRoZSBs c3AuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gbGFuZz1FTi1DQT5JIGRlZmluaXRlbHkgc2VlIGEgc3BlY2lmaWMgbmVlZCBmb3IgU1BS SU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1c2UgY2FzZSBpcyB0b28gbXVjaCBjYXRlcmVk IHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPk9uY2UgeW91 IHJlbW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNob3Vs ZCBiZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJl cXVpcmVtZW50cyBmb3IgYSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPkZvciBzb2x1dGlvbiBwYXJ0 LCBwbGVhc2UgcHVibGlzaCBhIHNlcGFyYXRlIElELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1DQT48YnI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzcuIExhc3QgYnV0IG5vdCB0aGUgbGVhc3Qs IGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFuZCBOTVM/PGJyPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtTb21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5j ZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQ8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO05NUy9FTVMgY291bGRuJ3QuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+W1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFu IEVNUy9OTVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9s b2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1Ag Y29tYmluYXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUg YmVlbiBjb21tZXJjaWFsbHkgYXZhaWxhYmxlLCB0aGUgY29tcGFueSBJIHdvcmsgZm9yIHdvdWxk bid0IGhhdmUgYmVlbiBkZXZlbG9waW5nIGEgUE1TLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Js b2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiVzYW0g LSBUaGVyZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hpY2ggcGVyZm9y bXMgTVBMUyB0b3BvbG9neSBzcGVjaWZpYyBvcGVyYXRpb25zICZuYnNwO2ZvciBhIGdpdmVuIHNl dCBvZiBMU1Ancy4gVGhleSBwZXJmb3JtIFRyZWV0cmFjZSBhbmQgcGVyZm9ybSBwaW5nIHdpdGgg bXVsdGlwYXRoLiBBbHNvIHBlcmZvcm0gTFNQIHNwZWNpZmljIHZhbGlkYXRpb24gYnkgY3JhZnRp bmcgcGFja2V0cyB3aXRoIGRhdGEgYXZhaWxhYmxlIHdpdGggdHJlZXRyYWNlIGFuZCBwaW5nIHdp dGggbXVsdGlwYXRoLiBZb3UgY291bGQgYXV0b21hdGUgdGhlIHdvcmtmbG93IHdpdGhvdXQgdGhl IG5lZWQgZm9yIE9TUy9QTVMsIGJ5IHVzaW5nIHByb2JlIHRlY2hub2xvZ3kuIFdpbGwgbm90IHNh eSBiZXlvbmQgdGhhdCA6RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tQ0E+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1DQT5jaGVlcnM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBsYW5nPUVOLUNBPi1zYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUNBPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQ0E+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 PjwvYm9keT48L2h0bWw+ --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8C84AAFHE111643EMEA1_-- From nobody Fri Jul 11 08:24:36 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3B51B2B51 for ; Fri, 11 Jul 2014 08:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZjpZBfsBZKZ for ; Fri, 11 Jul 2014 08:24:31 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7791E1A090D for ; Fri, 11 Jul 2014 08:24:31 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so1662604pab.3 for ; Fri, 11 Jul 2014 08:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TTGhHPTEWR9Io3UpKqy+b7+vYnUD+O5m4q16XF+xpmw=; b=EbEQ98yape0mmgMlrjjodHSgE1rwWYA6URUn0bd0Wd8yOnRpIjFjPAb00XTwDq3fDb LhYNlqsor6HY7kdHiMeUN849jbvjZm3K2HskfsqoMT2seGYkzChFcU8sBxK/fVbNZY/e A4JiCI2fnDSNkoG9lur5vrFBBXgPHV8S4NT/CFF3PCSAYvFAAR8amaQ/RVBpDieQx6zP NPysqUapEf+bh0iJEnTLR1f/R47TLtDTVtFIIR9lHmYjqddq0LGAzoEUXDbf8/6SQilC Cxk/n5Y8ZYKXnGRQLdBP43I5LwEmLwpFCaqiNJFtN+NV4Otv1dbW2kXAAbqGkV32bFEL D9fA== X-Received: by 10.69.26.68 with SMTP id iw4mr10484444pbd.137.1405092271113; Fri, 11 Jul 2014 08:24:31 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id jb5sm2603882pbd.73.2014.07.11.08.24.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 08:24:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6E89215-9F84-45DA-AE07-D41CE3C4C44F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Fri, 11 Jul 2014 08:24:29 -0700 Message-Id: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> References: To: Ruediger.Geib@telekom.de X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/nmgBH0CKUKcR9_iF_Yji2gYFQe8 Cc: nobo@cisco.com, draft-geib-spring-oam-usecase@tools.ietf.org, spring@ietf.org Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:24:34 -0000 --Apple-Mail=_F6E89215-9F84-45DA-AE07-D41CE3C4C44F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Rudiger, As I acknowledged in my earlier emails, the question is not about valid = use cases exist or not, rather it is about the document and what the = text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use = cases should not care what RFC4379 can or cannot, that discussion should = happen after the requirements which gets originated by these use cases. Once you cleanup the document and remove solution specific parts, it = should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then. cheers -sam On Jul 11, 2014, at 12:15 AM, = wrote: > Hi Nobo, hi Sam > =20 > the use case is to enable monitoring of an MPLS domain without = accessing the control plane. To do so, a PMS needs MPLS topology = awareness, which it gets by Segment Routing. The draft to some extent = explains how that is done, without going into too many details, I think. > =20 > Monitoring without control plane access is part of the use case, not = part of a solution discussion (to say it differently: using the data = plane for OAM purposes is not an option which may be removed). As many = SR based OAM features can be used without OAM specific protocols or = functions being added to Segment Routing, I think it=92s perfectly ok to = formulate the use case as is. The main requirement is: specify Segment = Routing. Then one may add OAM boxes which apply SR features. > =20 > RFC4379 could also monitor LSPs, but it requires using the control = plane and proxy-lsp-ping adds control plane based functionality to = RFC4379. It is an approach resulting in similar features, but it is = control plane based. This is a different use case. > =20 > If an operator needs to validate that a packet travels a certain path = or trace the path a lost packet has taken, then RFC4379 functionality is = needed. It=92s a difference whether RFC4379 is applied only at off peak = times or after a data plane only monitoring packet has been lost along = one path or whether that has to be done constantly. > =20 > Regards, > =20 > Ruediger > =20 > Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 > Gesendet: Donnerstag, 10. Juli 2014 21:46 > An: Sam Aldrin > Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase > Betreff: RE: [spring] Questions > =20 > Hi Sam, > =20 > I just wanted to point out the key described behavior, wasn=92t saying = anything about whether this document should be a use-case document or a = solution document J > =20 > Thanks! > =20 > -Nobo > =20 > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Thursday, July 10, 2014 3:10 PM > To: Nobo Akiya (nobo) > Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > =20 > Hi Nobo, > =20 > Inline for my comments. > =20 >=20 > On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = wrote: > Hi Sam, > =20 > Just to point out one thing about this document =85 > =20 > The test packet generated from a PMS/NMS/EMS/network-device can have = the complete segment stack on how to traverse the network as well as how = to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. > That is fine as a requirement/usecase and we should limit the scope to = that, than specifying how to solve it. > =20 > That makes this approach quite different from using proxy LSP ping. > You are talking about solution or use case? :D > =20 > =20 > This certainly has some pros and cons but can be quite useful as one = of the OAMs (yes plural) used to monitor the network. > Certainly. But I am struggling between use case and solution outlined = in the document. Pick one :D > =20 > -sam=20 > =20 > Thanks! > =20 > -Nobo > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 10, 2014 2:13 PM > To: Ruediger.Geib@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > =20 > Hi Ruediger, > =20 > Thanks for the quick response. Please find my responses inline. > =20 >=20 > On Thu, Jul 10, 2014 at 7:15 AM, wrote: > Hi Sam, >=20 > my replies are marked [RG] and added to your text. >=20 > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6) >=20 > Based on that, it=B9s a solution with broader scope and better fit for = SPRING as a whole.=20 > %sam - I believe you say it is use case document below. Then solution = is too premature at this point of time, as we haven't deliberated on the = requirements either.=20 >=20 > As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >=20 > Regards, >=20 > Ruediger >=20 >=20 > Sam Aldrin wrote: >=20 > I have few questions about this draft. >=20 > 1. The title is confusing to me. It says OAM use case but in = section #1 > it says the following >=20 > > This document describes a solution to this problem statement = and > illustrates it with use-cases. >=20 > The solution is described for a single IGP MPLS domain. >=20 > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > >=20 > In fact the draft is describing a solution to certain scenarios = and not just > providing use cases/scenarios. My understanding was, use case = draft should > document scenarios where it will drive new requirements. = Solutions could > be covered with existing toolset or defined newly, depending on = the GAP > analysis. But that should be separate as there could be more = than 1 solution, > where as this document could just focus on use cases only. >=20 > If infact this is supposed to be a solution document, then = changing the title > would be more meaningful. That's my observation. >=20 > [RG] Thanks. It's a use case document. We'll review the text of = section 1. > %sam - OK. then I'd like to see any specific solution content removed, = that way we dont have to discuss what other solutions does either or = compare with :D > =20 >=20 > 2. w.r.t. Section number #2, the same problem is being solved = with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described = in this > section could be done with the proxy ping(solution wise) where, = request could > be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding > right? If not, how is it different here? >=20 > [RG] The PMS is able to set up packets which stay in data plane and = execute a desired > chain of MPLS LSPs. > %sam - Execute you mean traverse? or perform something else?=20 >=20 > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message = to > be sent down a LSP or part of an LSP. > %sam - If it is proposing extensions, it has to be solution document = and cannot claim to be use case document. Also this document is on = information track. >=20 > [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like = proxy-ping to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation. > %sam - RFC4379 performs validation of dataplane and also find out lot = more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) > =20 > b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the = monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering = this feature. > %sam - This you could perform even without proxy ping. The function = you are describing is, how you use lsp ping rather than what lsp ping = does. Again I am not talking about non-mpls topology. > To answer your question, how you perform. > - Perform treetrace with rfc4379 to get topology info > - pick any arbitary LSP paths discovered along with its multipath = implementation. > - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. > - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >=20 > 3. When the response is sent back to PMS which is not part of = MPLS or segment > domain, there is a serious security aspect, which needs to = considered. I believe > it applies to sending a request too. Will you be documenting = that aspect? >=20 > [RG] That's a valid point. The domain external system is one option = and the team will deal with the security aspects raised by this option = once we are in solution space. We will not analyse this in depth for a = use case document. > %sam - nod=20 >=20 > 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if = there is something > new the solution brings here? >=20 > [RG] The SR OAM author team has provided text how to monitor a bundled = link in the use case draft. You are a co-author of proxy-lsp. I couldn't = find explicit text on how to detect and monitor a bundled link in = draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a = bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. > %sam - The same steps described above could be used if each bundled = link member is identified with a unique label. While performing tree = trace or ping with multipath, LER i will respond with DDMAP info for = each of the links and the multipath info for the same. > If you say that each link member has same label stack, then you could = use lsp selectors as defined in RFC4379, in this case it is local host = dest ip addr, to identify each link member. > Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. > Same applies in your case too. Cannot see how it is different. > =20 >=20 >=20 > 5. sec #5, Is the requirement here only for PMS to learn the = topology, in the > case of mixed env? >=20 > [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. > %sam - So, you are saying that you still need to perform RFC4379 trace = or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 > And the proposed PMS solution (not use case) is that, it performs on = demand per segment, which Proxy ping also does, albeit only for MPLS = topology. > The case you are making is that no need of bells and whistles of = RFC4379. > =20 > Question I have for you is, if data plane packets are getting dropped = and PMS packets going through, for a given LSP or Segment, how do you = know there is a problem? if you know, how do you figure out where it is? > At least with RFC4379 and/or proxy ping, you could validate each hop = because of the bells and whistles it carries along with the packet. > =20 >=20 >=20 > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may = also be > done by setting up a label including all node SIDs along that = path > (if LER1 has Node SID 40 in the example and it should be = passed > between LER i and LER j, the label stack is 20 - 40 - 30 - = 10). The > advantage of this method is, that it does not involve MPLS = OAM > functionality and it is independent of ECMP functionalities. = The > method still is able to monitor all link combinations of all = paths of > an MPLS domain. If correct forwarding along the desired = paths has to > be checked, RFC4739 functionality should be applied also in = this > case. >=20 > >=20 > In the above you mention that it does not involve MPLS OAM. = But later you say, > RFC4379 functionality could be used. Could you clarify how = could you verify a > path, if MPLS validation is not done. More text will help. = Also, more > importantly, the text earlier to the above says, for valid = result, MPLS > OAM has to be performed for topology changes etc. If so, it = contradicts here. >=20 > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. > - if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states = something different, I'll try to reword it. > %sam - The problem I am having is, in the case of MPLS, for OAM, you = have to validate the lsp. > I definitely see a specific need for SPRING, but what I feel is, the = use case is too much catered to a specific envisioned solution. > Once you remove solution or suggested enhancements, hope it should be = clear on what is being solved and scope out clear requirements for a = solution. > For solution part, please publish a separate ID. > =20 >=20 > 7. Last but not the least, how different is PMS from EMS and = NMS? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. >=20 > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and = uses this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. > %sam - There are tools which are part of NMS/OSS, which performs MPLS = topology specific operations for a given set of LSP's. They perform = Treetrace and perform ping with multipath. Also perform LSP specific = validation by crafting packets with data available with treetrace and = ping with multipath. You could automate the workflow without the need = for OSS/PMS, by using probe technology. Will not say beyond that :D > =20 > cheers > -sam --Apple-Mail=_F6E89215-9F84-45DA-AE07-D41CE3C4C44F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Rudiger,

As I acknowledged in my earlier emails, the = question is not about valid use cases exist or not, rather it is about = the document and what the text says. Document is not clear on just use = cases only because it touches various solution aspects, which is = unnecessary. For example, use cases should not care what RFC4379 can or = cannot, that discussion should happen after the requirements which gets = originated by these use cases.

Once you cleanup = the document and remove solution specific parts, it should be ok. We = could defer the discussion of what the existing solutions could and = could not do, for solution document and continue discussions of those = pieces, = then.

cheers
-sam

<= div>
On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> = <Ruediger.Geib@telekom.de> = wrote:

Hi Nobo, hi = Sam
 
the use case = is to enable monitoring of an MPLS domain without accessing the control = plane. To do so, a PMS needs MPLS topology awareness, which it gets by = Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I = think.
 
Monitoring = without control plane access is part of the use case, not part of a = solution discussion (to say it differently: using the data plane for OAM = purposes is not an option which may be removed). As many SR based OAM = features can be used without OAM specific protocols or functions being = added to Segment Routing, I think it=92s perfectly ok to formulate the = use case as is. The main requirement is: specify Segment Routing. Then = one may add OAM boxes which apply SR = features.
 
RFC4379 = could also monitor LSPs, but it requires using the control plane and = proxy-lsp-ping adds control plane based functionality to RFC4379. It is = an approach resulting in similar features, but it is control plane = based. This is a different use case.
 
If an operator needs to validate = that a packet travels a certain path or trace the path a lost packet has = taken, then RFC4379 functionality is needed. It=92s a difference whether = RFC4379 is applied only at off peak times or after a data plane only = monitoring packet has been lost along one path or whether that has to be = done constantly.
 
Regards,
 
Ruediger
 
Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerstag, 10. Juli 2014 = 21:46
An: Sam = Aldrin
Cc: Geib, R=FCdiger; spring; = draft-geib-spring-oam-usecase
Betreff: RE: [spring] = Questions
 
Hi = Sam,
 
I just = wanted to point out the key described behavior, wasn=92t saying anything = about whether this document should be a use-case document or a solution = document J
 
Thanks!
 
-Nobo
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, July 10, 2014 = 3:10 PM
To: Nobo Akiya = (nobo)
Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase
Subject: Re: [spring] = Questions
 
Hi Nobo,
 
Inline for my = comments.

 

On Thu, Jul 10, 2014 at 11:59 = AM, Nobo Akiya (nobo) <nobo@cisco.com> = wrote:
Hi Sam,
 
Just to point out one thing about = this document =85
 
The test = packet generated from a PMS/NMS/EMS/network-device can have the complete = segment stack on how to traverse the network as well as how to come back = to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
That is fine as a requirement/usecase and = we should limit the scope to that, than specifying how to solve = it.
 
That makes this approach quite = different from using proxy LSP ping.
You are talking about solution = or use case? :D
 
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
Certainly. But I am struggling = between use case and solution outlined in the document. Pick one = :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, July 10, 2014 = 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: [spring] = Questions
 
Hi = Ruediger,
 
Thanks for the quick response. = Please find my responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to = your text.

- Proxy-lsp-ping is MPLS only, while the PMS = architecture is intended for every SR data plane (MPLS + IPv6). We'll = clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC = 4379 / RFC 6424), while our use case can use any OAM (in particular, = specific good uses for BFD, and ICMPv6)

Based on that, it=B9s a = solution with broader scope and better fit for SPRING as a = whole. 
%sam - I believe you say it is use case document below. = Then solution is too premature at this point of time, as we haven't = deliberated on the requirements = either. 

As you = write, SR based OAM partially offers similar functions as proxy-lsp. = Without requiring the additional messages and LER/LSR processing = introduced by = proxy-lsp. 

Regards,

Ruediger


      Sam Aldrin = wrote:

      I have few questions about this = draft.

      1. The title is confusing to me. It = says OAM use case but in section #1
      it says the = following

      <snip>
    =    This document describes a solution to this problem = statement and
       illustrates it with = use-cases.

       The solution is described = for a single IGP MPLS domain.

       The = solution applies to monitoring of LDP LSP's as well as to
  =      monitoring of Segment Routed LSP's.
    =   <end snip>

       In fact the = draft is describing a solution to certain scenarios and not = just
       providing use cases/scenarios. My = understanding was, use case draft should
      =  document scenarios where it will drive new requirements. Solutions = could
       be covered with existing toolset or = defined newly, depending on the GAP
      =  analysis. But that should be separate as there could be more than = 1 solution,
       where as this document could = just focus on use cases only.

       If = infact this is supposed to be a solution document, then changing the = title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review the = text of section 1.
%sam - OK. then I'd like to see = any specific solution content removed, that way we dont have to discuss = what other solutions does either or compare with = :D
 


       2. w.r.t. Section number = #2, the same problem is being solved with
      =  "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in = this
       section could be done with the proxy = ping(solution wise) where, request could
      =  be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding
       right? If not, how is it = different here?

[RG] The PMS is able to set up packets which stay in data = plane and execute a desired
     chain of MPLS = LSPs.
%sam - Execute you mean traverse? or = perform something else? 

[RG] = Proxy-lsp says: This document defines protocol extensions to MPLS ping = [RFC4379] to
   allow a third party to remotely cause an = MPLS Echo Request message to
   be sent down a LSP or part = of an LSP.
%sam - If it is proposing extensions, =  it has to be solution document  and cannot claim to be use = case document. Also this document is on information = track.

[RG] I = take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't = need an additional protocol or functionality like proxy-ping to check = data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS = implementation.
%sam - RFC4379 performs = validation of dataplane and also find out lot more errors. You need = additional information to perform validation checks. For liveness = detection, BFD is preferred tool, atleast in present deployments.So are = you saying, PMS solution is designed for liveness detection and not to = perform validation of data plane to control plane, etc? (I think you = agree to this in the later part of the doc = also)
 
b) once PMS = detected data plane liveliness and correctness of MPLS topology by = RFC4379,
   it can continue to execute arbitrary LSP = combinations and the monitoring packets stay
   in data = plane. Please point me to the text in proxy-ping offering this = feature.
%sam - This you could perform even without = proxy ping. The function you are describing is, how you use lsp ping = rather than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with its = multipath implementation.
- perform ping with right = selectors for the path and use TTL for limiting the hop [LER = j].
- if you want to perform from LER i to LER j as in your = draft, use proxy ping to start from LER = i


        3. When the response is = sent back to PMS which is not part of MPLS or segment
    =     domain, there is a serious security aspect, which needs to = considered. I believe
        it applies to = sending a request too. Will you be documenting that = aspect?

[RG] That's a valid point. The domain external system is = one option and the team will deal with the security aspects raised by = this option once we are in solution space. We will not analyse this in = depth for a use case = document.
%sam - = nod 


        4. Sec 3.2 to monitor = bundle links, one could perform that with RFC4379 ping
    =     with multpath + proxy ping. Could you kindly differentiate = if there is something
        new the solution = brings here?

[RG] The SR OAM author team has provided text how to = monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be = used to monitor a bundled link (sorry if this is obvious and I missed = it). If there are differences to the SR OAM approach, we'll discuss = them.
%sam - The same steps described above could = be used if each bundled link member is identified with a unique label. = While performing tree trace or ping with multipath, LER i will respond = with DDMAP info for each of the links and the multipath info for the = same.
If you say that each link member has same label stack, = then you could use lsp selectors as defined in RFC4379, in this case it = is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled link as = one interface but cannot discern its link members, then you could only = validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is = the requirement here only for PMS to learn the topology, in = the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to set = up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring = packet.
%sam - So, you are saying that you still = need to perform RFC4379 trace or treetrace to get topology. I do not = think IGP extensions being proposed in SPRING export any of the info = other than label stack. 
And the proposed PMS solution = (not use case) is that, it performs on demand per segment, which Proxy = ping also does, albeit only for MPLS = topology.
The case you are making is that no need of = bells and whistles of RFC4379.
 
Question I have for you is, if = data plane packets are getting dropped and PMS packets going through, = for a given LSP or Segment, how do you know there is a problem? if you = know, how do you figure out where it = is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



         6. In sec = 3.1,
         <snip>
    =      Determining a path to be executed prior to a = measurement may also be
         done by = setting up a label including all node SIDs along that path
  =        (if LER1 has Node SID 40 in the example and = it should be passed
         between LER i = and LER j, the label stack is 20 - 40 - 30 - 10).  The
  =        advantage of this method is, that it does not = involve MPLS OAM
         functionality and = it is independent of ECMP functionalities.  The
    =      method still is able to monitor all link = combinations of all paths of
         an = MPLS domain.  If correct forwarding along the desired paths has = to
         be checked, RFC4739 = functionality should be applied also in this
      =    case.

         <end = snip>

         In the above you = mention that it does not involve MPLS OAM. But later you say,
  =        RFC4379 functionality could be used. Could = you clarify how could you verify a
        =  path, if MPLS validation is not done. More text will help. Also, = more
         importantly, the text earlier = to the above says, for valid result, MPLS
        =  OAM has to be performed for topology changes etc. If so, it = contradicts here.

[RG] The text should say that
- without = MPLS OAM functions, the PMS executes a set of paths only based on = control plane information.
- if the operator wants to make sure that = data plane corresponds to control plane, RFC4739 functions should be = applied.
If you understand this statement and the text in the draft = states something different, I'll try to reword = it.
%sam - The problem I am having is, in the = case of MPLS, for OAM, you have to validate the = lsp.
I definitely see a specific need for SPRING, but what I = feel is, the use case is too much catered to a specific envisioned = solution.
Once you remove solution or suggested = enhancements, hope it should be clear on what is being solved and scope = out clear requirements for a = solution.
For solution part, please publish a = separate ID.
 


         7. Last but not the = least, how different is PMS from EMS and NMS?
      =    Somehow I couldn't find the difference what PMS could do = and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't = have been developing a = PMS.
%sam - There are tools which are part of = NMS/OSS, which performs MPLS topology specific operations  for a = given set of LSP's. They perform Treetrace and perform ping with = multipath. Also perform LSP specific validation by crafting packets with = data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that = :D
 
cheers
-sam

= --Apple-Mail=_F6E89215-9F84-45DA-AE07-D41CE3C4C44F-- From nobody Fri Jul 11 08:50:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70F11A0A8A for ; Fri, 11 Jul 2014 08:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC7v1LWJKg3n for ; Fri, 11 Jul 2014 08:49:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 173E31A0659 for ; Fri, 11 Jul 2014 08:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64266; q=dns/txt; s=iport; t=1405093798; x=1406303398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iQuBR+ep6d+cgs/d0D3RJr0lZX+Dc2gxuwioomvunKw=; b=G1ddyadkOIk0iRgvADB9yPMqGR/++8U3X0f1TkyS/baZ6fju6shgQS/m x6Rt5xiu7dj8DISdpxIrlCTrLR9r2UkklJVPq2rlE8F2yDjik4pbyG2aJ gE6RsoZZNtfhHBrKegiDqv+uZ3N/FoFDgPFJrfyqSqe/+r4wjUqbQvZkd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FADoHwFOtJA2N/2dsb2JhbABPCoJHR1JawHEBCYZvUwGBCxZ1hAMBAQEEAQEBF00HBAcQAgEIEQEDAQEhAQYHIQYLFAMGCAIEDgUbiBMDEQ2/Gg2HGBeNHYFAEAUsKwYBAgQDgySBFgWZBYIAgUqMPIYWg0SBbwEHFwYc X-IronPort-AV: E=Sophos; i="5.01,644,1400025600"; d="scan'208,217"; a="60113685" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 11 Jul 2014 15:49:57 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6BFnqOK020044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 15:49:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 10:49:51 -0500 From: "Carlos Pignataro (cpignata)" To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J1ROB+bkF5Eyzu98s3ehKlwAT5ZsQAA/kkXAAExYZAAABnHcAAABc/AAAAUQagAAYD7EAABEWPIAAAOV7gA== Date: Fri, 11 Jul 2014 15:49:51 +0000 Message-ID: References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> In-Reply-To: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.101] Content-Type: multipart/alternative; boundary="_000_E0E170D7AB06480095F8A34C032F33C7ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ISrloYhSzZNi85cxCHZkd70aX5w Cc: "Ruediger.Geib@telekom.de" , "spring@ietf.org" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "Nobo Akiya \(nobo\)" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 15:50:00 -0000 --_000_E0E170D7AB06480095F8A34C032F33C7ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sam, Just to be clear: a use-case document is not a set of abstract generic requ= irements and nothing else. Use case is not requirements to then think of a = solution -- that would be a requirements document. This document describes the specific case of how to use a specific technolo= gy (spring) to solve a particular problem. The Abstract is pretty clear on = that: Abstract This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. [...] This scenario cannot be decoupled from its actual use case. I agree that additional text on showing how proxy-lsp-ping could support it= can potentially be useful, but not with "remove all solutions". Further, m= aybe the use case can be generalized even more. Thanks, Carlos. On Jul 11, 2014, at 11:24 AM, Sam Aldrin > wrote: Hi Rudiger, As I acknowledged in my earlier emails, the question is not about valid use= cases exist or not, rather it is about the document and what the text says= . Document is not clear on just use cases only because it touches various s= olution aspects, which is unnecessary. For example, use cases should not ca= re what RFC4379 can or cannot, that discussion should happen after the requ= irements which gets originated by these use cases. Once you cleanup the document and remove solution specific parts, it should= be ok. We could defer the discussion of what the existing solutions could = and could not do, for solution document and continue discussions of those p= ieces, then. cheers -sam On Jul 11, 2014, at 12:15 AM, > > = wrote: Hi Nobo, hi Sam the use case is to enable monitoring of an MPLS domain without accessing th= e control plane. To do so, a PMS needs MPLS topology awareness, which it ge= ts by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think. Monitoring without control plane access is part of the use case, not part o= f a solution discussion (to say it differently: using the data plane for OA= M purposes is not an option which may be removed). As many SR based OAM fea= tures can be used without OAM specific protocols or functions being added t= o Segment Routing, I think it=92s perfectly ok to formulate the use case as= is. The main requirement is: specify Segment Routing. Then one may add OAM= boxes which apply SR features. RFC4379 could also monitor LSPs, but it requires using the control plane an= d proxy-lsp-ping adds control plane based functionality to RFC4379. It is a= n approach resulting in similar features, but it is control plane based. Th= is is a different use case. If an operator needs to validate that a packet travels a certain path or tr= ace the path a lost packet has taken, then RFC4379 functionality is needed.= It=92s a difference whether RFC4379 is applied only at off peak times or a= fter a data plane only monitoring packet has been lost along one path or wh= ether that has to be done constantly. Regards, Ruediger Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Gesendet: Donnerstag, 10. Juli 2014 21:46 An: Sam Aldrin Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase Betreff: RE: [spring] Questions Hi Sam, I just wanted to point out the key described behavior, wasn=92t saying anyt= hing about whether this document should be a use-case document or a solutio= n document :) Thanks! -Nobo From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, July 10, 2014 3:10 PM To: Nobo Akiya (nobo) Cc: Ruediger.Geib@telekom.de; spring; draf= t-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Nobo, Inline for my comments. On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) > wrote: Hi Sam, Just to point out one thing about this document =85 The test packet generated from a PMS/NMS/EMS/network-device can have the co= mplete segment stack on how to traverse the network as well as how to come = back to self without any further signaling, OAM state maintenance on networ= k nodes nor OAM involvement by network nodes. That is fine as a requirement/usecase and we should limit the scope to that= , than specifying how to solve it. That makes this approach quite different from using proxy LSP ping. You are talking about solution or use case? :D This certainly has some pros and cons but can be quite useful as one of the= OAMs (yes plural) used to monitor the network. Certainly. But I am struggling between use case and solution outlined in th= e document. Pick one :D -sam Thanks! -Nobo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 10, 2014 2:13 PM To: Ruediger.Geib@telekom.de Cc: spring; draft-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, > wrote: Hi Sam, my replies are marked [RG] and added to your text. - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft. - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= ) Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. %sam - I believe you say it is use case document below. Then solution is to= o premature at this point of time, as we haven't deliberated on the require= ments either. As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. Regards, Ruediger Sam Aldrin wrote: I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section = #1 it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and = not just providing use cases/scenarios. My understanding was, use case draft = should document scenarios where it will drive new requirements. Solutions c= ould be covered with existing toolset or defined newly, depending on the = GAP analysis. But that should be separate as there could be more than 1 = solution, where as this document could just focus on use cases only. If infact this is supposed to be a solution document, then changing = the title would be more meaningful. That's my observation. [RG] Thanks. It's a use case document. We'll review the text of section 1. %sam - OK. then I'd like to see any specific solution content removed, that= way we dont have to discuss what other solutions does either or compare wi= th :D 2. w.r.t. Section number #2, the same problem is being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in thi= s section could be done with the proxy ping(solution wise) where, requ= est could be sent to monitor LER i and LER j segment, from a PMS. Is my unders= tanding right? If not, how is it different here? [RG] The PMS is able to set up packets which stay in data plane and execute= a desired chain of MPLS LSPs. %sam - Execute you mean traverse? or perform something else? [RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down a LSP or part of an LSP. %sam - If it is proposing extensions, it has to be solution document and = cannot claim to be use case document. Also this document is on information = track. [RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds functionality: a) You don't need an additional protocol or functionality like proxy-ping t= o check data plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS imple= mentation. %sam - RFC4379 performs validation of dataplane and also find out lot more = errors. You need additional information to perform validation checks. For l= iveness detection, BFD is preferred tool, atleast in present deployments.So= are you saying, PMS solution is designed for liveness detection and not to= perform validation of data plane to control plane, etc? (I think you agree= to this in the later part of the doc also) b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379, it can continue to execute arbitrary LSP combinations and the monitoring= packets stay in data plane. Please point me to the text in proxy-ping offering this f= eature. %sam - This you could perform even without proxy ping. The function you are= describing is, how you use lsp ping rather than what lsp ping does. Again = I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implement= ation. - perform ping with right selectors for the path and use TTL for limiting t= he hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy pi= ng to start from LER i 3. When the response is sent back to PMS which is not part of MPLS = or segment domain, there is a serious security aspect, which needs to consider= ed. I believe it applies to sending a request too. Will you be documenting that a= spect? [RG] That's a valid point. The domain external system is one option and the= team will deal with the security aspects raised by this option once we are= in solution space. We will not analyse this in depth for a use case docume= nt. %sam - nod 4. Sec 3.2 to monitor bundle links, one could perform that with RFC= 4379 ping with multpath + proxy ping. Could you kindly differentiate if there= is something new the solution brings here? [RG] The SR OAM author team has provided text how to monitor a bundled link= in the use case draft. You are a co-author of proxy-lsp. I couldn't find e= xplicit text on how to detect and monitor a bundled link in draft-proxy-lsp= . Please describe how proxy-lsp can be used to monitor a bundled link (sorr= y if this is obvious and I missed it). If there are differences to the SR O= AM approach, we'll discuss them. %sam - The same steps described above could be used if each bundled link me= mber is identified with a unique label. While performing tree trace or ping= with multipath, LER i will respond with DDMAP info for each of the links a= nd the multipath info for the same. If you say that each link member has same label stack, then you could use l= sp selectors as defined in RFC4379, in this case it is local host dest ip a= ddr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but= cannot discern its link members, then you could only validate the interfac= e and not its individual members. Same applies in your case too. Cannot see how it is different. 5. sec #5, Is the requirement here only for PMS to learn the topol= ogy, in the case of mixed env? [RG] MPLS topology awareness is the precondition to set up packets with lab= el stacks executing a desired chain of LSPs. If suitable Label/FEC/node rel= ation is known to the PMS, that LSP can be executed from that node on by a = PMS monitoring packet. %sam - So, you are saying that you still need to perform RFC4379 trace or t= reetrace to get topology. I do not think IGP extensions being proposed in S= PRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand= per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and P= MS packets going through, for a given LSP or Segment, how do you know there= is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop becaus= e of the bells and whistles it carries along with the packet. 6. In sec 3.1, Determining a path to be executed prior to a measurement may also = be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). T= he advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths= of an MPLS domain. If correct forwarding along the desired paths has= to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But la= ter you say, RFC4379 functionality could be used. Could you clarify how could y= ou verify a path, if MPLS validation is not done. More text will help. Also, m= ore importantly, the text earlier to the above says, for valid result,= MPLS OAM has to be performed for topology changes etc. If so, it contra= dicts here. [RG] The text should say that - without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information. - if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied. If you understand this statement and the text in the draft states something= different, I'll try to reword it. %sam - The problem I am having is, in the case of MPLS, for OAM, you have t= o validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use ca= se is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear= on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. 7. Last but not the least, how different is PMS from EMS and NMS? Somehow I couldn't find the difference what PMS could do and NMS/EMS couldn't. [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses t= his topology awareness to create data plane packets executing LSP combinati= ons as desired by an operator. Had this feature been commercially available= , the company I work for wouldn't have been developing a PMS. %sam - There are tools which are part of NMS/OSS, which performs MPLS topol= ogy specific operations for a given set of LSP's. They perform Treetrace a= nd perform ping with multipath. Also perform LSP specific validation by cra= fting packets with data available with treetrace and ping with multipath. Y= ou could automate the workflow without the need for OSS/PMS, by using probe= technology. Will not say beyond that :D cheers -sam _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_E0E170D7AB06480095F8A34C032F33C7ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Sam,

Just to be clear: a use-case document is not a set of abstract generic= requirements and nothing else. Use case is not requirements to then think = of a solution -- that would be a requirements document.

This document describes the specific case of how to use a specific tec= hnology (spring) to solve a particular problem. The Abstract is pretty clea= r on that:

Abstract

   This document describes features and a use case of a path= monitoring
   system.  Segment based routing enables a scalable an= d simple method
   to monitor data plane liveliness of the complete set of p= aths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.

I agree that additional text on showing how proxy-lsp-ping could suppo= rt it can potentially be useful, but not with "remove all solutions&qu= ot;. Further, maybe the use case can be generalized even more.

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about vali= d use cases exist or not, rather it is about the document and what the text= says. Document is not clear on just use cases only because it touches vari= ous solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that di= scussion should happen after the requirements which gets originated by thes= e use cases.

Once you cleanup the document and remove solution specific parts, it s= hould be ok. We could defer the discussion of what the existing solutions c= ould and could not do, for solution document and continue discussions of th= ose pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:

Hi Nobo, hi Sam
 
the use case is to enable monitoring of an = MPLS domain without accessing the control plane. To do so, a PMS needs MPLS= topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, witho= ut going into too many details, I think.
 
Monitoring without control plane access is = part of the use case, not part of a solution discussion (to say it differen= tly: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features can = be used without OAM specific protocols or functions being added to Segment = Routing, I think it=92s perfectly ok to formulate the use case as is. The m= ain requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR features.
 
RFC4379 could also monitor LSPs, but it req= uires using the control plane and proxy-lsp-ping adds control plane based f= unctionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a di= fferent use case.
 
If an operator needs to validate that a pac= ket travels a certain path or trace the path a lost packet has taken, then = RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after a = data plane only monitoring packet has been lost along one path or whether t= hat has to be done constantly.
 
Regards,
 
Ruediger
 
Von:=  Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerst= ag, 10. Juli 2014 21:46
An: Sam Aldrin
Cc: Geib, R=FCdige= r; spring; draft-geib-spring-oam-usecase
Betreff: RE: [spri= ng] Questions
 
Hi Sam,
 
I just wanted to point out the key describe= d behavior, wasn=92t saying anything about whether this document should be = a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: = Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, Ju= ly 10, 2014 3:10 PM
To: Nobo Akiya (no= bo)
Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase=
Subject: Re: [spri= ng] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) &l= t;nobo@cisco.com> wrote:
Hi Sam,
 
Just to point out one thing about this docu= ment =85
 
The test packet generated from a PMS/NMS/EM= S/network-device can have the complete segment stack on how to traverse the= network as well as how to come back to self without any further signaling, OAM state maintenance on network no= des nor OAM involvement by network nodes.<= /o:p>
That is fine as a requirement/usecase and we should li= mit the scope to that, than specifying how to solve it.
 
That makes this approach quite different fr= om using proxy LSP ping.
You are talking about solution or use case? :D
 
 
This certainly has some pros and cons but c= an be quite useful as one of the OAMs (yes plural) used to monitor the netw= ork.
Certainly. But I am struggling between use case and so= lution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: = spring [mailto:spring-bounces= @ietf.org] On Behalf Of Sam Aldrin=
Sent: Thursday, Ju= ly 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; draft-= geib-spring-oam-usecase
Subject: Re: [spri= ng] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my response= s inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. 
%sam - I believe you say it is use case document below= . Then solution is too premature at this point of time, as we haven't delib= erated on the requirements either. 

As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use case = but in section #1
      it says the following

      <snip>
       This document describes a solution to this probl= em statement and
       illustrates it with use-cases.

       The solution is described for a single IGP MPLS = domain.

       The solution applies to monitoring of LDP LSP's = as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to ce= rtain scenarios and not just
       providing use cases/scenarios. My understanding = was, use case draft should
       document scenarios where it will drive new requi= rements. Solutions could
       be covered with existing toolset or defined newl= y, depending on the GAP
       analysis. But that should be separate as there c= ould be more than 1 solution,
       where as this document could just focus on use c= ases only.

       If infact this is supposed to be a solution docu= ment, then changing the title
       would be more meaningful. That's my observation.=

[RG] Thanks. It's a use case document. We'll review th= e text of section 1.
%sam - OK. then I'd like to see any specific solution = content removed, that way we dont have to discuss what other solutions does= either or compare with :D
 


       2. w.r.t. Section number #2, the same problem is= being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
       section could be done with the proxy ping(soluti= on wise) where, request could
       be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
       right? If not, how is it different here?

[RG] The PMS is able to set up packets which stay in d= ata plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform something= else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request mes= sage to
   be sent down a LSP or part of an LSP.
%sam - If it is proposing extensions,  it has to = be solution document  and cannot claim to be use case document. Also t= his document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-ping t= o check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.
%sam - RFC4379 performs validation of dataplane and al= so find out lot more errors. You need additional information to perform val= idation checks. For liveness detection, BFD is preferred tool, atleast in p= resent deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validat= ion of data plane to control plane, etc? (I think you agree to this in the = later part of the doc also)
 
b) once PMS detected data plane liveliness and correct= ness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
   in data plane. Please point me to the text in proxy-ping offer= ing this feature.
%sam - This you could perform even without proxy ping.= The function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology.
To answer your question, how you perform.
- Perform treetrace with rfc4379 to get topology info<= o:p>
- pick any arbitary LSP paths discovered along with it= s multipath implementation.
- perform ping with right selectors for the path and u= se TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in you= r draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS which = is not part of MPLS or segment
        domain, there is a serious security aspect, whi= ch needs to considered. I believe
        it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external system = is one option and the team will deal with the security aspects raised by th= is option once we are in solution space. We will not analyse this in depth = for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
        with multpath + proxy ping. Could you kindl= y differentiate if there is something
        new the solution brings here?=

[RG] The SR OAM author team has provided text how to m= onitor a bundled link in the use case draft. You are a co-author of proxy-l= sp. I couldn't find explicit text on how to detect and monitor a bundled li= nk in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is obvi= ous and I missed it). If there are differences to the SR OAM approach, we'l= l discuss them.
%sam - The same steps described above could be used if= each bundled link member is identified with a unique label. While performi= ng tree trace or ping with multipath, LER i will respond with DDMAP info fo= r each of the links and the multipath info for the same.
If you say that each link member has same label stack,= then you could use lsp selectors as defined in RFC4379, in this case it is= local host dest ip addr, to identify each link member.
Now if the MPLS forwarding layer sees the bundled link= as one interface but cannot discern its link members, then you could only = validate the interface and not its individual members.
Same applies in your case too. Cannot see how it is di= fferent.
 



         5. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
            case of mixed env?

[RG] MPLS topology awareness is the precondition to se= t up packets with label stacks executing a desired chain of LSPs. If suitab= le Label/FEC/node relation is known to the PMS, that LSP can be executed fr= om that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to perfo= rm RFC4379 trace or treetrace to get topology. I do not think IGP extension= s being proposed in SPRING export any of the info other than label stack.&n= bsp;
And the proposed PMS solution (not use case) is that, = it performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology.
The case you are making is that no need of bells and w= histles of RFC4379.
 
Question I have for you is, if data plane packets are = getting dropped and PMS packets going through, for a given LSP or Segment, = how do you know there is a problem? if you know, how do you figure out wher= e it is?
At least with RFC4379 and/or proxy ping, you could val= idate each hop because of the bells and whistles it carries along with the = packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed prior t= o a measurement may also be
         done by setting up a label including all = node SIDs along that path
         (if LER1 has Node SID 40 in the example a= nd it should be passed
         between LER i and LER j, the label stack = is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it does= not involve MPLS OAM
         functionality and it is independent of EC= MP functionalities.  The
         method still is able to monitor all link = combinations of all paths of
         an MPLS domain.  If correct forwardi= ng along the desired paths has to
         be checked, RFC4739 functionality should = be applied also in this
         case.

         <end snip>

         In the above you mention that it does not= involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. Coul= d you clarify how could you verify a
         path, if MPLS validation is not done. Mor= e text will help. Also, more
         importantly, the text earlier to the abov= e says, for valid result, MPLS
         OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.
%sam - The problem I am having is, in the case of MPLS= , for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but what = I feel is, the use case is too much catered to a specific envisioned soluti= on.
Once you remove solution or suggested enhancements, ho= pe it should be clear on what is being solved and scope out clear requireme= nts for a solution.
For solution part, please publish a separate ID.<= /o:p>
 


         7. Last but not the least, how different = is PMS from EMS and NMS?
         Somehow I couldn't find the difference wh= at PMS could do and
         NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topo= logy aware and uses this topology awareness to create data plane packets ex= ecuting LSP combinations as desired by an operator. Had this feature been c= ommercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, whic= h performs MPLS topology specific operations  for a given set of LSP's= . They perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with treetrace and ping with multipath. You could auto= mate the workflow without the need for OSS/PMS, by using probe technology. = Will not say beyond that :D
 
cheers
-sam

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

--_000_E0E170D7AB06480095F8A34C032F33C7ciscocom_-- From nobody Fri Jul 11 09:07:53 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29B1B2B4D for ; Fri, 11 Jul 2014 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNG5c--qn0cv for ; Fri, 11 Jul 2014 09:07:45 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5271B2B76 for ; Fri, 11 Jul 2014 09:07:43 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id ft15so1618803pdb.35 for ; Fri, 11 Jul 2014 09:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J4nKMPUX6P4+piZDTwthL+X50u+2mYFdfe0+U4hVupg=; b=Y8ejDkfdcehucblBnBwLCrxM6UtwVmuC05Go9nX9vbjKRPo2om8tdEImfM2PSjnYiZ lkK9c/4uy5YR7lr99XtU7g8NJtSSprbjSjOKAaZTA8H8fcydBfOMaHKpbG/bLD8K2wRE PFqzYaotmoAuThED6sX/5261i8t1KAhGnyW84I5YHhl1A3fjsUYQlimz2Y3wsHzXO5C2 kggPbmJy/OS3S/oGYHYdPzuP5qfyNCLt3EF3jwCCBlYeaphcR+eh0jdkrteg+DlPxk9T xizqTDa5EbFCOFRTkYjJq3mqFVsNRuvqIJhNX4iAs5HbH6EFAGl7TYp8m0TMshc1pQOH /mKA== X-Received: by 10.66.158.36 with SMTP id wr4mr46114864pab.34.1405094862282; Fri, 11 Jul 2014 09:07:42 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id w7sm1929013pdo.90.2014.07.11.09.07.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 09:07:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A21E82AA-5F73-4CE4-953A-84E366164080" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Fri, 11 Jul 2014 09:07:40 -0700 Message-Id: <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/_ZvVGDt5q7_eYNVMy78sVe3VTKI Cc: "Ruediger.Geib@telekom.de" , "spring@ietf.org" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "Nobo Akiya \(nobo\)" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:07:49 -0000 --Apple-Mail=_A21E82AA-5F73-4CE4-953A-84E366164080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Carlos, On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) = wrote: > Sam, >=20 > Just to be clear: a use-case document is not a set of abstract generic = requirements and nothing else. Use case is not requirements to then = think of a solution -- that would be a requirements document. Neither did I ask for requirements only nor to be abstract, rather to = document to capture use cases, if that is what the authors intent for = this document is. >=20 > This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that: >=20 > Abstract >=20 > This document describes features and a use case of a path = monitoring > system. Segment based routing enables a scalable and simple method > to monitor data plane liveliness of the complete set of paths > belonging to a single domain. [...] >=20 > This scenario cannot be decoupled from its actual use case. Well then the introduction says the following The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. ... .. The proposed solution offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of a domains forwarding paths. >=20 > I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even more. Again, it is up to you authors what to retain in the document or what to = add. We could review accordingly. If there are solutions and proposals to existing solutions in this ID, = then it will lead into solutions discussions, which is what is happening = right now. cheers -sam >=20 > Thanks, >=20 > Carlos. >=20 > On Jul 11, 2014, at 11:24 AM, Sam Aldrin = wrote: >=20 >> Hi Rudiger, >>=20 >> As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use = cases should not care what RFC4379 can or cannot, that discussion should = happen after the requirements which gets originated by these use cases. >>=20 >> Once you cleanup the document and remove solution specific parts, it = should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then. >>=20 >> cheers >> -sam >>=20 >>=20 >> On Jul 11, 2014, at 12:15 AM, = wrote: >>=20 >>> Hi Nobo, hi Sam >>> =20 >>> the use case is to enable monitoring of an MPLS domain without = accessing the control plane. To do so, a PMS needs MPLS topology = awareness, which it gets by Segment Routing. The draft to some extent = explains how that is done, without going into too many details, I think. >>> =20 >>> Monitoring without control plane access is part of the use case, not = part of a solution discussion (to say it differently: using the data = plane for OAM purposes is not an option which may be removed). As many = SR based OAM features can be used without OAM specific protocols or = functions being added to Segment Routing, I think it=92s perfectly ok to = formulate the use case as is. The main requirement is: specify Segment = Routing. Then one may add OAM boxes which apply SR features. >>> =20 >>> RFC4379 could also monitor LSPs, but it requires using the control = plane and proxy-lsp-ping adds control plane based functionality to = RFC4379. It is an approach resulting in similar features, but it is = control plane based. This is a different use case. >>> =20 >>> If an operator needs to validate that a packet travels a certain = path or trace the path a lost packet has taken, then RFC4379 = functionality is needed. It=92s a difference whether RFC4379 is applied = only at off peak times or after a data plane only monitoring packet has = been lost along one path or whether that has to be done constantly. >>> =20 >>> Regards, >>> =20 >>> Ruediger >>> =20 >>> Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 >>> Gesendet: Donnerstag, 10. Juli 2014 21:46 >>> An: Sam Aldrin >>> Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase >>> Betreff: RE: [spring] Questions >>> =20 >>> Hi Sam, >>> =20 >>> I just wanted to point out the key described behavior, wasn=92t = saying anything about whether this document should be a use-case = document or a solution document J >>> =20 >>> Thanks! >>> =20 >>> -Nobo >>> =20 >>> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 >>> Sent: Thursday, July 10, 2014 3:10 PM >>> To: Nobo Akiya (nobo) >>> Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase >>> Subject: Re: [spring] Questions >>> =20 >>> Hi Nobo, >>> =20 >>> Inline for my comments. >>> =20 >>> On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = wrote: >>> Hi Sam, >>> =20 >>> Just to point out one thing about this document =85 >>> =20 >>> The test packet generated from a PMS/NMS/EMS/network-device can have = the complete segment stack on how to traverse the network as well as how = to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. >>> That is fine as a requirement/usecase and we should limit the scope = to that, than specifying how to solve it. >>> =20 >>> That makes this approach quite different from using proxy LSP ping. >>> You are talking about solution or use case? :D >>> =20 >>> =20 >>> This certainly has some pros and cons but can be quite useful as one = of the OAMs (yes plural) used to monitor the network. >>> Certainly. But I am struggling between use case and solution = outlined in the document. Pick one :D >>> =20 >>> -sam=20 >>> =20 >>> Thanks! >>> =20 >>> -Nobo >>> =20 >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin >>> Sent: Thursday, July 10, 2014 2:13 PM >>> To: Ruediger.Geib@telekom.de >>> Cc: spring; draft-geib-spring-oam-usecase >>> Subject: Re: [spring] Questions >>> =20 >>> Hi Ruediger, >>> =20 >>> Thanks for the quick response. Please find my responses inline. >>> =20 >>>=20 >>> On Thu, Jul 10, 2014 at 7:15 AM, wrote: >>> Hi Sam, >>>=20 >>> my replies are marked [RG] and added to your text. >>>=20 >>> - Proxy-lsp-ping is MPLS only, while the PMS architecture is = intended for every SR data plane (MPLS + IPv6). We'll clarify that in = the draft. >>> - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while = our use case can use any OAM (in particular, specific good uses for BFD, = and ICMPv6) >>>=20 >>> Based on that, it=B9s a solution with broader scope and better fit = for SPRING as a whole.=20 >>> %sam - I believe you say it is use case document below. Then = solution is too premature at this point of time, as we haven't = deliberated on the requirements either.=20 >>>=20 >>> As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >>>=20 >>> Regards, >>>=20 >>> Ruediger >>>=20 >>>=20 >>> Sam Aldrin wrote: >>>=20 >>> I have few questions about this draft. >>>=20 >>> 1. The title is confusing to me. It says OAM use case but in = section #1 >>> it says the following >>>=20 >>> >>> This document describes a solution to this problem statement = and >>> illustrates it with use-cases. >>>=20 >>> The solution is described for a single IGP MPLS domain. >>>=20 >>> The solution applies to monitoring of LDP LSP's as well as to >>> monitoring of Segment Routed LSP's. >>> >>>=20 >>> In fact the draft is describing a solution to certain = scenarios and not just >>> providing use cases/scenarios. My understanding was, use case = draft should >>> document scenarios where it will drive new requirements. = Solutions could >>> be covered with existing toolset or defined newly, depending = on the GAP >>> analysis. But that should be separate as there could be more = than 1 solution, >>> where as this document could just focus on use cases only. >>>=20 >>> If infact this is supposed to be a solution document, then = changing the title >>> would be more meaningful. That's my observation. >>>=20 >>> [RG] Thanks. It's a use case document. We'll review the text of = section 1. >>> %sam - OK. then I'd like to see any specific solution content = removed, that way we dont have to discuss what other solutions does = either or compare with :D >>> =20 >>>=20 >>> 2. w.r.t. Section number #2, the same problem is being solved = with >>> "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described = in this >>> section could be done with the proxy ping(solution wise) = where, request could >>> be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding >>> right? If not, how is it different here? >>>=20 >>> [RG] The PMS is able to set up packets which stay in data plane and = execute a desired >>> chain of MPLS LSPs. >>> %sam - Execute you mean traverse? or perform something else?=20 >>>=20 >>> [RG] Proxy-lsp says: This document defines protocol extensions to = MPLS ping [RFC4379] to >>> allow a third party to remotely cause an MPLS Echo Request = message to >>> be sent down a LSP or part of an LSP. >>> %sam - If it is proposing extensions, it has to be solution = document and cannot claim to be use case document. Also this document = is on information track. >>>=20 >>> [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds >>> functionality: >>> a) You don't need an additional protocol or functionality like = proxy-ping to check data >>> plane liveliness, RFC4379 is fine. Deutsche Telekom operates a = PMS implementation. >>> %sam - RFC4379 performs validation of dataplane and also find out = lot more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) >>> =20 >>> b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, >>> it can continue to execute arbitrary LSP combinations and the = monitoring packets stay >>> in data plane. Please point me to the text in proxy-ping offering = this feature. >>> %sam - This you could perform even without proxy ping. The function = you are describing is, how you use lsp ping rather than what lsp ping = does. Again I am not talking about non-mpls topology. >>> To answer your question, how you perform. >>> - Perform treetrace with rfc4379 to get topology info >>> - pick any arbitary LSP paths discovered along with its multipath = implementation. >>> - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. >>> - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >>>=20 >>> 3. When the response is sent back to PMS which is not part = of MPLS or segment >>> domain, there is a serious security aspect, which needs to = considered. I believe >>> it applies to sending a request too. Will you be documenting = that aspect? >>>=20 >>> [RG] That's a valid point. The domain external system is one option = and the team will deal with the security aspects raised by this option = once we are in solution space. We will not analyse this in depth for a = use case document. >>> %sam - nod=20 >>>=20 >>> 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping >>> with multpath + proxy ping. Could you kindly differentiate = if there is something >>> new the solution brings here? >>>=20 >>> [RG] The SR OAM author team has provided text how to monitor a = bundled link in the use case draft. You are a co-author of proxy-lsp. I = couldn't find explicit text on how to detect and monitor a bundled link = in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor = a bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. >>> %sam - The same steps described above could be used if each bundled = link member is identified with a unique label. While performing tree = trace or ping with multipath, LER i will respond with DDMAP info for = each of the links and the multipath info for the same. >>> If you say that each link member has same label stack, then you = could use lsp selectors as defined in RFC4379, in this case it is local = host dest ip addr, to identify each link member. >>> Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. >>> Same applies in your case too. Cannot see how it is different. >>> =20 >>>=20 >>>=20 >>> 5. sec #5, Is the requirement here only for PMS to learn = the topology, in the >>> case of mixed env? >>>=20 >>> [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. >>> %sam - So, you are saying that you still need to perform RFC4379 = trace or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 >>> And the proposed PMS solution (not use case) is that, it performs on = demand per segment, which Proxy ping also does, albeit only for MPLS = topology. >>> The case you are making is that no need of bells and whistles of = RFC4379. >>> =20 >>> Question I have for you is, if data plane packets are getting = dropped and PMS packets going through, for a given LSP or Segment, how = do you know there is a problem? if you know, how do you figure out where = it is? >>> At least with RFC4379 and/or proxy ping, you could validate each hop = because of the bells and whistles it carries along with the packet. >>> =20 >>>=20 >>>=20 >>> 6. In sec 3.1, >>> >>> Determining a path to be executed prior to a measurement = may also be >>> done by setting up a label including all node SIDs along = that path >>> (if LER1 has Node SID 40 in the example and it should be = passed >>> between LER i and LER j, the label stack is 20 - 40 - 30 - = 10). The >>> advantage of this method is, that it does not involve MPLS = OAM >>> functionality and it is independent of ECMP = functionalities. The >>> method still is able to monitor all link combinations of = all paths of >>> an MPLS domain. If correct forwarding along the desired = paths has to >>> be checked, RFC4739 functionality should be applied also in = this >>> case. >>>=20 >>> >>>=20 >>> In the above you mention that it does not involve MPLS OAM. = But later you say, >>> RFC4379 functionality could be used. Could you clarify how = could you verify a >>> path, if MPLS validation is not done. More text will help. = Also, more >>> importantly, the text earlier to the above says, for valid = result, MPLS >>> OAM has to be performed for topology changes etc. If so, it = contradicts here. >>>=20 >>> [RG] The text should say that >>> - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. >>> - if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied. >>> If you understand this statement and the text in the draft states = something different, I'll try to reword it. >>> %sam - The problem I am having is, in the case of MPLS, for OAM, you = have to validate the lsp. >>> I definitely see a specific need for SPRING, but what I feel is, the = use case is too much catered to a specific envisioned solution. >>> Once you remove solution or suggested enhancements, hope it should = be clear on what is being solved and scope out clear requirements for a = solution. >>> For solution part, please publish a separate ID. >>> =20 >>>=20 >>> 7. Last but not the least, how different is PMS from EMS = and NMS? >>> Somehow I couldn't find the difference what PMS could do = and >>> NMS/EMS couldn't. >>>=20 >>> [RG] I've never heard of an EMS/NMS which is MPLS topology aware and = uses this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. >>> %sam - There are tools which are part of NMS/OSS, which performs = MPLS topology specific operations for a given set of LSP's. They = perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with = treetrace and ping with multipath. You could automate the workflow = without the need for OSS/PMS, by using probe technology. Will not say = beyond that :D >>> =20 >>> cheers >>> -sam >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 --Apple-Mail=_A21E82AA-5F73-4CE4-953A-84E366164080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Carlos,

On Jul 11, 2014, at 8:49 = AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements = document.
Neither did I ask for requirements = only nor to be abstract, rather to document to capture use cases, if = that is what the authors intent for this document is.

This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that:

Abstract

   This document describes features and a use case of a = path monitoring
   system.  Segment based routing enables a scalable = and simple method
   to monitor data plane liveliness of the complete set = of paths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use = case.
Well then the introduction says the = following
<snip>
   The =
solution is described for a single IGP MPLS domain.


The =
solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed =
LSP's.
...
..
The proposed solution =
offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding =
paths.

<snip>










I agree that additional text on showing how proxy-lsp-ping could =
support it can potentially be useful, but not with "remove all =
solutions". Further, maybe the use case can be generalized even =
more.


Again, it is = up to you authors what to retain in the document or what to = add.
We could review accordingly.
If there are = solutions and proposals to existing solutions in this ID, then it will = lead into solutions discussions, which is what is happening right = now.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that = discussion should happen after the requirements which gets originated by = these use cases.

Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> = <Ruediger.Geib@telekom.de> = wrote:

Hi Nobo, hi = Sam
 
the use case is to enable = monitoring of an MPLS domain without accessing the control plane. To do = so, a PMS needs MPLS topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think.
 
Monitoring without control plane = access is part of the use case, not part of a solution discussion (to = say it differently: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features = can be used without OAM specific protocols or functions being added to = Segment Routing, I think it=92s perfectly ok to formulate the use case = as is. The main requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR = features.
 
RFC4379 could also monitor LSPs, = but it requires using the control plane and proxy-lsp-ping adds control = plane based functionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a = different use case.
 
If an operator needs to validate = that a packet travels a certain path or trace the path a lost packet has = taken, then RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after = a data plane only monitoring packet has been lost along one path or = whether that has to be done constantly.
 
Regards,
 
Ruediger
 
Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerstag, 10. Juli 2014 = 21:46
An: Sam = Aldrin
Cc: Geib, = R=FCdiger; spring; draft-geib-spring-oam-usecase
Betreff: RE: = [spring] Questions
 
Hi Sam,
 
I just wanted to point out the key = described behavior, wasn=92t saying anything about whether this document = should be a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, = July 10, 2014 3:10 PM
To: Nobo Akiya = (nobo)
Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:
Hi Sam,
 
Just to point out one thing about = this document =85
 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
That is fine as a requirement/usecase and we should = limit the scope to that, than specifying how to solve = it.
 
That makes this approach quite = different from using proxy LSP ping.
You are talking about solution or use case? = :D
 
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
Certainly. But I am struggling between use case and = solution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, = July 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the = draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=B9s a solution with broader scope and better fit for = SPRING as a whole. 
%sam - I believe you say it is use case document = below. Then solution is too premature at this point of time, as we = haven't deliberated on the requirements = either. 

As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use = case but in section #1
      it says the following

      <snip>
       This document describes a solution to this = problem statement and
       illustrates it with use-cases.

       The solution is described for a single IGP = MPLS domain.

       The solution applies to monitoring of LDP = LSP's as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to = certain scenarios and not just
       providing use cases/scenarios. My = understanding was, use case draft should
       document scenarios where it will drive new = requirements. Solutions could
       be covered with existing toolset or defined = newly, depending on the GAP
       analysis. But that should be separate as = there could be more than 1 solution,
       where as this document could just focus on = use cases only.

       If infact this is supposed to be a solution = document, then changing the title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review = the text of section 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with :D
 


       2. w.r.t. Section number #2, the same problem = is being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . What is = being described in this
       section could be done with the proxy = ping(solution wise) where, request could
       be sent to monitor LER i and LER j segment, = from a PMS. Is my understanding
       right? If not, how is it different = here?

[RG] The PMS is able to set up packets which stay = in data plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform = something else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request = message to
   be sent down a LSP or part of an = LSP.
%sam - If it is proposing extensions,  it has = to be solution document  and cannot claim to be use case document. = Also this document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like = proxy-ping to check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS implementation.
%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to = perform validation checks. For liveness detection, BFD is preferred = tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform = validation of data plane to control plane, etc? (I think you agree to = this in the later part of the doc also)
 
b) once PMS detected data plane liveliness and = correctness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and = the monitoring packets stay
   in data plane. Please point me to the text in proxy-ping = offering this feature.
%sam - This you could perform even without proxy = ping. The function you are describing is, how you use lsp ping rather = than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with = its multipath implementation.
- perform ping with right selectors for the path = and use TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in = your draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS = which is not part of MPLS or segment
        domain, there is a serious security aspect, = which needs to considered. I believe
        it applies to sending a request too. Will = you be documenting that aspect?

[RG] That's a valid point. The domain external = system is one option and the team will deal with the security aspects = raised by this option once we are in solution space. We will not analyse = this in depth for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one = could perform that with RFC4379 ping
        with multpath + proxy ping. Could you kindly = differentiate if there is something
        new the solution brings = here?

[RG] The SR OAM author team has provided text how = to monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is = obvious and I missed it). If there are differences to the SR OAM = approach, we'll discuss them.
%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the same.
If you say that each link member has same label = stack, then you could use lsp selectors as defined in RFC4379, in this = case it is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled = link as one interface but cannot discern its link members, then you = could only validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is the requirement here = only for PMS to learn the topology, in the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to = set up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to = perform RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is = that, it performs on demand per segment, which Proxy ping also does, = albeit only for MPLS topology.
The case you are making is that no need of bells = and whistles of RFC4379.
 
Question I have for you is, if data plane packets = are getting dropped and PMS packets going through, for a given LSP or = Segment, how do you know there is a problem? if you know, how do you = figure out where it is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed = prior to a measurement may also be
         done by setting up a label including = all node SIDs along that path
         (if LER1 has Node SID 40 in the = example and it should be passed
         between LER i and LER j, the label = stack is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it = does not involve MPLS OAM
         functionality and it is independent of = ECMP functionalities.  The
         method still is able to monitor all = link combinations of all paths of
         an MPLS domain.  If correct = forwarding along the desired paths has to
         be checked, RFC4739 functionality = should be applied also in this
         case.

         <end snip>

         In the above you mention that it does = not involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. = Could you clarify how could you verify a
         path, if MPLS validation is not done. = More text will help. Also, more
         importantly, the text earlier to the = above says, for valid result, MPLS
         OAM has to be performed for topology = changes etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based = on control plane information.
- if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states = something different, I'll try to reword it.
%sam - The problem I am having is, in the case of = MPLS, for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but = what I feel is, the use case is too much catered to a specific = envisioned solution.
Once you remove solution or suggested enhancements, = hope it should be clear on what is being solved and scope out clear = requirements for a solution.
For solution part, please publish a separate = ID.
 


         7. Last but not the least, how = different is PMS from EMS and NMS?
         Somehow I couldn't find the difference = what PMS could do and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, = which performs MPLS topology specific operations  for a given set = of LSP's. They perform Treetrace and perform ping with multipath. Also = perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that :D
 
cheers
-sam

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


= --Apple-Mail=_A21E82AA-5F73-4CE4-953A-84E366164080-- From nobody Fri Jul 11 09:29:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B865E1A0385 for ; Fri, 11 Jul 2014 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPXUkjHjhHGr for ; Fri, 11 Jul 2014 09:29:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1081A0A9E for ; Fri, 11 Jul 2014 09:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70255; q=dns/txt; s=iport; t=1405096161; x=1406305761; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iwJkkonTOFzg6S1bSwTmIi0mDEiV5SwJSqzLit7XQdc=; b=BeJk9IHWpFcaJroGj/7cKvN6Rd+eg1hzFtlRQpb+ZH7qE6Lv6QjYUZGe XOieHSVBL9GvP8JPCkwwBNAY/JJXJh/IWByyykhxvVNxM5ahCjncRSGvK hNGp3XlSa2Cmp2N0iGMMMzlZPM5KIObYVJLaA2UxbsqMjHpw0IcE5vygf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKsPwFOtJA2H/2dsb2JhbABPCoJHR1JahDG8QQEJhm9TAYELFnWEAwEBAQQBAQEXAUwHBAcQAgEIEQEDAQEhAQYHIQYLFAMGCAIEDgUbiBMDEQ2/Mw2HGBeNHYFAEAUsJwQGAQIEA4MkgRYFmQWCAIFKjDyGFoNEgW8BBxcGHA X-IronPort-AV: E=Sophos; i="5.01,644,1400025600"; d="scan'208,217"; a="60127746" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 11 Jul 2014 16:29:20 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6BGTJeZ021832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 16:29:20 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 11 Jul 2014 11:29:19 -0500 From: "Carlos Pignataro (cpignata)" To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J1ROB+bkF5Eyzu98s3ehKlwAT5ZsQAA/kkXAAExYZAAABnHcAAABc/AAAAUQagAAYD7EAABEWPIAAAOV7gAAAnJwAAADEQIA= Date: Fri, 11 Jul 2014 16:29:18 +0000 Message-ID: References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> In-Reply-To: <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.101] Content-Type: multipart/alternative; boundary="_000_E2179C9AFEF346EDB2722C9F72FA551Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/NQgFdTcJobYcF_kFaHHcya9CPGQ Cc: "Ruediger.Geib@telekom.de" , "spring@ietf.org" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "Nobo Akiya \(nobo\)" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 16:29:26 -0000 --_000_E2179C9AFEF346EDB2722C9F72FA551Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Sam, On Jul 11, 2014, at 12:07 PM, Sam Aldrin > wrote: Carlos, On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) > wrote: Sam, Just to be clear: a use-case document is not a set of abstract generic requ= irements and nothing else. Use case is not requirements to then think of a = solution -- that would be a requirements document. Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is. This document describes the specific case of how to use a specific technolo= gy (spring) to solve a particular problem. The Abstract is pretty clear on = that: Abstract This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. [...] This scenario cannot be decoupled from its actual use case. Well then the introduction says the following The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. ... .. The proposed solution offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of a domains forwarding paths. Thanks for pointing these out. I think you are cherry-picking and extrapola= ting the word "solution" way further than intended, and adding meaning to i= t as if it supports requirements. %s/The solution/The use case/ s/The proposed solution/The presented use case/ I agree that additional text on showing how proxy-lsp-ping could support it= can potentially be useful, but not with "remove all solutions". Further, m= aybe the use case can be generalized even more. Again, it is up to you authors what to retain in the document or what to ad= d. We could review accordingly. If there are solutions and proposals to existing solutions in this ID, then= it will lead into solutions discussions, which is what is happening right = now. What I think would be more useful would be to channel the review cycles tow= ards oam uses that get enabled by the spring architecture. That is, * is this a simple remote (proxy?) realization/use for oam in spring networ= ks? * can this use case be generalized to the spring ipv6 dataplane? [I think s= o] * can this use case be used with S-BFD? Thanks, Carlos. cheers -sam Thanks, Carlos. On Jul 11, 2014, at 11:24 AM, Sam Aldrin > wrote: Hi Rudiger, As I acknowledged in my earlier emails, the question is not about valid use= cases exist or not, rather it is about the document and what the text says= . Document is not clear on just use cases only because it touches various s= olution aspects, which is unnecessary. For example, use cases should not ca= re what RFC4379 can or cannot, that discussion should happen after the requ= irements which gets originated by these use cases. Once you cleanup the document and remove solution specific parts, it should= be ok. We could defer the discussion of what the existing solutions could = and could not do, for solution document and continue discussions of those p= ieces, then. cheers -sam On Jul 11, 2014, at 12:15 AM, > > = wrote: Hi Nobo, hi Sam the use case is to enable monitoring of an MPLS domain without accessing th= e control plane. To do so, a PMS needs MPLS topology awareness, which it ge= ts by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think. Monitoring without control plane access is part of the use case, not part o= f a solution discussion (to say it differently: using the data plane for OA= M purposes is not an option which may be removed). As many SR based OAM fea= tures can be used without OAM specific protocols or functions being added t= o Segment Routing, I think it=92s perfectly ok to formulate the use case as= is. The main requirement is: specify Segment Routing. Then one may add OAM= boxes which apply SR features. RFC4379 could also monitor LSPs, but it requires using the control plane an= d proxy-lsp-ping adds control plane based functionality to RFC4379. It is a= n approach resulting in similar features, but it is control plane based. Th= is is a different use case. If an operator needs to validate that a packet travels a certain path or tr= ace the path a lost packet has taken, then RFC4379 functionality is needed.= It=92s a difference whether RFC4379 is applied only at off peak times or a= fter a data plane only monitoring packet has been lost along one path or wh= ether that has to be done constantly. Regards, Ruediger Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Gesendet: Donnerstag, 10. Juli 2014 21:46 An: Sam Aldrin Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase Betreff: RE: [spring] Questions Hi Sam, I just wanted to point out the key described behavior, wasn=92t saying anyt= hing about whether this document should be a use-case document or a solutio= n document :) Thanks! -Nobo From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, July 10, 2014 3:10 PM To: Nobo Akiya (nobo) Cc: Ruediger.Geib@telekom.de; spring; draf= t-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Nobo, Inline for my comments. On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) > wrote: Hi Sam, Just to point out one thing about this document =85 The test packet generated from a PMS/NMS/EMS/network-device can have the co= mplete segment stack on how to traverse the network as well as how to come = back to self without any further signaling, OAM state maintenance on networ= k nodes nor OAM involvement by network nodes. That is fine as a requirement/usecase and we should limit the scope to that= , than specifying how to solve it. That makes this approach quite different from using proxy LSP ping. You are talking about solution or use case? :D This certainly has some pros and cons but can be quite useful as one of the= OAMs (yes plural) used to monitor the network. Certainly. But I am struggling between use case and solution outlined in th= e document. Pick one :D -sam Thanks! -Nobo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 10, 2014 2:13 PM To: Ruediger.Geib@telekom.de Cc: spring; draft-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, > wrote: Hi Sam, my replies are marked [RG] and added to your text. - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft. - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= ) Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. %sam - I believe you say it is use case document below. Then solution is to= o premature at this point of time, as we haven't deliberated on the require= ments either. As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. Regards, Ruediger Sam Aldrin wrote: I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section = #1 it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and = not just providing use cases/scenarios. My understanding was, use case draft = should document scenarios where it will drive new requirements. Solutions c= ould be covered with existing toolset or defined newly, depending on the = GAP analysis. But that should be separate as there could be more than 1 = solution, where as this document could just focus on use cases only. If infact this is supposed to be a solution document, then changing = the title would be more meaningful. That's my observation. [RG] Thanks. It's a use case document. We'll review the text of section 1. %sam - OK. then I'd like to see any specific solution content removed, that= way we dont have to discuss what other solutions does either or compare wi= th :D 2. w.r.t. Section number #2, the same problem is being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in thi= s section could be done with the proxy ping(solution wise) where, requ= est could be sent to monitor LER i and LER j segment, from a PMS. Is my unders= tanding right? If not, how is it different here? [RG] The PMS is able to set up packets which stay in data plane and execute= a desired chain of MPLS LSPs. %sam - Execute you mean traverse? or perform something else? [RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down a LSP or part of an LSP. %sam - If it is proposing extensions, it has to be solution document and = cannot claim to be use case document. Also this document is on information = track. [RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds functionality: a) You don't need an additional protocol or functionality like proxy-ping t= o check data plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS imple= mentation. %sam - RFC4379 performs validation of dataplane and also find out lot more = errors. You need additional information to perform validation checks. For l= iveness detection, BFD is preferred tool, atleast in present deployments.So= are you saying, PMS solution is designed for liveness detection and not to= perform validation of data plane to control plane, etc? (I think you agree= to this in the later part of the doc also) b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379, it can continue to execute arbitrary LSP combinations and the monitoring= packets stay in data plane. Please point me to the text in proxy-ping offering this f= eature. %sam - This you could perform even without proxy ping. The function you are= describing is, how you use lsp ping rather than what lsp ping does. Again = I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implement= ation. - perform ping with right selectors for the path and use TTL for limiting t= he hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy pi= ng to start from LER i 3. When the response is sent back to PMS which is not part of MPLS = or segment domain, there is a serious security aspect, which needs to consider= ed. I believe it applies to sending a request too. Will you be documenting that a= spect? [RG] That's a valid point. The domain external system is one option and the= team will deal with the security aspects raised by this option once we are= in solution space. We will not analyse this in depth for a use case docume= nt. %sam - nod 4. Sec 3.2 to monitor bundle links, one could perform that with RFC= 4379 ping with multpath + proxy ping. Could you kindly differentiate if there= is something new the solution brings here? [RG] The SR OAM author team has provided text how to monitor a bundled link= in the use case draft. You are a co-author of proxy-lsp. I couldn't find e= xplicit text on how to detect and monitor a bundled link in draft-proxy-lsp= . Please describe how proxy-lsp can be used to monitor a bundled link (sorr= y if this is obvious and I missed it). If there are differences to the SR O= AM approach, we'll discuss them. %sam - The same steps described above could be used if each bundled link me= mber is identified with a unique label. While performing tree trace or ping= with multipath, LER i will respond with DDMAP info for each of the links a= nd the multipath info for the same. If you say that each link member has same label stack, then you could use l= sp selectors as defined in RFC4379, in this case it is local host dest ip a= ddr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but= cannot discern its link members, then you could only validate the interfac= e and not its individual members. Same applies in your case too. Cannot see how it is different. 5. sec #5, Is the requirement here only for PMS to learn the topol= ogy, in the case of mixed env? [RG] MPLS topology awareness is the precondition to set up packets with lab= el stacks executing a desired chain of LSPs. If suitable Label/FEC/node rel= ation is known to the PMS, that LSP can be executed from that node on by a = PMS monitoring packet. %sam - So, you are saying that you still need to perform RFC4379 trace or t= reetrace to get topology. I do not think IGP extensions being proposed in S= PRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand= per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and P= MS packets going through, for a given LSP or Segment, how do you know there= is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop becaus= e of the bells and whistles it carries along with the packet. 6. In sec 3.1, Determining a path to be executed prior to a measurement may also = be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). T= he advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths= of an MPLS domain. If correct forwarding along the desired paths has= to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But la= ter you say, RFC4379 functionality could be used. Could you clarify how could y= ou verify a path, if MPLS validation is not done. More text will help. Also, m= ore importantly, the text earlier to the above says, for valid result,= MPLS OAM has to be performed for topology changes etc. If so, it contra= dicts here. [RG] The text should say that - without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information. - if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied. If you understand this statement and the text in the draft states something= different, I'll try to reword it. %sam - The problem I am having is, in the case of MPLS, for OAM, you have t= o validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use ca= se is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear= on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. 7. Last but not the least, how different is PMS from EMS and NMS? Somehow I couldn't find the difference what PMS could do and NMS/EMS couldn't. [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses t= his topology awareness to create data plane packets executing LSP combinati= ons as desired by an operator. Had this feature been commercially available= , the company I work for wouldn't have been developing a PMS. %sam - There are tools which are part of NMS/OSS, which performs MPLS topol= ogy specific operations for a given set of LSP's. They perform Treetrace a= nd perform ping with multipath. Also perform LSP specific validation by cra= fting packets with data available with treetrace and ping with multipath. Y= ou could automate the workflow without the need for OSS/PMS, by using probe= technology. Will not say beyond that :D cheers -sam _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_E2179C9AFEF346EDB2722C9F72FA551Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0257557B3D18914084C7A2877A31B6DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract generic= requirements and nothing else. Use case is not requirements to then think = of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is.

This document describes the specific case of how to use a specific tec= hnology (spring) to solve a particular problem. The Abstract is pretty clea= r on that:

Abstract

   This document describes features and a use case of a path= monitoring
   system.  Segment based routing enables a scalable an= d simple method
   to monitor data plane liveliness of the complete set of p= aths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS domain.


The solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed LSP's.
...
..
Th=
e proposed solution offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding paths.

<snip>



Thanks for pointing these out. I think you are cherry-picking and extr= apolating the word "solution" way further than intended, and addi= ng meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/



I agree that additional text on showing how proxy-lsp-ping could suppo= rt it can potentially be useful, but not with "remove all solutions&qu= ot;. Further, maybe the use case can be generalized even more.


Again, it is up to you authors what to retain in the document or what = to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this ID,= then it will lead into solutions discussions, which is what is happening r= ight now.


What I think would be more useful would be to channel the review cycle= s towards oam uses that get enabled by the spring architecture. That is,
* is this a simple remote (proxy?) realization/use for oam in spring n= etworks?
* can this use case be generalized to the spring ipv6 dataplane? [I th= ink so]
* can this use case be used with S-BFD?

Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about vali= d use cases exist or not, rather it is about the document and what the text= says. Document is not clear on just use cases only because it touches vari= ous solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that di= scussion should happen after the requirements which gets originated by thes= e use cases.

Once you cleanup the document and remove solution specific parts, it s= hould be ok. We could defer the discussion of what the existing solutions c= ould and could not do, for solution document and continue discussions of th= ose pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:

Hi Nobo, hi Sam
 
the use case is to enable monitoring of an = MPLS domain without accessing the control plane. To do so, a PMS needs MPLS= topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, witho= ut going into too many details, I think.
 
Monitoring without control plane access is = part of the use case, not part of a solution discussion (to say it differen= tly: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features can = be used without OAM specific protocols or functions being added to Segment = Routing, I think it=92s perfectly ok to formulate the use case as is. The m= ain requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR features.
 
RFC4379 could also monitor LSPs, but it req= uires using the control plane and proxy-lsp-ping adds control plane based f= unctionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a di= fferent use case.
 
If an operator needs to validate that a pac= ket travels a certain path or trace the path a lost packet has taken, then = RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after a = data plane only monitoring packet has been lost along one path or whether t= hat has to be done constantly.
 
Regards,
 
Ruediger
 
Von:=  Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerst= ag, 10. Juli 2014 21:46
An: Sam Aldrin
Cc: Geib, R=FCdige= r; spring; draft-geib-spring-oam-usecase
Betreff: RE: [spri= ng] Questions
 
Hi Sam,
 
I just wanted to point out the key describe= d behavior, wasn=92t saying anything about whether this document should be = a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: = Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, Ju= ly 10, 2014 3:10 PM
To: Nobo Akiya (no= bo)
Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase=
Subject: Re: [spri= ng] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) &l= t;nobo@cisco.com> wrote:
Hi Sam,
 
Just to point out one thing about this docu= ment =85
 
The test packet generated from a PMS/NMS/EM= S/network-device can have the complete segment stack on how to traverse the= network as well as how to come back to self without any further signaling, OAM state maintenance on network no= des nor OAM involvement by network nodes.<= /o:p>
That is fine as a requirement/usecase and we should li= mit the scope to that, than specifying how to solve it.
 
That makes this approach quite different fr= om using proxy LSP ping.
You are talking about solution or use case? :D
 
 
This certainly has some pros and cons but c= an be quite useful as one of the OAMs (yes plural) used to monitor the netw= ork.
Certainly. But I am struggling between use case and so= lution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: = spring [mailto:spring-bounces= @ietf.org] On Behalf Of Sam Aldrin=
Sent: Thursday, Ju= ly 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; draft-= geib-spring-oam-usecase
Subject: Re: [spri= ng] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my response= s inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. 
%sam - I believe you say it is use case document below= . Then solution is too premature at this point of time, as we haven't delib= erated on the requirements either. 

As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use case = but in section #1
      it says the following

      <snip>
       This document describes a solution to this probl= em statement and
       illustrates it with use-cases.

       The solution is described for a single IGP MPLS = domain.

       The solution applies to monitoring of LDP LSP's = as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to ce= rtain scenarios and not just
       providing use cases/scenarios. My understanding = was, use case draft should
       document scenarios where it will drive new requi= rements. Solutions could
       be covered with existing toolset or defined newl= y, depending on the GAP
       analysis. But that should be separate as there c= ould be more than 1 solution,
       where as this document could just focus on use c= ases only.

       If infact this is supposed to be a solution docu= ment, then changing the title
       would be more meaningful. That's my observation.=

[RG] Thanks. It's a use case document. We'll review th= e text of section 1.
%sam - OK. then I'd like to see any specific solution = content removed, that way we dont have to discuss what other solutions does= either or compare with :D
 


       2. w.r.t. Section number #2, the same problem is= being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
       section could be done with the proxy ping(soluti= on wise) where, request could
       be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
       right? If not, how is it different here?

[RG] The PMS is able to set up packets which stay in d= ata plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform something= else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request mes= sage to
   be sent down a LSP or part of an LSP.
%sam - If it is proposing extensions,  it has to = be solution document  and cannot claim to be use case document. Also t= his document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-ping t= o check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.
%sam - RFC4379 performs validation of dataplane and al= so find out lot more errors. You need additional information to perform val= idation checks. For liveness detection, BFD is preferred tool, atleast in p= resent deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validat= ion of data plane to control plane, etc? (I think you agree to this in the = later part of the doc also)
 
b) once PMS detected data plane liveliness and correct= ness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
   in data plane. Please point me to the text in proxy-ping offer= ing this feature.
%sam - This you could perform even without proxy ping.= The function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology.
To answer your question, how you perform.
- Perform treetrace with rfc4379 to get topology info<= o:p>
- pick any arbitary LSP paths discovered along with it= s multipath implementation.
- perform ping with right selectors for the path and u= se TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in you= r draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS which = is not part of MPLS or segment
        domain, there is a serious security aspect, whi= ch needs to considered. I believe
        it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external system = is one option and the team will deal with the security aspects raised by th= is option once we are in solution space. We will not analyse this in depth = for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
        with multpath + proxy ping. Could you kindl= y differentiate if there is something
        new the solution brings here?=

[RG] The SR OAM author team has provided text how to m= onitor a bundled link in the use case draft. You are a co-author of proxy-l= sp. I couldn't find explicit text on how to detect and monitor a bundled li= nk in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is obvi= ous and I missed it). If there are differences to the SR OAM approach, we'l= l discuss them.
%sam - The same steps described above could be used if= each bundled link member is identified with a unique label. While performi= ng tree trace or ping with multipath, LER i will respond with DDMAP info fo= r each of the links and the multipath info for the same.
If you say that each link member has same label stack,= then you could use lsp selectors as defined in RFC4379, in this case it is= local host dest ip addr, to identify each link member.
Now if the MPLS forwarding layer sees the bundled link= as one interface but cannot discern its link members, then you could only = validate the interface and not its individual members.
Same applies in your case too. Cannot see how it is di= fferent.
 



         5. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
            case of mixed env?

[RG] MPLS topology awareness is the precondition to se= t up packets with label stacks executing a desired chain of LSPs. If suitab= le Label/FEC/node relation is known to the PMS, that LSP can be executed fr= om that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to perfo= rm RFC4379 trace or treetrace to get topology. I do not think IGP extension= s being proposed in SPRING export any of the info other than label stack.&n= bsp;
And the proposed PMS solution (not use case) is that, = it performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology.
The case you are making is that no need of bells and w= histles of RFC4379.
 
Question I have for you is, if data plane packets are = getting dropped and PMS packets going through, for a given LSP or Segment, = how do you know there is a problem? if you know, how do you figure out wher= e it is?
At least with RFC4379 and/or proxy ping, you could val= idate each hop because of the bells and whistles it carries along with the = packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed prior t= o a measurement may also be
         done by setting up a label including all = node SIDs along that path
         (if LER1 has Node SID 40 in the example a= nd it should be passed
         between LER i and LER j, the label stack = is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it does= not involve MPLS OAM
         functionality and it is independent of EC= MP functionalities.  The
         method still is able to monitor all link = combinations of all paths of
         an MPLS domain.  If correct forwardi= ng along the desired paths has to
         be checked, RFC4739 functionality should = be applied also in this
         case.

         <end snip>

         In the above you mention that it does not= involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. Coul= d you clarify how could you verify a
         path, if MPLS validation is not done. Mor= e text will help. Also, more
         importantly, the text earlier to the abov= e says, for valid result, MPLS
         OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.
%sam - The problem I am having is, in the case of MPLS= , for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but what = I feel is, the use case is too much catered to a specific envisioned soluti= on.
Once you remove solution or suggested enhancements, ho= pe it should be clear on what is being solved and scope out clear requireme= nts for a solution.
For solution part, please publish a separate ID.<= /o:p>
 


         7. Last but not the least, how different = is PMS from EMS and NMS?
         Somehow I couldn't find the difference wh= at PMS could do and
         NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topo= logy aware and uses this topology awareness to create data plane packets ex= ecuting LSP combinations as desired by an operator. Had this feature been c= ommercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, whic= h performs MPLS topology specific operations  for a given set of LSP's= . They perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with treetrace and ping with multipath. You could auto= mate the workflow without the need for OSS/PMS, by using probe technology. = Will not say beyond that :D
 
cheers
-sam

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring



--_000_E2179C9AFEF346EDB2722C9F72FA551Cciscocom_-- From nobody Fri Jul 11 10:25:11 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8321A0AEE for ; Fri, 11 Jul 2014 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax-Fag8Na6-J for ; Fri, 11 Jul 2014 10:25:05 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9311A0AE6 for ; Fri, 11 Jul 2014 10:25:05 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lj1so1796481pab.8 for ; Fri, 11 Jul 2014 10:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GY3/T/UvRJ1ZCuXCxMiy/VSZD7zU+uj3G1JKzNNG87k=; b=WClDIrIEoTyalRrw0YcEmbKm1ffdR8tWvKl49fOcDalKjjpQWLHqGLu8NLmtLI3rcZ LQBrPtMA2x0wErDWBkc74yq7IIu23Bx6Rs8eiiAyRVPuS9/JBIGEqdcmLi9/1KUpqPaA Qx7+DSVRAX6mSj0Y3EkPQ9HZJC6wolKzX1C+uWt5BigJiCJAQyBcibU2QtSgd606ERf1 oFRCchCqbNMOwAR+kD338qVIsbFySrs2tIvRH/4gFkHY7/NbkDp2+xi/OCmF6y5L38F4 G67MaFVDqoOQIysmDrgAPJmAckUYGc8XhCY0UnwOV1IeHn4UPp6oEjAJs1d6RU4IpLa0 JFIA== X-Received: by 10.66.66.166 with SMTP id g6mr263624pat.108.1405099504696; Fri, 11 Jul 2014 10:25:04 -0700 (PDT) Received: from [192.168.1.2] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id uv5sm2859713pbc.52.2014.07.11.10.25.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jul 2014 10:25:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_35F9A115-F374-4F2A-9D67-DE4750DFEC02" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Fri, 11 Jul 2014 10:25:03 -0700 Message-Id: <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/atBPnycjJlMDMMF8YrzcjA-ZF2Q Cc: "Ruediger.Geib@telekom.de" , "spring@ietf.org" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "Nobo Akiya \(nobo\)" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 17:25:09 -0000 --Apple-Mail=_35F9A115-F374-4F2A-9D67-DE4750DFEC02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Carlos, On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) = wrote: > Hi, Sam, >=20 > On Jul 11, 2014, at 12:07 PM, Sam Aldrin = wrote: >=20 >> Carlos, >>=20 >> On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) = wrote: >>=20 >>> Sam, >>>=20 >>> Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document. >> Neither did I ask for requirements only nor to be abstract, rather to = document to capture use cases, if that is what the authors intent for = this document is. >>>=20 >>> This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that: >>>=20 >>> Abstract >>>=20 >>> This document describes features and a use case of a path = monitoring >>> system. Segment based routing enables a scalable and simple = method >>> to monitor data plane liveliness of the complete set of paths >>> belonging to a single domain. [...] >>>=20 >>> This scenario cannot be decoupled from its actual use case. >> Well then the introduction says the following >> >> The solution is described for a single IGP MPLS domain. >>=20 >> The solution applies to monitoring of LDP LSP's as well as to >> monitoring of Segment Routed LSP's. >> ... >> .. >> The proposed solution offers several benefits for network monitoring. >> A single centralized monitoring device is able to monitor the >> complete set of a domains forwarding paths. >>=20 >> >>=20 >>=20 >=20 > Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements. >=20 > %s/The solution/The use case/ > s/The proposed solution/The presented use case/ You are trivializing what I was eluding to in my earlier emails. If indeed you are not talking about solution, do you think sections 4-7 = talk about use cases? When I read the document the way it is worded and understood was to PMS = solution (sec #2) trying to solve problem in a specific. If you don't = believe, do "%s/PMS/NMS/g" and see. Don't misconstrue that I am saying there is no use case. >=20 >>=20 >>>=20 >>> I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even more. >>=20 >>=20 >> Again, it is up to you authors what to retain in the document or what = to add. >> We could review accordingly. >> If there are solutions and proposals to existing solutions in this = ID, then it will lead into solutions discussions, which is what is = happening right now. >>=20 >=20 > What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is, > * is this a simple remote (proxy?) realization/use for oam in spring = networks? > * can this use case be generalized to the spring ipv6 dataplane? [I = think so] > * can this use case be used with S-BFD? >=20 In addition, this document should add more details about the scenarios = of IPv6 w.r.t SR, or add specific pointers for the same. Also consider = the comments in my earlier emails. As far as S-BFD goes, refer to sec = 3.4 of S-BFD use case document. -sam > Thanks, >=20 > Carlos. >=20 >> cheers >> -sam >>>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>> On Jul 11, 2014, at 11:24 AM, Sam Aldrin = wrote: >>>=20 >>>> Hi Rudiger, >>>>=20 >>>> As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use = cases should not care what RFC4379 can or cannot, that discussion should = happen after the requirements which gets originated by these use cases. >>>>=20 >>>> Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then. >>>>=20 >>>> cheers >>>> -sam >>>>=20 >>>>=20 >>>> On Jul 11, 2014, at 12:15 AM, = wrote: >>>>=20 >>>>> Hi Nobo, hi Sam >>>>> =20 >>>>> the use case is to enable monitoring of an MPLS domain without = accessing the control plane. To do so, a PMS needs MPLS topology = awareness, which it gets by Segment Routing. The draft to some extent = explains how that is done, without going into too many details, I think. >>>>> =20 >>>>> Monitoring without control plane access is part of the use case, = not part of a solution discussion (to say it differently: using the data = plane for OAM purposes is not an option which may be removed). As many = SR based OAM features can be used without OAM specific protocols or = functions being added to Segment Routing, I think it=92s perfectly ok to = formulate the use case as is. The main requirement is: specify Segment = Routing. Then one may add OAM boxes which apply SR features. >>>>> =20 >>>>> RFC4379 could also monitor LSPs, but it requires using the control = plane and proxy-lsp-ping adds control plane based functionality to = RFC4379. It is an approach resulting in similar features, but it is = control plane based. This is a different use case. >>>>> =20 >>>>> If an operator needs to validate that a packet travels a certain = path or trace the path a lost packet has taken, then RFC4379 = functionality is needed. It=92s a difference whether RFC4379 is applied = only at off peak times or after a data plane only monitoring packet has = been lost along one path or whether that has to be done constantly. >>>>> =20 >>>>> Regards, >>>>> =20 >>>>> Ruediger >>>>> =20 >>>>> Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 >>>>> Gesendet: Donnerstag, 10. Juli 2014 21:46 >>>>> An: Sam Aldrin >>>>> Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase >>>>> Betreff: RE: [spring] Questions >>>>> =20 >>>>> Hi Sam, >>>>> =20 >>>>> I just wanted to point out the key described behavior, wasn=92t = saying anything about whether this document should be a use-case = document or a solution document J >>>>> =20 >>>>> Thanks! >>>>> =20 >>>>> -Nobo >>>>> =20 >>>>> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 >>>>> Sent: Thursday, July 10, 2014 3:10 PM >>>>> To: Nobo Akiya (nobo) >>>>> Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase >>>>> Subject: Re: [spring] Questions >>>>> =20 >>>>> Hi Nobo, >>>>> =20 >>>>> Inline for my comments. >>>>> =20 >>>>> On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = wrote: >>>>> Hi Sam, >>>>> =20 >>>>> Just to point out one thing about this document =85 >>>>> =20 >>>>> The test packet generated from a PMS/NMS/EMS/network-device can = have the complete segment stack on how to traverse the network as well = as how to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. >>>>> That is fine as a requirement/usecase and we should limit the = scope to that, than specifying how to solve it. >>>>> =20 >>>>> That makes this approach quite different from using proxy LSP = ping. >>>>> You are talking about solution or use case? :D >>>>> =20 >>>>> =20 >>>>> This certainly has some pros and cons but can be quite useful as = one of the OAMs (yes plural) used to monitor the network. >>>>> Certainly. But I am struggling between use case and solution = outlined in the document. Pick one :D >>>>> =20 >>>>> -sam=20 >>>>> =20 >>>>> Thanks! >>>>> =20 >>>>> -Nobo >>>>> =20 >>>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin >>>>> Sent: Thursday, July 10, 2014 2:13 PM >>>>> To: Ruediger.Geib@telekom.de >>>>> Cc: spring; draft-geib-spring-oam-usecase >>>>> Subject: Re: [spring] Questions >>>>> =20 >>>>> Hi Ruediger, >>>>> =20 >>>>> Thanks for the quick response. Please find my responses inline. >>>>> =20 >>>>>=20 >>>>> On Thu, Jul 10, 2014 at 7:15 AM, wrote: >>>>> Hi Sam, >>>>>=20 >>>>> my replies are marked [RG] and added to your text. >>>>>=20 >>>>> - Proxy-lsp-ping is MPLS only, while the PMS architecture is = intended for every SR data plane (MPLS + IPv6). We'll clarify that in = the draft. >>>>> - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while = our use case can use any OAM (in particular, specific good uses for BFD, = and ICMPv6) >>>>>=20 >>>>> Based on that, it=B9s a solution with broader scope and better fit = for SPRING as a whole.=20 >>>>> %sam - I believe you say it is use case document below. Then = solution is too premature at this point of time, as we haven't = deliberated on the requirements either.=20 >>>>>=20 >>>>> As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Ruediger >>>>>=20 >>>>>=20 >>>>> Sam Aldrin wrote: >>>>>=20 >>>>> I have few questions about this draft. >>>>>=20 >>>>> 1. The title is confusing to me. It says OAM use case but in = section #1 >>>>> it says the following >>>>>=20 >>>>> >>>>> This document describes a solution to this problem = statement and >>>>> illustrates it with use-cases. >>>>>=20 >>>>> The solution is described for a single IGP MPLS domain. >>>>>=20 >>>>> The solution applies to monitoring of LDP LSP's as well as = to >>>>> monitoring of Segment Routed LSP's. >>>>> >>>>>=20 >>>>> In fact the draft is describing a solution to certain = scenarios and not just >>>>> providing use cases/scenarios. My understanding was, use = case draft should >>>>> document scenarios where it will drive new requirements. = Solutions could >>>>> be covered with existing toolset or defined newly, = depending on the GAP >>>>> analysis. But that should be separate as there could be = more than 1 solution, >>>>> where as this document could just focus on use cases only. >>>>>=20 >>>>> If infact this is supposed to be a solution document, then = changing the title >>>>> would be more meaningful. That's my observation. >>>>>=20 >>>>> [RG] Thanks. It's a use case document. We'll review the text of = section 1. >>>>> %sam - OK. then I'd like to see any specific solution content = removed, that way we dont have to discuss what other solutions does = either or compare with :D >>>>> =20 >>>>>=20 >>>>> 2. w.r.t. Section number #2, the same problem is being = solved with >>>>> "draft-ietf-mpls-proxy-lsp-ping-02" . What is being = described in this >>>>> section could be done with the proxy ping(solution wise) = where, request could >>>>> be sent to monitor LER i and LER j segment, from a PMS. Is = my understanding >>>>> right? If not, how is it different here? >>>>>=20 >>>>> [RG] The PMS is able to set up packets which stay in data plane = and execute a desired >>>>> chain of MPLS LSPs. >>>>> %sam - Execute you mean traverse? or perform something else?=20 >>>>>=20 >>>>> [RG] Proxy-lsp says: This document defines protocol extensions to = MPLS ping [RFC4379] to >>>>> allow a third party to remotely cause an MPLS Echo Request = message to >>>>> be sent down a LSP or part of an LSP. >>>>> %sam - If it is proposing extensions, it has to be solution = document and cannot claim to be use case document. Also this document = is on information track. >>>>>=20 >>>>> [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds >>>>> functionality: >>>>> a) You don't need an additional protocol or functionality like = proxy-ping to check data >>>>> plane liveliness, RFC4379 is fine. Deutsche Telekom operates a = PMS implementation. >>>>> %sam - RFC4379 performs validation of dataplane and also find out = lot more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) >>>>> =20 >>>>> b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, >>>>> it can continue to execute arbitrary LSP combinations and the = monitoring packets stay >>>>> in data plane. Please point me to the text in proxy-ping = offering this feature. >>>>> %sam - This you could perform even without proxy ping. The = function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology. >>>>> To answer your question, how you perform. >>>>> - Perform treetrace with rfc4379 to get topology info >>>>> - pick any arbitary LSP paths discovered along with its multipath = implementation. >>>>> - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. >>>>> - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >>>>>=20 >>>>> 3. When the response is sent back to PMS which is not part = of MPLS or segment >>>>> domain, there is a serious security aspect, which needs to = considered. I believe >>>>> it applies to sending a request too. Will you be = documenting that aspect? >>>>>=20 >>>>> [RG] That's a valid point. The domain external system is one = option and the team will deal with the security aspects raised by this = option once we are in solution space. We will not analyse this in depth = for a use case document. >>>>> %sam - nod=20 >>>>>=20 >>>>> 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping >>>>> with multpath + proxy ping. Could you kindly differentiate = if there is something >>>>> new the solution brings here? >>>>>=20 >>>>> [RG] The SR OAM author team has provided text how to monitor a = bundled link in the use case draft. You are a co-author of proxy-lsp. I = couldn't find explicit text on how to detect and monitor a bundled link = in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor = a bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. >>>>> %sam - The same steps described above could be used if each = bundled link member is identified with a unique label. While performing = tree trace or ping with multipath, LER i will respond with DDMAP info = for each of the links and the multipath info for the same. >>>>> If you say that each link member has same label stack, then you = could use lsp selectors as defined in RFC4379, in this case it is local = host dest ip addr, to identify each link member. >>>>> Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. >>>>> Same applies in your case too. Cannot see how it is different. >>>>> =20 >>>>>=20 >>>>>=20 >>>>> 5. sec #5, Is the requirement here only for PMS to learn = the topology, in the >>>>> case of mixed env? >>>>>=20 >>>>> [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. >>>>> %sam - So, you are saying that you still need to perform RFC4379 = trace or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 >>>>> And the proposed PMS solution (not use case) is that, it performs = on demand per segment, which Proxy ping also does, albeit only for MPLS = topology. >>>>> The case you are making is that no need of bells and whistles of = RFC4379. >>>>> =20 >>>>> Question I have for you is, if data plane packets are getting = dropped and PMS packets going through, for a given LSP or Segment, how = do you know there is a problem? if you know, how do you figure out where = it is? >>>>> At least with RFC4379 and/or proxy ping, you could validate each = hop because of the bells and whistles it carries along with the packet. >>>>> =20 >>>>>=20 >>>>>=20 >>>>> 6. In sec 3.1, >>>>> >>>>> Determining a path to be executed prior to a measurement = may also be >>>>> done by setting up a label including all node SIDs along = that path >>>>> (if LER1 has Node SID 40 in the example and it should be = passed >>>>> between LER i and LER j, the label stack is 20 - 40 - 30 = - 10). The >>>>> advantage of this method is, that it does not involve = MPLS OAM >>>>> functionality and it is independent of ECMP = functionalities. The >>>>> method still is able to monitor all link combinations of = all paths of >>>>> an MPLS domain. If correct forwarding along the desired = paths has to >>>>> be checked, RFC4739 functionality should be applied also = in this >>>>> case. >>>>>=20 >>>>> >>>>>=20 >>>>> In the above you mention that it does not involve MPLS = OAM. But later you say, >>>>> RFC4379 functionality could be used. Could you clarify = how could you verify a >>>>> path, if MPLS validation is not done. More text will = help. Also, more >>>>> importantly, the text earlier to the above says, for = valid result, MPLS >>>>> OAM has to be performed for topology changes etc. If so, = it contradicts here. >>>>>=20 >>>>> [RG] The text should say that >>>>> - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. >>>>> - if the operator wants to make sure that data plane corresponds = to control plane, RFC4739 functions should be applied. >>>>> If you understand this statement and the text in the draft states = something different, I'll try to reword it. >>>>> %sam - The problem I am having is, in the case of MPLS, for OAM, = you have to validate the lsp. >>>>> I definitely see a specific need for SPRING, but what I feel is, = the use case is too much catered to a specific envisioned solution. >>>>> Once you remove solution or suggested enhancements, hope it should = be clear on what is being solved and scope out clear requirements for a = solution. >>>>> For solution part, please publish a separate ID. >>>>> =20 >>>>>=20 >>>>> 7. Last but not the least, how different is PMS from EMS = and NMS? >>>>> Somehow I couldn't find the difference what PMS could do = and >>>>> NMS/EMS couldn't. >>>>>=20 >>>>> [RG] I've never heard of an EMS/NMS which is MPLS topology aware = and uses this topology awareness to create data plane packets executing = LSP combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. >>>>> %sam - There are tools which are part of NMS/OSS, which performs = MPLS topology specific operations for a given set of LSP's. They = perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with = treetrace and ping with multipath. You could automate the workflow = without the need for OSS/PMS, by using probe technology. Will not say = beyond that :D >>>>> =20 >>>>> cheers >>>>> -sam >>>>=20 >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>=20 >>=20 >=20 --Apple-Mail=_35F9A115-F374-4F2A-9D67-DE4750DFEC02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos = Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to = document to capture use cases, if that is what the authors intent for = this document is.

This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that:

Abstract

   This document describes features and a use case of a = path monitoring
   system.  Segment based routing enables a scalable = and simple method
   to monitor data plane liveliness of the complete set = of paths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS =
domain.


The solution applies to monitoring of LDP LSP's as =
well as to
   monitoring of Segment Routed =
LSP's.
...
..
The proposed solution =
offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding =
paths.

<snip>

Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use = case/

You are = trivializing what I was eluding to in my earlier emails.
If = indeed you are not talking about solution, do you think sections 4-7 = talk about use cases?
When I read the document the way it is = worded and understood was to PMS solution (sec #2) trying to solve = problem in a specific. If you don't believe, do "%s/PMS/NMS/g" and = see.

Don't misconstrue that I am saying there = is no use case.





I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even = more.


Again, it is up to you authors what to retain in the document or = what to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this = ID, then it will lead into solutions discussions, which is what is = happening right now.


What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is,
* is this a simple remote (proxy?) realization/use for oam in = spring networks?
* can this use case be generalized to the spring ipv6 dataplane? [I = think so]
* can this use case be used with S-BFD?

In addition, this document = should add more details about the scenarios of IPv6 w.r.t SR, or add = specific pointers for the same. Also consider the comments in my earlier = emails. As far as S-BFD goes, refer to sec 3.4 of S-BFD use case = document.

-sam


Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that = discussion should happen after the requirements which gets originated by = these use cases.

Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> = <Ruediger.Geib@telekom.de> = wrote:

Hi Nobo, hi = Sam
 
the use case is to enable = monitoring of an MPLS domain without accessing the control plane. To do = so, a PMS needs MPLS topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think.
 
Monitoring without control plane = access is part of the use case, not part of a solution discussion (to = say it differently: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features = can be used without OAM specific protocols or functions being added to = Segment Routing, I think it=92s perfectly ok to formulate the use case = as is. The main requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR = features.
 
RFC4379 could also monitor LSPs, = but it requires using the control plane and proxy-lsp-ping adds control = plane based functionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a = different use case.
 
If an operator needs to validate = that a packet travels a certain path or trace the path a lost packet has = taken, then RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after = a data plane only monitoring packet has been lost along one path or = whether that has to be done constantly.
 
Regards,
 
Ruediger
 
Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerstag, 10. Juli 2014 = 21:46
An: Sam = Aldrin
Cc: Geib, = R=FCdiger; spring; draft-geib-spring-oam-usecase
Betreff: RE: = [spring] Questions
 
Hi Sam,
 
I just wanted to point out the key = described behavior, wasn=92t saying anything about whether this document = should be a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, = July 10, 2014 3:10 PM
To: Nobo Akiya = (nobo)
Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:
Hi Sam,
 
Just to point out one thing about = this document =85
 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
That is fine as a requirement/usecase and we should = limit the scope to that, than specifying how to solve = it.
 
That makes this approach quite = different from using proxy LSP ping.
You are talking about solution or use case? = :D
 
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
Certainly. But I am struggling between use case and = solution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, = July 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the = draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=B9s a solution with broader scope and better fit for = SPRING as a whole. 
%sam - I believe you say it is use case document = below. Then solution is too premature at this point of time, as we = haven't deliberated on the requirements = either. 

As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use = case but in section #1
      it says the following

      <snip>
       This document describes a solution to this = problem statement and
       illustrates it with use-cases.

       The solution is described for a single IGP = MPLS domain.

       The solution applies to monitoring of LDP = LSP's as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to = certain scenarios and not just
       providing use cases/scenarios. My = understanding was, use case draft should
       document scenarios where it will drive new = requirements. Solutions could
       be covered with existing toolset or defined = newly, depending on the GAP
       analysis. But that should be separate as = there could be more than 1 solution,
       where as this document could just focus on = use cases only.

       If infact this is supposed to be a solution = document, then changing the title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review = the text of section 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with :D
 


       2. w.r.t. Section number #2, the same problem = is being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . What is = being described in this
       section could be done with the proxy = ping(solution wise) where, request could
       be sent to monitor LER i and LER j segment, = from a PMS. Is my understanding
       right? If not, how is it different = here?

[RG] The PMS is able to set up packets which stay = in data plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform = something else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request = message to
   be sent down a LSP or part of an = LSP.
%sam - If it is proposing extensions,  it has = to be solution document  and cannot claim to be use case document. = Also this document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like = proxy-ping to check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS implementation.
%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to = perform validation checks. For liveness detection, BFD is preferred = tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform = validation of data plane to control plane, etc? (I think you agree to = this in the later part of the doc also)
 
b) once PMS detected data plane liveliness and = correctness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and = the monitoring packets stay
   in data plane. Please point me to the text in proxy-ping = offering this feature.
%sam - This you could perform even without proxy = ping. The function you are describing is, how you use lsp ping rather = than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with = its multipath implementation.
- perform ping with right selectors for the path = and use TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in = your draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS = which is not part of MPLS or segment
        domain, there is a serious security aspect, = which needs to considered. I believe
        it applies to sending a request too. Will = you be documenting that aspect?

[RG] That's a valid point. The domain external = system is one option and the team will deal with the security aspects = raised by this option once we are in solution space. We will not analyse = this in depth for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one = could perform that with RFC4379 ping
        with multpath + proxy ping. Could you kindly = differentiate if there is something
        new the solution brings = here?

[RG] The SR OAM author team has provided text how = to monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is = obvious and I missed it). If there are differences to the SR OAM = approach, we'll discuss them.
%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the same.
If you say that each link member has same label = stack, then you could use lsp selectors as defined in RFC4379, in this = case it is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled = link as one interface but cannot discern its link members, then you = could only validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is the requirement here = only for PMS to learn the topology, in the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to = set up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to = perform RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is = that, it performs on demand per segment, which Proxy ping also does, = albeit only for MPLS topology.
The case you are making is that no need of bells = and whistles of RFC4379.
 
Question I have for you is, if data plane packets = are getting dropped and PMS packets going through, for a given LSP or = Segment, how do you know there is a problem? if you know, how do you = figure out where it is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed = prior to a measurement may also be
         done by setting up a label including = all node SIDs along that path
         (if LER1 has Node SID 40 in the = example and it should be passed
         between LER i and LER j, the label = stack is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it = does not involve MPLS OAM
         functionality and it is independent of = ECMP functionalities.  The
         method still is able to monitor all = link combinations of all paths of
         an MPLS domain.  If correct = forwarding along the desired paths has to
         be checked, RFC4739 functionality = should be applied also in this
         case.

         <end snip>

         In the above you mention that it does = not involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. = Could you clarify how could you verify a
         path, if MPLS validation is not done. = More text will help. Also, more
         importantly, the text earlier to the = above says, for valid result, MPLS
         OAM has to be performed for topology = changes etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based = on control plane information.
- if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states = something different, I'll try to reword it.
%sam - The problem I am having is, in the case of = MPLS, for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but = what I feel is, the use case is too much catered to a specific = envisioned solution.
Once you remove solution or suggested enhancements, = hope it should be clear on what is being solved and scope out clear = requirements for a solution.
For solution part, please publish a separate = ID.
 


         7. Last but not the least, how = different is PMS from EMS and NMS?
         Somehow I couldn't find the difference = what PMS could do and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, = which performs MPLS topology specific operations  for a given set = of LSP's. They perform Treetrace and perform ping with multipath. Also = perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that :D
 
cheers
-sam

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




= --Apple-Mail=_35F9A115-F374-4F2A-9D67-DE4750DFEC02-- From nobody Sun Jul 13 00:59:41 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE251B29ED for ; Sun, 13 Jul 2014 00:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTtQefIQh0Q0 for ; Sun, 13 Jul 2014 00:59:34 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461591B29BC for ; Sun, 13 Jul 2014 00:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76715; q=dns/txt; s=iport; t=1405238374; x=1406447974; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ou8PD6AOS3/B/eEM4b+mv2+3j95QJSl8gRKixeLSspk=; b=Kpp1P0RA/mt9x/j2/F1+t2ww5ATLwpmo1+/WkmFuimdjSRkZSoLvhnoD Ctb5PjivnZxKiCP1L96c0OU5kW3D6MY7fYG0Tb5iy3I7ox/dLHIsbIro1 xhbsa0zTKkCQG/8wvnpp7nV5vdgwBnN/0qvQsxxH5RsY0blG//ru1vOwP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJk7wlOtJA2K/2dsb2JhbABPCoJHR1JahDG9BgEJhnBTAYEMFnWEAwEBAQQBAQEXAUwHBAcQAgEIEQEDAQEhAQYHIQYLFAMGCAIEDgUbiBMDEQ2/Kg2HKBeNHoFBEAUsJwQGAQIEA4MkgRYFmQ6CAIFKjD2GFoNEgW8BBxcGHA X-IronPort-AV: E=Sophos; i="5.01,652,1400025600"; d="scan'208,217"; a="60419326" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 13 Jul 2014 07:59:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6D7xWJX022644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Jul 2014 07:59:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Sun, 13 Jul 2014 02:59:32 -0500 From: "Carlos Pignataro (cpignata)" To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J1ROB+bkF5Eyzu98s3ehKlwAT5ZsQAA/kkXAAExYZAAABnHcAAABc/AAAAUQagAAYD7EAABEWPIAAAOV7gAAAnJwAAADEQIAAAe+dgABQzE2A Date: Sun, 13 Jul 2014 07:59:30 +0000 Message-ID: <8A0655C2-99CC-44C3-A287-1E73CD6BA51A@cisco.com> References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> In-Reply-To: <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.206.42] Content-Type: multipart/alternative; boundary="_000_8A0655C299CC44C3A2871E73CD6BA51Aciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/xlhzMHt1vfW0faQf-7K7HEtmsWo Cc: "Nobo Akiya \(nobo\)" , "Ruediger.Geib@telekom.de" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "spring@ietf.org" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 07:59:40 -0000 --_000_8A0655C299CC44C3A2871E73CD6BA51Aciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Sam, On Jul 11, 2014, at 6:25 PM, Sam Aldrin > wrote: Hi Carlos, On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) > wrote: Hi, Sam, On Jul 11, 2014, at 12:07 PM, Sam Aldrin > wrote: Carlos, On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) > wrote: Sam, Just to be clear: a use-case document is not a set of abstract generic requ= irements and nothing else. Use case is not requirements to then think of a = solution -- that would be a requirements document. Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is. This document describes the specific case of how to use a specific technolo= gy (spring) to solve a particular problem. The Abstract is pretty clear on = that: Abstract This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. [...] This scenario cannot be decoupled from its actual use case. Well then the introduction says the following The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. ... .. The proposed solution offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of a domains forwarding paths. Thanks for pointing these out. I think you are cherry-picking and extrapola= ting the word "solution" way further than intended, and adding meaning to i= t as if it supports requirements. %s/The solution/The use case/ s/The proposed solution/The presented use case/ You are trivializing what I was eluding to in my earlier emails. If indeed you are not talking about solution, do you think sections 4-7 tal= k about use cases? When I read the document the way it is worded and understood was to PMS sol= ution (sec #2) trying to solve problem in a specific. If you don't believe,= do "%s/PMS/NMS/g" and see. Don't misconstrue that I am saying there is no use case. I did not imply that you said there is no use case. My point is that the "s= olution" is part of the use case itself, and that a use case is not a set o= f requirements -- this use case document explains how the use case works (i= .e., the case of the benefits for OAM of having Source Packet Routing in Ne= tworks). You were asking about removing solutions from the use case -- I am= reacting to that. Otherwise, I might be misunderstanding your point. I agree that additional text on showing how proxy-lsp-ping could support it= can potentially be useful, but not with "remove all solutions". Further, m= aybe the use case can be generalized even more. Again, it is up to you authors what to retain in the document or what to ad= d. We could review accordingly. If there are solutions and proposals to existing solutions in this ID, then= it will lead into solutions discussions, which is what is happening right = now. What I think would be more useful would be to channel the review cycles tow= ards oam uses that get enabled by the spring architecture. That is, * is this a simple remote (proxy?) realization/use for oam in spring networ= ks? * can this use case be generalized to the spring ipv6 dataplane? [I think s= o] * can this use case be used with S-BFD? In addition, this document should add more details about the scenarios of I= Pv6 w.r.t SR, or add specific pointers for the same. Certainly these scenarios need to also be documented. Also consider the comments in my earlier emails. As far as S-BFD goes, refe= r to sec 3.4 of S-BFD use case document. Yes, this citations should be good. Thanks, Carlos. -sam Thanks, Carlos. cheers -sam Thanks, Carlos. On Jul 11, 2014, at 11:24 AM, Sam Aldrin > wrote: Hi Rudiger, As I acknowledged in my earlier emails, the question is not about valid use= cases exist or not, rather it is about the document and what the text says= . Document is not clear on just use cases only because it touches various s= olution aspects, which is unnecessary. For example, use cases should not ca= re what RFC4379 can or cannot, that discussion should happen after the requ= irements which gets originated by these use cases. Once you cleanup the document and remove solution specific parts, it should= be ok. We could defer the discussion of what the existing solutions could = and could not do, for solution document and continue discussions of those p= ieces, then. cheers -sam On Jul 11, 2014, at 12:15 AM, > > = wrote: Hi Nobo, hi Sam the use case is to enable monitoring of an MPLS domain without accessing th= e control plane. To do so, a PMS needs MPLS topology awareness, which it ge= ts by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think. Monitoring without control plane access is part of the use case, not part o= f a solution discussion (to say it differently: using the data plane for OA= M purposes is not an option which may be removed). As many SR based OAM fea= tures can be used without OAM specific protocols or functions being added t= o Segment Routing, I think it=92s perfectly ok to formulate the use case as= is. The main requirement is: specify Segment Routing. Then one may add OAM= boxes which apply SR features. RFC4379 could also monitor LSPs, but it requires using the control plane an= d proxy-lsp-ping adds control plane based functionality to RFC4379. It is a= n approach resulting in similar features, but it is control plane based. Th= is is a different use case. If an operator needs to validate that a packet travels a certain path or tr= ace the path a lost packet has taken, then RFC4379 functionality is needed.= It=92s a difference whether RFC4379 is applied only at off peak times or a= fter a data plane only monitoring packet has been lost along one path or wh= ether that has to be done constantly. Regards, Ruediger Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Gesendet: Donnerstag, 10. Juli 2014 21:46 An: Sam Aldrin Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase Betreff: RE: [spring] Questions Hi Sam, I just wanted to point out the key described behavior, wasn=92t saying anyt= hing about whether this document should be a use-case document or a solutio= n document :) Thanks! -Nobo From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, July 10, 2014 3:10 PM To: Nobo Akiya (nobo) Cc: Ruediger.Geib@telekom.de; spring; draf= t-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Nobo, Inline for my comments. On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) > wrote: Hi Sam, Just to point out one thing about this document =85 The test packet generated from a PMS/NMS/EMS/network-device can have the co= mplete segment stack on how to traverse the network as well as how to come = back to self without any further signaling, OAM state maintenance on networ= k nodes nor OAM involvement by network nodes. That is fine as a requirement/usecase and we should limit the scope to that= , than specifying how to solve it. That makes this approach quite different from using proxy LSP ping. You are talking about solution or use case? :D This certainly has some pros and cons but can be quite useful as one of the= OAMs (yes plural) used to monitor the network. Certainly. But I am struggling between use case and solution outlined in th= e document. Pick one :D -sam Thanks! -Nobo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 10, 2014 2:13 PM To: Ruediger.Geib@telekom.de Cc: spring; draft-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, > wrote: Hi Sam, my replies are marked [RG] and added to your text. - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft. - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= ) Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. %sam - I believe you say it is use case document below. Then solution is to= o premature at this point of time, as we haven't deliberated on the require= ments either. As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. Regards, Ruediger Sam Aldrin wrote: I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section = #1 it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and = not just providing use cases/scenarios. My understanding was, use case draft = should document scenarios where it will drive new requirements. Solutions c= ould be covered with existing toolset or defined newly, depending on the = GAP analysis. But that should be separate as there could be more than 1 = solution, where as this document could just focus on use cases only. If infact this is supposed to be a solution document, then changing = the title would be more meaningful. That's my observation. [RG] Thanks. It's a use case document. We'll review the text of section 1. %sam - OK. then I'd like to see any specific solution content removed, that= way we dont have to discuss what other solutions does either or compare wi= th :D 2. w.r.t. Section number #2, the same problem is being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in thi= s section could be done with the proxy ping(solution wise) where, requ= est could be sent to monitor LER i and LER j segment, from a PMS. Is my unders= tanding right? If not, how is it different here? [RG] The PMS is able to set up packets which stay in data plane and execute= a desired chain of MPLS LSPs. %sam - Execute you mean traverse? or perform something else? [RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down a LSP or part of an LSP. %sam - If it is proposing extensions, it has to be solution document and = cannot claim to be use case document. Also this document is on information = track. [RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds functionality: a) You don't need an additional protocol or functionality like proxy-ping t= o check data plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS imple= mentation. %sam - RFC4379 performs validation of dataplane and also find out lot more = errors. You need additional information to perform validation checks. For l= iveness detection, BFD is preferred tool, atleast in present deployments.So= are you saying, PMS solution is designed for liveness detection and not to= perform validation of data plane to control plane, etc? (I think you agree= to this in the later part of the doc also) b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379, it can continue to execute arbitrary LSP combinations and the monitoring= packets stay in data plane. Please point me to the text in proxy-ping offering this f= eature. %sam - This you could perform even without proxy ping. The function you are= describing is, how you use lsp ping rather than what lsp ping does. Again = I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implement= ation. - perform ping with right selectors for the path and use TTL for limiting t= he hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy pi= ng to start from LER i 3. When the response is sent back to PMS which is not part of MPLS = or segment domain, there is a serious security aspect, which needs to consider= ed. I believe it applies to sending a request too. Will you be documenting that a= spect? [RG] That's a valid point. The domain external system is one option and the= team will deal with the security aspects raised by this option once we are= in solution space. We will not analyse this in depth for a use case docume= nt. %sam - nod 4. Sec 3.2 to monitor bundle links, one could perform that with RFC= 4379 ping with multpath + proxy ping. Could you kindly differentiate if there= is something new the solution brings here? [RG] The SR OAM author team has provided text how to monitor a bundled link= in the use case draft. You are a co-author of proxy-lsp. I couldn't find e= xplicit text on how to detect and monitor a bundled link in draft-proxy-lsp= . Please describe how proxy-lsp can be used to monitor a bundled link (sorr= y if this is obvious and I missed it). If there are differences to the SR O= AM approach, we'll discuss them. %sam - The same steps described above could be used if each bundled link me= mber is identified with a unique label. While performing tree trace or ping= with multipath, LER i will respond with DDMAP info for each of the links a= nd the multipath info for the same. If you say that each link member has same label stack, then you could use l= sp selectors as defined in RFC4379, in this case it is local host dest ip a= ddr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but= cannot discern its link members, then you could only validate the interfac= e and not its individual members. Same applies in your case too. Cannot see how it is different. 5. sec #5, Is the requirement here only for PMS to learn the topol= ogy, in the case of mixed env? [RG] MPLS topology awareness is the precondition to set up packets with lab= el stacks executing a desired chain of LSPs. If suitable Label/FEC/node rel= ation is known to the PMS, that LSP can be executed from that node on by a = PMS monitoring packet. %sam - So, you are saying that you still need to perform RFC4379 trace or t= reetrace to get topology. I do not think IGP extensions being proposed in S= PRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand= per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and P= MS packets going through, for a given LSP or Segment, how do you know there= is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop becaus= e of the bells and whistles it carries along with the packet. 6. In sec 3.1, Determining a path to be executed prior to a measurement may also = be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). T= he advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths= of an MPLS domain. If correct forwarding along the desired paths has= to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But la= ter you say, RFC4379 functionality could be used. Could you clarify how could y= ou verify a path, if MPLS validation is not done. More text will help. Also, m= ore importantly, the text earlier to the above says, for valid result,= MPLS OAM has to be performed for topology changes etc. If so, it contra= dicts here. [RG] The text should say that - without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information. - if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied. If you understand this statement and the text in the draft states something= different, I'll try to reword it. %sam - The problem I am having is, in the case of MPLS, for OAM, you have t= o validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use ca= se is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear= on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. 7. Last but not the least, how different is PMS from EMS and NMS? Somehow I couldn't find the difference what PMS could do and NMS/EMS couldn't. [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses t= his topology awareness to create data plane packets executing LSP combinati= ons as desired by an operator. Had this feature been commercially available= , the company I work for wouldn't have been developing a PMS. %sam - There are tools which are part of NMS/OSS, which performs MPLS topol= ogy specific operations for a given set of LSP's. They perform Treetrace a= nd perform ping with multipath. Also perform LSP specific validation by cra= fting packets with data available with treetrace and ping with multipath. Y= ou could automate the workflow without the need for OSS/PMS, by using probe= technology. Will not say beyond that :D cheers -sam _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_8A0655C299CC44C3A2871E73CD6BA51Aciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <757FD8B0569A834B8A96D7DDC0EA255E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi, Sam,

On Jul 11, 2014, at 6:25 PM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract generic= requirements and nothing else. Use case is not requirements to then think = of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is.

This document describes the specific case of how to use a specific tec= hnology (spring) to solve a particular problem. The Abstract is pretty clea= r on that:

Abstract

   This document describes features and a use case of a path= monitoring
   system.  Segment based routing enables a scalable an= d simple method
   to monitor data plane liveliness of the complete set of p= aths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS domain.


The solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed LSP's.
...
..
Th=
e proposed solution offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding paths.

<snip>



Thanks for pointing these out. I think you are cherry-picking and extr= apolating the word "solution" way further than intended, and addi= ng meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/

You are trivializing what I was eluding to in my earlier emails.
If indeed you are not talking about solution, do you think sections 4-= 7 talk about use cases?
When I read the document the way it is worded and understood was to PM= S solution (sec #2) trying to solve problem in a specific. If you don't bel= ieve, do "%s/PMS/NMS/g" and see.

Don't misconstrue that I am saying there is no use case.


I did not imply that you said there is no use case. My point is that t= he "solution" is part of the use case itself, and that a use case= is not a set of requirements -- this use case document explains how the us= e case works (i.e., the case of the benefits for OAM of having Source Packet Routing in Networks). You were asking abou= t removing solutions from the use case -- I am reacting to that. Otherwise,= I might be misunderstanding your point.





I agree that additional text on showing how proxy-lsp-ping could suppo= rt it can potentially be useful, but not with "remove all solutions&qu= ot;. Further, maybe the use case can be generalized even more.


Again, it is up to you authors what to retain in the document or what = to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this ID,= then it will lead into solutions discussions, which is what is happening r= ight now.


What I think would be more useful would be to channel the review cycle= s towards oam uses that get enabled by the spring architecture. That is,
* is this a simple remote (proxy?) realization/use for oam in spring n= etworks?
* can this use case be generalized to the spring ipv6 dataplane? [I th= ink so]
* can this use case be used with S-BFD?

In addition, this document should add more details about the scenarios of I= Pv6 w.r.t SR, or add specific pointers for the same.

Certainly these scenarios need to also be documented.

Also consider the comments in my earlier emails. As far as S-BFD goes,= refer to sec 3.4 of S-BFD use case document.


Yes, this citations should be good.

Thanks,

Carlos.

-sam


Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about vali= d use cases exist or not, rather it is about the document and what the text= says. Document is not clear on just use cases only because it touches vari= ous solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that di= scussion should happen after the requirements which gets originated by thes= e use cases.

Once you cleanup the document and remove solution specific parts, it s= hould be ok. We could defer the discussion of what the existing solutions c= ould and could not do, for solution document and continue discussions of th= ose pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:

Hi Nobo, hi Sam
 
the use case is to enable monitoring of an = MPLS domain without accessing the control plane. To do so, a PMS needs MPLS= topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, witho= ut going into too many details, I think.
 
Monitoring without control plane access is = part of the use case, not part of a solution discussion (to say it differen= tly: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features can = be used without OAM specific protocols or functions being added to Segment = Routing, I think it=92s perfectly ok to formulate the use case as is. The m= ain requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR features.
 
RFC4379 could also monitor LSPs, but it req= uires using the control plane and proxy-lsp-ping adds control plane based f= unctionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a di= fferent use case.
 
If an operator needs to validate that a pac= ket travels a certain path or trace the path a lost packet has taken, then = RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after a = data plane only monitoring packet has been lost along one path or whether t= hat has to be done constantly.
 
Regards,
 
Ruediger
 
Von:=  Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerst= ag, 10. Juli 2014 21:46
An: Sam Aldrin
Cc: Geib, R=FCdige= r; spring; draft-geib-spring-oam-usecase
Betreff: RE: [spri= ng] Questions
 
Hi Sam,
 
I just wanted to point out the key describe= d behavior, wasn=92t saying anything about whether this document should be = a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: = Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, Ju= ly 10, 2014 3:10 PM
To: Nobo Akiya (no= bo)
Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase=
Subject: Re: [spri= ng] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) &l= t;nobo@cisco.com> wrote:
Hi Sam,
 
Just to point out one thing about this docu= ment =85
 
The test packet generated from a PMS/NMS/EM= S/network-device can have the complete segment stack on how to traverse the= network as well as how to come back to self without any further signaling, OAM state maintenance on network no= des nor OAM involvement by network nodes.<= /o:p>
That is fine as a requirement/usecase and we should li= mit the scope to that, than specifying how to solve it.
 
That makes this approach quite different fr= om using proxy LSP ping.
You are talking about solution or use case? :D
 
 
This certainly has some pros and cons but c= an be quite useful as one of the OAMs (yes plural) used to monitor the netw= ork.
Certainly. But I am struggling between use case and so= lution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: = spring [mailto:spring-bounces= @ietf.org] On Behalf Of Sam Aldrin=
Sent: Thursday, Ju= ly 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; draft-= geib-spring-oam-usecase
Subject: Re: [spri= ng] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my response= s inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. 
%sam - I believe you say it is use case document below= . Then solution is too premature at this point of time, as we haven't delib= erated on the requirements either. 

As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use case = but in section #1
      it says the following

      <snip>
       This document describes a solution to this probl= em statement and
       illustrates it with use-cases.

       The solution is described for a single IGP MPLS = domain.

       The solution applies to monitoring of LDP LSP's = as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to ce= rtain scenarios and not just
       providing use cases/scenarios. My understanding = was, use case draft should
       document scenarios where it will drive new requi= rements. Solutions could
       be covered with existing toolset or defined newl= y, depending on the GAP
       analysis. But that should be separate as there c= ould be more than 1 solution,
       where as this document could just focus on use c= ases only.

       If infact this is supposed to be a solution docu= ment, then changing the title
       would be more meaningful. That's my observation.=

[RG] Thanks. It's a use case document. We'll review th= e text of section 1.
%sam - OK. then I'd like to see any specific solution = content removed, that way we dont have to discuss what other solutions does= either or compare with :D
 


       2. w.r.t. Section number #2, the same problem is= being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
       section could be done with the proxy ping(soluti= on wise) where, request could
       be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
       right? If not, how is it different here?

[RG] The PMS is able to set up packets which stay in d= ata plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform something= else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request mes= sage to
   be sent down a LSP or part of an LSP.
%sam - If it is proposing extensions,  it has to = be solution document  and cannot claim to be use case document. Also t= his document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-ping t= o check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.
%sam - RFC4379 performs validation of dataplane and al= so find out lot more errors. You need additional information to perform val= idation checks. For liveness detection, BFD is preferred tool, atleast in p= resent deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validat= ion of data plane to control plane, etc? (I think you agree to this in the = later part of the doc also)
 
b) once PMS detected data plane liveliness and correct= ness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
   in data plane. Please point me to the text in proxy-ping offer= ing this feature.
%sam - This you could perform even without proxy ping.= The function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology.
To answer your question, how you perform.
- Perform treetrace with rfc4379 to get topology info<= o:p>
- pick any arbitary LSP paths discovered along with it= s multipath implementation.
- perform ping with right selectors for the path and u= se TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in you= r draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS which = is not part of MPLS or segment
        domain, there is a serious security aspect, whi= ch needs to considered. I believe
        it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external system = is one option and the team will deal with the security aspects raised by th= is option once we are in solution space. We will not analyse this in depth = for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
        with multpath + proxy ping. Could you kindl= y differentiate if there is something
        new the solution brings here?=

[RG] The SR OAM author team has provided text how to m= onitor a bundled link in the use case draft. You are a co-author of proxy-l= sp. I couldn't find explicit text on how to detect and monitor a bundled li= nk in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is obvi= ous and I missed it). If there are differences to the SR OAM approach, we'l= l discuss them.
%sam - The same steps described above could be used if= each bundled link member is identified with a unique label. While performi= ng tree trace or ping with multipath, LER i will respond with DDMAP info fo= r each of the links and the multipath info for the same.
If you say that each link member has same label stack,= then you could use lsp selectors as defined in RFC4379, in this case it is= local host dest ip addr, to identify each link member.
Now if the MPLS forwarding layer sees the bundled link= as one interface but cannot discern its link members, then you could only = validate the interface and not its individual members.
Same applies in your case too. Cannot see how it is di= fferent.
 



         5. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
            case of mixed env?

[RG] MPLS topology awareness is the precondition to se= t up packets with label stacks executing a desired chain of LSPs. If suitab= le Label/FEC/node relation is known to the PMS, that LSP can be executed fr= om that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to perfo= rm RFC4379 trace or treetrace to get topology. I do not think IGP extension= s being proposed in SPRING export any of the info other than label stack.&n= bsp;
And the proposed PMS solution (not use case) is that, = it performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology.
The case you are making is that no need of bells and w= histles of RFC4379.
 
Question I have for you is, if data plane packets are = getting dropped and PMS packets going through, for a given LSP or Segment, = how do you know there is a problem? if you know, how do you figure out wher= e it is?
At least with RFC4379 and/or proxy ping, you could val= idate each hop because of the bells and whistles it carries along with the = packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed prior t= o a measurement may also be
         done by setting up a label including all = node SIDs along that path
         (if LER1 has Node SID 40 in the example a= nd it should be passed
         between LER i and LER j, the label stack = is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it does= not involve MPLS OAM
         functionality and it is independent of EC= MP functionalities.  The
         method still is able to monitor all link = combinations of all paths of
         an MPLS domain.  If correct forwardi= ng along the desired paths has to
         be checked, RFC4739 functionality should = be applied also in this
         case.

         <end snip>

         In the above you mention that it does not= involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. Coul= d you clarify how could you verify a
         path, if MPLS validation is not done. Mor= e text will help. Also, more
         importantly, the text earlier to the abov= e says, for valid result, MPLS
         OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.
%sam - The problem I am having is, in the case of MPLS= , for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but what = I feel is, the use case is too much catered to a specific envisioned soluti= on.
Once you remove solution or suggested enhancements, ho= pe it should be clear on what is being solved and scope out clear requireme= nts for a solution.
For solution part, please publish a separate ID.<= /o:p>
 


         7. Last but not the least, how different = is PMS from EMS and NMS?
         Somehow I couldn't find the difference wh= at PMS could do and
         NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topo= logy aware and uses this topology awareness to create data plane packets ex= ecuting LSP combinations as desired by an operator. Had this feature been c= ommercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, whic= h performs MPLS topology specific operations  for a given set of LSP's= . They perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with treetrace and ping with multipath. You could auto= mate the workflow without the need for OSS/PMS, by using probe technology. = Will not say beyond that :D
 
cheers
-sam

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring




_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

--_000_8A0655C299CC44C3A2871E73CD6BA51Aciscocom_-- From nobody Sun Jul 13 01:18:15 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D261B29F2 for ; Sun, 13 Jul 2014 01:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzA2zaxsldtH for ; Sun, 13 Jul 2014 01:18:08 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF621B29F0 for ; Sun, 13 Jul 2014 01:18:08 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so260069pdj.8 for ; Sun, 13 Jul 2014 01:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nBWH473WJsSsx+HWZ8W5gairGt506/QLOYT0CUcp3sU=; b=l+5YHTIXP9SZNPsX2G3iprcprULQzcrJ6rjpnBkKkV/Yoj50TDU33YYeYfQ4MLE/d4 lEabz94iMbZIKlwprNqX7eS3Imo0un4IB0MyWgG52vSi6twBmKGZyno1aPHBYRh/E5nG Twf30V5/dFPLfY9ipdG5ZjjR6NvkpciQuxW0ofGNdQyAY8ghn9J3aYAMjFP2BCapEtHC g7PBv70YP2+04Zl9LqRuDhR0XSGO13wLKqLH6nToiURqWbyxV0hiep5DYnCPRNQ8rPUu HjV0ysEUIr6I+4xuq5Y+oJfPrjYg0OL/p7xYgE5Oel92N9nnb78zKA8Ul841AEoJSSM4 VJuw== X-Received: by 10.68.171.131 with SMTP id au3mr60908pbc.125.1405239487688; Sun, 13 Jul 2014 01:18:07 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id gg3sm7183598pbc.34.2014.07.13.01.18.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jul 2014 01:18:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0D3212E-7ED5-4CA4-B691-C233B9127BB4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: <8A0655C2-99CC-44C3-A287-1E73CD6BA51A@cisco.com> Date: Sun, 13 Jul 2014 01:18:03 -0700 Message-Id: <6B4D46C6-B52A-4B16-906C-EC2684E3A670@gmail.com> References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> <8A0655C2-99CC-44C3-A287-1E73CD6BA51A@cisco.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/n4Fkdb48hE95XHb5Twci8ZnIvzk Cc: "Nobo Akiya \(nobo\)" , "Ruediger.Geib@telekom.de" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "spring@ietf.org" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 08:18:12 -0000 --Apple-Mail=_E0D3212E-7ED5-4CA4-B691-C233B9127BB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Carlos, comments inline. On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) = wrote: > Hi, Sam, >=20 > On Jul 11, 2014, at 6:25 PM, Sam Aldrin wrote: >=20 >> Hi Carlos, >>=20 >> On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) = wrote: >>=20 >>> Hi, Sam, >>>=20 >>> On Jul 11, 2014, at 12:07 PM, Sam Aldrin = wrote: >>>=20 >>>> Carlos, >>>>=20 >>>> On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) = wrote: >>>>=20 >>>>> Sam, >>>>>=20 >>>>> Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document. >>>> Neither did I ask for requirements only nor to be abstract, rather = to document to capture use cases, if that is what the authors intent for = this document is. >>>>>=20 >>>>> This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that: >>>>>=20 >>>>> Abstract >>>>>=20 >>>>> This document describes features and a use case of a path = monitoring >>>>> system. Segment based routing enables a scalable and simple = method >>>>> to monitor data plane liveliness of the complete set of paths >>>>> belonging to a single domain. [...] >>>>>=20 >>>>> This scenario cannot be decoupled from its actual use case. >>>> Well then the introduction says the following >>>> >>>> The solution is described for a single IGP MPLS domain. >>>>=20 >>>> The solution applies to monitoring of LDP LSP's as well as to >>>> monitoring of Segment Routed LSP's. >>>> ... >>>> .. >>>> The proposed solution offers several benefits for network = monitoring. >>>> A single centralized monitoring device is able to monitor the >>>> complete set of a domains forwarding paths. >>>>=20 >>>> >>>>=20 >>>>=20 >>>=20 >>> Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements. >>>=20 >>> %s/The solution/The use case/ >>> s/The proposed solution/The presented use case/ >>=20 >> You are trivializing what I was eluding to in my earlier emails. >> If indeed you are not talking about solution, do you think sections = 4-7 talk about use cases? >> When I read the document the way it is worded and understood was to = PMS solution (sec #2) trying to solve problem in a specific. If you = don't believe, do "%s/PMS/NMS/g" and see. >>=20 >> Don't misconstrue that I am saying there is no use case. >>=20 >=20 > I did not imply that you said there is no use case. My point is that = the "solution" is part of the use case itself, and that a use case is = not a set of requirements -- this use case document explains how the use = case works (i.e., the case of the benefits for OAM of having Source = Packet Routing in Networks). You were asking about removing solutions = from the use case -- I am reacting to that. Otherwise, I might be = misunderstanding your point. I am only providing comment, whether to remove or not is upto you, the = authors. If you want to keep solution, that is fine too, but that will only delay = the progression of the document, because, we will be discussing which = solution is better and which isn=92t for a given use case. I could see why some of the existing solutions could do some of the = tasks, without the need of enhancement. As you could see from my earlier = arguments, I was commenting on the solution parts, not for use case. I prefer to see the use case be present in a simple and concise way and = solution be deferred to solution document. Again, your call :D To provide more reason for my argument, for ex: why should I care = RFC4379 solve a specific use case or not? Use case is valid but it could = be solved multiple ways. Similarly, I need not solve a use case with = PMS, rather I could do with NMS. I do hope you see my point. >=20 >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even more. >>>>=20 >>>>=20 >>>> Again, it is up to you authors what to retain in the document or = what to add. >>>> We could review accordingly. >>>> If there are solutions and proposals to existing solutions in this = ID, then it will lead into solutions discussions, which is what is = happening right now. >>>>=20 >>>=20 >>> What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is, >>> * is this a simple remote (proxy?) realization/use for oam in spring = networks? >>> * can this use case be generalized to the spring ipv6 dataplane? [I = think so] >>> * can this use case be used with S-BFD? >>>=20 >> In addition, this document should add more details about the = scenarios of IPv6 w.r.t SR, or add specific pointers for the same. >=20 > Certainly these scenarios need to also be documented. cool thanks -sam >=20 >> Also consider the comments in my earlier emails. As far as S-BFD = goes, refer to sec 3.4 of S-BFD use case document. >>=20 >=20 > Yes, this citations should be good. >=20 > Thanks, >=20 > Carlos. >=20 >> -sam >>=20 >>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>>> cheers >>>> -sam >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Carlos. >>>>>=20 >>>>> On Jul 11, 2014, at 11:24 AM, Sam Aldrin = wrote: >>>>>=20 >>>>>> Hi Rudiger, >>>>>>=20 >>>>>> As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use = cases should not care what RFC4379 can or cannot, that discussion should = happen after the requirements which gets originated by these use cases. >>>>>>=20 >>>>>> Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then. >>>>>>=20 >>>>>> cheers >>>>>> -sam >>>>>>=20 >>>>>>=20 >>>>>> On Jul 11, 2014, at 12:15 AM, = wrote: >>>>>>=20 >>>>>>> Hi Nobo, hi Sam >>>>>>> =20 >>>>>>> the use case is to enable monitoring of an MPLS domain without = accessing the control plane. To do so, a PMS needs MPLS topology = awareness, which it gets by Segment Routing. The draft to some extent = explains how that is done, without going into too many details, I think. >>>>>>> =20 >>>>>>> Monitoring without control plane access is part of the use case, = not part of a solution discussion (to say it differently: using the data = plane for OAM purposes is not an option which may be removed). As many = SR based OAM features can be used without OAM specific protocols or = functions being added to Segment Routing, I think it=92s perfectly ok to = formulate the use case as is. The main requirement is: specify Segment = Routing. Then one may add OAM boxes which apply SR features. >>>>>>> =20 >>>>>>> RFC4379 could also monitor LSPs, but it requires using the = control plane and proxy-lsp-ping adds control plane based functionality = to RFC4379. It is an approach resulting in similar features, but it is = control plane based. This is a different use case. >>>>>>> =20 >>>>>>> If an operator needs to validate that a packet travels a certain = path or trace the path a lost packet has taken, then RFC4379 = functionality is needed. It=92s a difference whether RFC4379 is applied = only at off peak times or after a data plane only monitoring packet has = been lost along one path or whether that has to be done constantly. >>>>>>> =20 >>>>>>> Regards, >>>>>>> =20 >>>>>>> Ruediger >>>>>>> =20 >>>>>>> Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 >>>>>>> Gesendet: Donnerstag, 10. Juli 2014 21:46 >>>>>>> An: Sam Aldrin >>>>>>> Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase >>>>>>> Betreff: RE: [spring] Questions >>>>>>> =20 >>>>>>> Hi Sam, >>>>>>> =20 >>>>>>> I just wanted to point out the key described behavior, wasn=92t = saying anything about whether this document should be a use-case = document or a solution document J >>>>>>> =20 >>>>>>> Thanks! >>>>>>> =20 >>>>>>> -Nobo >>>>>>> =20 >>>>>>> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 >>>>>>> Sent: Thursday, July 10, 2014 3:10 PM >>>>>>> To: Nobo Akiya (nobo) >>>>>>> Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase >>>>>>> Subject: Re: [spring] Questions >>>>>>> =20 >>>>>>> Hi Nobo, >>>>>>> =20 >>>>>>> Inline for my comments. >>>>>>> =20 >>>>>>> On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = wrote: >>>>>>> Hi Sam, >>>>>>> =20 >>>>>>> Just to point out one thing about this document =85 >>>>>>> =20 >>>>>>> The test packet generated from a PMS/NMS/EMS/network-device can = have the complete segment stack on how to traverse the network as well = as how to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. >>>>>>> That is fine as a requirement/usecase and we should limit the = scope to that, than specifying how to solve it. >>>>>>> =20 >>>>>>> That makes this approach quite different from using proxy LSP = ping. >>>>>>> You are talking about solution or use case? :D >>>>>>> =20 >>>>>>> =20 >>>>>>> This certainly has some pros and cons but can be quite useful as = one of the OAMs (yes plural) used to monitor the network. >>>>>>> Certainly. But I am struggling between use case and solution = outlined in the document. Pick one :D >>>>>>> =20 >>>>>>> -sam=20 >>>>>>> =20 >>>>>>> Thanks! >>>>>>> =20 >>>>>>> -Nobo >>>>>>> =20 >>>>>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin >>>>>>> Sent: Thursday, July 10, 2014 2:13 PM >>>>>>> To: Ruediger.Geib@telekom.de >>>>>>> Cc: spring; draft-geib-spring-oam-usecase >>>>>>> Subject: Re: [spring] Questions >>>>>>> =20 >>>>>>> Hi Ruediger, >>>>>>> =20 >>>>>>> Thanks for the quick response. Please find my responses inline. >>>>>>> =20 >>>>>>>=20 >>>>>>> On Thu, Jul 10, 2014 at 7:15 AM, = wrote: >>>>>>> Hi Sam, >>>>>>>=20 >>>>>>> my replies are marked [RG] and added to your text. >>>>>>>=20 >>>>>>> - Proxy-lsp-ping is MPLS only, while the PMS architecture is = intended for every SR data plane (MPLS + IPv6). We'll clarify that in = the draft. >>>>>>> - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), = while our use case can use any OAM (in particular, specific good uses = for BFD, and ICMPv6) >>>>>>>=20 >>>>>>> Based on that, it=B9s a solution with broader scope and better = fit for SPRING as a whole.=20 >>>>>>> %sam - I believe you say it is use case document below. Then = solution is too premature at this point of time, as we haven't = deliberated on the requirements either.=20 >>>>>>>=20 >>>>>>> As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Ruediger >>>>>>>=20 >>>>>>>=20 >>>>>>> Sam Aldrin wrote: >>>>>>>=20 >>>>>>> I have few questions about this draft. >>>>>>>=20 >>>>>>> 1. The title is confusing to me. It says OAM use case but = in section #1 >>>>>>> it says the following >>>>>>>=20 >>>>>>> >>>>>>> This document describes a solution to this problem = statement and >>>>>>> illustrates it with use-cases. >>>>>>>=20 >>>>>>> The solution is described for a single IGP MPLS domain. >>>>>>>=20 >>>>>>> The solution applies to monitoring of LDP LSP's as well = as to >>>>>>> monitoring of Segment Routed LSP's. >>>>>>> >>>>>>>=20 >>>>>>> In fact the draft is describing a solution to certain = scenarios and not just >>>>>>> providing use cases/scenarios. My understanding was, use = case draft should >>>>>>> document scenarios where it will drive new requirements. = Solutions could >>>>>>> be covered with existing toolset or defined newly, = depending on the GAP >>>>>>> analysis. But that should be separate as there could be = more than 1 solution, >>>>>>> where as this document could just focus on use cases = only. >>>>>>>=20 >>>>>>> If infact this is supposed to be a solution document, = then changing the title >>>>>>> would be more meaningful. That's my observation. >>>>>>>=20 >>>>>>> [RG] Thanks. It's a use case document. We'll review the text of = section 1. >>>>>>> %sam - OK. then I'd like to see any specific solution content = removed, that way we dont have to discuss what other solutions does = either or compare with :D >>>>>>> =20 >>>>>>>=20 >>>>>>> 2. w.r.t. Section number #2, the same problem is being = solved with >>>>>>> "draft-ietf-mpls-proxy-lsp-ping-02" . What is being = described in this >>>>>>> section could be done with the proxy ping(solution wise) = where, request could >>>>>>> be sent to monitor LER i and LER j segment, from a PMS. = Is my understanding >>>>>>> right? If not, how is it different here? >>>>>>>=20 >>>>>>> [RG] The PMS is able to set up packets which stay in data plane = and execute a desired >>>>>>> chain of MPLS LSPs. >>>>>>> %sam - Execute you mean traverse? or perform something else?=20 >>>>>>>=20 >>>>>>> [RG] Proxy-lsp says: This document defines protocol extensions = to MPLS ping [RFC4379] to >>>>>>> allow a third party to remotely cause an MPLS Echo Request = message to >>>>>>> be sent down a LSP or part of an LSP. >>>>>>> %sam - If it is proposing extensions, it has to be solution = document and cannot claim to be use case document. Also this document = is on information track. >>>>>>>=20 >>>>>>> [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds >>>>>>> functionality: >>>>>>> a) You don't need an additional protocol or functionality like = proxy-ping to check data >>>>>>> plane liveliness, RFC4379 is fine. Deutsche Telekom operates = a PMS implementation. >>>>>>> %sam - RFC4379 performs validation of dataplane and also find = out lot more errors. You need additional information to perform = validation checks. For liveness detection, BFD is preferred tool, = atleast in present deployments.So are you saying, PMS solution is = designed for liveness detection and not to perform validation of data = plane to control plane, etc? (I think you agree to this in the later = part of the doc also) >>>>>>> =20 >>>>>>> b) once PMS detected data plane liveliness and correctness of = MPLS topology by RFC4379, >>>>>>> it can continue to execute arbitrary LSP combinations and the = monitoring packets stay >>>>>>> in data plane. Please point me to the text in proxy-ping = offering this feature. >>>>>>> %sam - This you could perform even without proxy ping. The = function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology. >>>>>>> To answer your question, how you perform. >>>>>>> - Perform treetrace with rfc4379 to get topology info >>>>>>> - pick any arbitary LSP paths discovered along with its = multipath implementation. >>>>>>> - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. >>>>>>> - if you want to perform from LER i to LER j as in your draft, = use proxy ping to start from LER i >>>>>>>=20 >>>>>>> 3. When the response is sent back to PMS which is not = part of MPLS or segment >>>>>>> domain, there is a serious security aspect, which needs = to considered. I believe >>>>>>> it applies to sending a request too. Will you be = documenting that aspect? >>>>>>>=20 >>>>>>> [RG] That's a valid point. The domain external system is one = option and the team will deal with the security aspects raised by this = option once we are in solution space. We will not analyse this in depth = for a use case document. >>>>>>> %sam - nod=20 >>>>>>>=20 >>>>>>> 4. Sec 3.2 to monitor bundle links, one could perform = that with RFC4379 ping >>>>>>> with multpath + proxy ping. Could you kindly = differentiate if there is something >>>>>>> new the solution brings here? >>>>>>>=20 >>>>>>> [RG] The SR OAM author team has provided text how to monitor a = bundled link in the use case draft. You are a co-author of proxy-lsp. I = couldn't find explicit text on how to detect and monitor a bundled link = in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor = a bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. >>>>>>> %sam - The same steps described above could be used if each = bundled link member is identified with a unique label. While performing = tree trace or ping with multipath, LER i will respond with DDMAP info = for each of the links and the multipath info for the same. >>>>>>> If you say that each link member has same label stack, then you = could use lsp selectors as defined in RFC4379, in this case it is local = host dest ip addr, to identify each link member. >>>>>>> Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. >>>>>>> Same applies in your case too. Cannot see how it is different. >>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 5. sec #5, Is the requirement here only for PMS to = learn the topology, in the >>>>>>> case of mixed env? >>>>>>>=20 >>>>>>> [RG] MPLS topology awareness is the precondition to set up = packets with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. >>>>>>> %sam - So, you are saying that you still need to perform RFC4379 = trace or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 >>>>>>> And the proposed PMS solution (not use case) is that, it = performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology. >>>>>>> The case you are making is that no need of bells and whistles of = RFC4379. >>>>>>> =20 >>>>>>> Question I have for you is, if data plane packets are getting = dropped and PMS packets going through, for a given LSP or Segment, how = do you know there is a problem? if you know, how do you figure out where = it is? >>>>>>> At least with RFC4379 and/or proxy ping, you could validate each = hop because of the bells and whistles it carries along with the packet. >>>>>>> =20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 6. In sec 3.1, >>>>>>> >>>>>>> Determining a path to be executed prior to a = measurement may also be >>>>>>> done by setting up a label including all node SIDs = along that path >>>>>>> (if LER1 has Node SID 40 in the example and it should = be passed >>>>>>> between LER i and LER j, the label stack is 20 - 40 - = 30 - 10). The >>>>>>> advantage of this method is, that it does not involve = MPLS OAM >>>>>>> functionality and it is independent of ECMP = functionalities. The >>>>>>> method still is able to monitor all link combinations = of all paths of >>>>>>> an MPLS domain. If correct forwarding along the = desired paths has to >>>>>>> be checked, RFC4739 functionality should be applied = also in this >>>>>>> case. >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> In the above you mention that it does not involve MPLS = OAM. But later you say, >>>>>>> RFC4379 functionality could be used. Could you clarify = how could you verify a >>>>>>> path, if MPLS validation is not done. More text will = help. Also, more >>>>>>> importantly, the text earlier to the above says, for = valid result, MPLS >>>>>>> OAM has to be performed for topology changes etc. If = so, it contradicts here. >>>>>>>=20 >>>>>>> [RG] The text should say that >>>>>>> - without MPLS OAM functions, the PMS executes a set of paths = only based on control plane information. >>>>>>> - if the operator wants to make sure that data plane corresponds = to control plane, RFC4739 functions should be applied. >>>>>>> If you understand this statement and the text in the draft = states something different, I'll try to reword it. >>>>>>> %sam - The problem I am having is, in the case of MPLS, for OAM, = you have to validate the lsp. >>>>>>> I definitely see a specific need for SPRING, but what I feel is, = the use case is too much catered to a specific envisioned solution. >>>>>>> Once you remove solution or suggested enhancements, hope it = should be clear on what is being solved and scope out clear requirements = for a solution. >>>>>>> For solution part, please publish a separate ID. >>>>>>> =20 >>>>>>>=20 >>>>>>> 7. Last but not the least, how different is PMS from = EMS and NMS? >>>>>>> Somehow I couldn't find the difference what PMS could = do and >>>>>>> NMS/EMS couldn't. >>>>>>>=20 >>>>>>> [RG] I've never heard of an EMS/NMS which is MPLS topology aware = and uses this topology awareness to create data plane packets executing = LSP combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. >>>>>>> %sam - There are tools which are part of NMS/OSS, which performs = MPLS topology specific operations for a given set of LSP's. They = perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with = treetrace and ping with multipath. You could automate the workflow = without the need for OSS/PMS, by using probe technology. Will not say = beyond that :D >>>>>>> =20 >>>>>>> cheers >>>>>>> -sam >>>>>>=20 >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 --Apple-Mail=_E0D3212E-7ED5-4CA4-B691-C233B9127BB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Carlos,

comments inline.
On Jul 13, = 2014, at 12:59 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

On Jul 11, 2014, at 6:25 PM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to = document to capture use cases, if that is what the authors intent for = this document is.

This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that:

Abstract

   This document describes features and a use case of a = path monitoring
   system.  Segment based routing enables a scalable = and simple method
   to monitor data plane liveliness of the complete set = of paths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS =
domain.


The solution applies to monitoring of LDP LSP's as =
well as to
   monitoring of Segment Routed =
LSP's.
...
..
The proposed solution =
offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding =
paths.

<snip>

Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/

You are trivializing what I was eluding to in my earlier emails.
If indeed you are not talking about solution, do you think sections = 4-7 talk about use cases?
When I read the document the way it is worded and understood was to = PMS solution (sec #2) trying to solve problem in a specific. If you = don't believe, do "%s/PMS/NMS/g" and see.

Don't misconstrue that I am saying there is no use case.


I did not imply that you said there is no use case. My point is = that the "solution" is part of the use case itself, and that a use case = is not a set of requirements -- this use case document explains how the = use case works (i.e., the case of the benefits for OAM of having Source Packet Routing in Networks). You were asking = about removing solutions from the use case -- I am reacting to that. = Otherwise, I might be misunderstanding your = point.
I am only providing comment, = whether to remove or not is upto you, the authors.
If you want = to keep solution, that is fine too, but that will only delay the = progression of the document, because, we will be discussing which = solution is better and which isn=92t for a given use case.
I = could see why some of the existing solutions could do some of the tasks, = without the need of enhancement. As you could see from my earlier = arguments, I was commenting on the solution parts, not for use = case.
I prefer to see the use case be present in a simple and = concise way and solution be deferred to solution document. Again, your = call :D

To provide more reason for my argument, = for ex: why should I care RFC4379 solve a specific use case or not? Use = case is valid but it could be solved multiple ways. Similarly, I need = not solve a use case with PMS, rather I could do with NMS. I do hope you = see my point.






I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even = more.


Again, it is up to you authors what to retain in the document or = what to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this = ID, then it will lead into solutions discussions, which is what is = happening right now.


What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is,
* is this a simple remote (proxy?) realization/use for oam in = spring networks?
* can this use case be generalized to the spring ipv6 dataplane? [I = think so]
* can this use case be used with S-BFD?

In addition, this document should add more details about the scenarios = of IPv6 w.r.t SR, or add specific pointers for the same.

Certainly these scenarios need to also be = documented.
cool

thanks
-sam

Also consider the comments in my earlier emails. As far as S-BFD = goes, refer to sec 3.4 of S-BFD use case document.


Yes, this citations should be good.

Thanks,

Carlos.

-sam


Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that = discussion should happen after the requirements which gets originated by = these use cases.

Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> = <Ruediger.Geib@telekom.de> = wrote:

Hi Nobo, hi = Sam
 
the use case is to enable = monitoring of an MPLS domain without accessing the control plane. To do = so, a PMS needs MPLS topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think.
 
Monitoring without control plane = access is part of the use case, not part of a solution discussion (to = say it differently: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features = can be used without OAM specific protocols or functions being added to = Segment Routing, I think it=92s perfectly ok to formulate the use case = as is. The main requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR = features.
 
RFC4379 could also monitor LSPs, = but it requires using the control plane and proxy-lsp-ping adds control = plane based functionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a = different use case.
 
If an operator needs to validate = that a packet travels a certain path or trace the path a lost packet has = taken, then RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after = a data plane only monitoring packet has been lost along one path or = whether that has to be done constantly.
 
Regards,
 
Ruediger
 
Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerstag, 10. Juli 2014 = 21:46
An: Sam = Aldrin
Cc: Geib, = R=FCdiger; spring; draft-geib-spring-oam-usecase
Betreff: RE: = [spring] Questions
 
Hi Sam,
 
I just wanted to point out the key = described behavior, wasn=92t saying anything about whether this document = should be a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, = July 10, 2014 3:10 PM
To: Nobo Akiya = (nobo)
Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:
Hi Sam,
 
Just to point out one thing about = this document =85
 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
That is fine as a requirement/usecase and we should = limit the scope to that, than specifying how to solve = it.
 
That makes this approach quite = different from using proxy LSP ping.
You are talking about solution or use case? = :D
 
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
Certainly. But I am struggling between use case and = solution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, = July 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the = draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=B9s a solution with broader scope and better fit for = SPRING as a whole. 
%sam - I believe you say it is use case document = below. Then solution is too premature at this point of time, as we = haven't deliberated on the requirements = either. 

As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use = case but in section #1
      it says the following

      <snip>
       This document describes a solution to this = problem statement and
       illustrates it with use-cases.

       The solution is described for a single IGP = MPLS domain.

       The solution applies to monitoring of LDP = LSP's as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to = certain scenarios and not just
       providing use cases/scenarios. My = understanding was, use case draft should
       document scenarios where it will drive new = requirements. Solutions could
       be covered with existing toolset or defined = newly, depending on the GAP
       analysis. But that should be separate as = there could be more than 1 solution,
       where as this document could just focus on = use cases only.

       If infact this is supposed to be a solution = document, then changing the title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review = the text of section 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with :D
 


       2. w.r.t. Section number #2, the same problem = is being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . What is = being described in this
       section could be done with the proxy = ping(solution wise) where, request could
       be sent to monitor LER i and LER j segment, = from a PMS. Is my understanding
       right? If not, how is it different = here?

[RG] The PMS is able to set up packets which stay = in data plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform = something else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request = message to
   be sent down a LSP or part of an = LSP.
%sam - If it is proposing extensions,  it has = to be solution document  and cannot claim to be use case document. = Also this document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like = proxy-ping to check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS implementation.
%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to = perform validation checks. For liveness detection, BFD is preferred = tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform = validation of data plane to control plane, etc? (I think you agree to = this in the later part of the doc also)
 
b) once PMS detected data plane liveliness and = correctness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and = the monitoring packets stay
   in data plane. Please point me to the text in proxy-ping = offering this feature.
%sam - This you could perform even without proxy = ping. The function you are describing is, how you use lsp ping rather = than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with = its multipath implementation.
- perform ping with right selectors for the path = and use TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in = your draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS = which is not part of MPLS or segment
        domain, there is a serious security aspect, = which needs to considered. I believe
        it applies to sending a request too. Will = you be documenting that aspect?

[RG] That's a valid point. The domain external = system is one option and the team will deal with the security aspects = raised by this option once we are in solution space. We will not analyse = this in depth for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one = could perform that with RFC4379 ping
        with multpath + proxy ping. Could you kindly = differentiate if there is something
        new the solution brings = here?

[RG] The SR OAM author team has provided text how = to monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is = obvious and I missed it). If there are differences to the SR OAM = approach, we'll discuss them.
%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the same.
If you say that each link member has same label = stack, then you could use lsp selectors as defined in RFC4379, in this = case it is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled = link as one interface but cannot discern its link members, then you = could only validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is the requirement here = only for PMS to learn the topology, in the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to = set up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to = perform RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is = that, it performs on demand per segment, which Proxy ping also does, = albeit only for MPLS topology.
The case you are making is that no need of bells = and whistles of RFC4379.
 
Question I have for you is, if data plane packets = are getting dropped and PMS packets going through, for a given LSP or = Segment, how do you know there is a problem? if you know, how do you = figure out where it is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed = prior to a measurement may also be
         done by setting up a label including = all node SIDs along that path
         (if LER1 has Node SID 40 in the = example and it should be passed
         between LER i and LER j, the label = stack is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it = does not involve MPLS OAM
         functionality and it is independent of = ECMP functionalities.  The
         method still is able to monitor all = link combinations of all paths of
         an MPLS domain.  If correct = forwarding along the desired paths has to
         be checked, RFC4739 functionality = should be applied also in this
         case.

         <end snip>

         In the above you mention that it does = not involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. = Could you clarify how could you verify a
         path, if MPLS validation is not done. = More text will help. Also, more
         importantly, the text earlier to the = above says, for valid result, MPLS
         OAM has to be performed for topology = changes etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based = on control plane information.
- if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states = something different, I'll try to reword it.
%sam - The problem I am having is, in the case of = MPLS, for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but = what I feel is, the use case is too much catered to a specific = envisioned solution.
Once you remove solution or suggested enhancements, = hope it should be clear on what is being solved and scope out clear = requirements for a solution.
For solution part, please publish a separate = ID.
 


         7. Last but not the least, how = different is PMS from EMS and NMS?
         Somehow I couldn't find the difference = what PMS could do and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, = which performs MPLS topology specific operations  for a given set = of LSP's. They perform Treetrace and perform ping with multipath. Also = perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that :D
 
cheers
-sam

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




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


= --Apple-Mail=_E0D3212E-7ED5-4CA4-B691-C233B9127BB4-- From nobody Sun Jul 13 01:36:10 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608631B2A01 for ; Sun, 13 Jul 2014 01:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.551 X-Spam-Level: X-Spam-Status: No, score=-14.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-2i8BEVJi-5 for ; Sun, 13 Jul 2014 01:36:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7691B29FA for ; Sun, 13 Jul 2014 01:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=85162; q=dns/txt; s=iport; t=1405240562; x=1406450162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mvy0fnoIh7gePP83INNHscjekNq0Sp4xhP/cvFT2eVw=; b=UzbjNbcASEy2XyBBX4UTq3iwbzArqN3m5a7xTImdfM2y2eJfhvZ4IAxn U9FZFiHKugG6b3sgweynjptKYkNhDWdv2CGqFYnFA+nqGiViKkCjjDkoj jxS3D3huL7U18QODdWCgfZxqg55CbJJaXkQszJKReWt61FbRRlirnPXDT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAIVEwlOtJV2S/2dsb2JhbABPCoJHR1JahDG9BgEJhnBTAYEMFnWEAwEBAQQBAQEXAUwHBAcQAgEIEQEDAQEhAQYHIQYLFAMGCAIEDgUbiBMDEQ2/Kw2HKBeNHoFBEAUsJwQGAQIEA4MkgRYFmQ6CAIFKjD2GFoNEgW8BBxcGHA X-IronPort-AV: E=Sophos;i="5.01,652,1400025600"; d="scan'208,217";a="339716119" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP; 13 Jul 2014 08:35:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6D8Zx1U006581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 13 Jul 2014 08:35:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 13 Jul 2014 03:35:59 -0500 From: "Carlos Pignataro (cpignata)" To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J1ROB+bkF5Eyzu98s3ehKlwAT5ZsQAA/kkXAAExYZAAABnHcAAABc/AAAAUQagAAYD7EAABEWPIAAAOV7gAAAnJwAAADEQIAAAe+dgABQzE2AAACuWIAAAKNRgA== Date: Sun, 13 Jul 2014 08:35:58 +0000 Message-ID: References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> <8A0655C2-99CC-44C3-A287-1E73CD6BA51A@cisco.com> <6B4D46C6-B52A-4B16-906C-EC2684E3A670@gmail.com> In-Reply-To: <6B4D46C6-B52A-4B16-906C-EC2684E3A670@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.206.42] Content-Type: multipart/alternative; boundary="_000_A352426CD45540DBA1C664A5B6B4D959ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/cfCz4yDrbAhMmq1MSPh3ARA7cnQ Cc: "Nobo Akiya \(nobo\)" , "Ruediger.Geib@telekom.de" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "spring@ietf.org" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 08:36:07 -0000 --_000_A352426CD45540DBA1C664A5B6B4D959ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Sam, Please find inline a quick follow-up. On Jul 13, 2014, at 9:18 AM, Sam Aldrin > wrote: Hi Carlos, comments inline. On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) > wrote: Hi, Sam, On Jul 11, 2014, at 6:25 PM, Sam Aldrin > wrote: Hi Carlos, On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) > wrote: Hi, Sam, On Jul 11, 2014, at 12:07 PM, Sam Aldrin > wrote: Carlos, On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) > wrote: Sam, Just to be clear: a use-case document is not a set of abstract generic requ= irements and nothing else. Use case is not requirements to then think of a = solution -- that would be a requirements document. Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is. This document describes the specific case of how to use a specific technolo= gy (spring) to solve a particular problem. The Abstract is pretty clear on = that: Abstract This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. [...] This scenario cannot be decoupled from its actual use case. Well then the introduction says the following The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. ... .. The proposed solution offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of a domains forwarding paths. Thanks for pointing these out. I think you are cherry-picking and extrapola= ting the word "solution" way further than intended, and adding meaning to i= t as if it supports requirements. %s/The solution/The use case/ s/The proposed solution/The presented use case/ You are trivializing what I was eluding to in my earlier emails. If indeed you are not talking about solution, do you think sections 4-7 tal= k about use cases? When I read the document the way it is worded and understood was to PMS sol= ution (sec #2) trying to solve problem in a specific. If you don't believe,= do "%s/PMS/NMS/g" and see. Don't misconstrue that I am saying there is no use case. I did not imply that you said there is no use case. My point is that the "s= olution" is part of the use case itself, and that a use case is not a set o= f requirements -- this use case document explains how the use case works (i= .e., the case of the benefits for OAM of having Source Packet Routing in Ne= tworks). You were asking about removing solutions from the use case -- I am= reacting to that. Otherwise, I might be misunderstanding your point. I am only providing comment, whether to remove or not is upto you, the auth= ors. If you want to keep solution, that is fine too, but that will only delay th= e progression of the document, because, we will be discussing which solutio= n is better and which isn=92t for a given use case. I could see why some of the existing solutions could do some of the tasks, = without the need of enhancement. As you could see from my earlier arguments= , I was commenting on the solution parts, not for use case. I prefer to see the use case be present in a simple and concise way and sol= ution be deferred to solution document. Again, your call :D I wanted to make sure I understood your point, because you always have insi= ghtful and contractive input and feedback. My take: What you call "solution" in the paragraph above is actually part o= f the use case itself. There is no solution outside of and external to the = use case. A simple and concise way of presenting the context of the use case would ma= ke for a very short draft -- see the first two sentences of the Abstract: This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. However the use case is describing how segment based routing enables this O= AM method. To provide more reason for my argument, for ex: why should I care RFC4379 s= olve a specific use case or not? Use case is valid but it could be solved m= ultiple ways. Similarly, I need not solve a use case with PMS, rather I cou= ld do with NMS. I do hope you see my point. These are use cases that get enabled by Source Packet Routing in Networks. = In the context of OAM, new ways of doing network-wide path monitoring are e= nabled. The point of the use case is how it can be done in spring networks = that it cannot in non-spring ones. I agree that additional text on showing how proxy-lsp-ping could support it= can potentially be useful, but not with "remove all solutions". Further, m= aybe the use case can be generalized even more. Again, it is up to you authors what to retain in the document or what to ad= d. We could review accordingly. If there are solutions and proposals to existing solutions in this ID, then= it will lead into solutions discussions, which is what is happening right = now. What I think would be more useful would be to channel the review cycles tow= ards oam uses that get enabled by the spring architecture. That is, * is this a simple remote (proxy?) realization/use for oam in spring networ= ks? * can this use case be generalized to the spring ipv6 dataplane? [I think s= o] * can this use case be used with S-BFD? In addition, this document should add more details about the scenarios of I= Pv6 w.r.t SR, or add specific pointers for the same. Certainly these scenarios need to also be documented. cool thanks Anytime. Thanks, Carlos. -sam Also consider the comments in my earlier emails. As far as S-BFD goes, refe= r to sec 3.4 of S-BFD use case document. Yes, this citations should be good. Thanks, Carlos. -sam Thanks, Carlos. cheers -sam Thanks, Carlos. On Jul 11, 2014, at 11:24 AM, Sam Aldrin > wrote: Hi Rudiger, As I acknowledged in my earlier emails, the question is not about valid use= cases exist or not, rather it is about the document and what the text says= . Document is not clear on just use cases only because it touches various s= olution aspects, which is unnecessary. For example, use cases should not ca= re what RFC4379 can or cannot, that discussion should happen after the requ= irements which gets originated by these use cases. Once you cleanup the document and remove solution specific parts, it should= be ok. We could defer the discussion of what the existing solutions could = and could not do, for solution document and continue discussions of those p= ieces, then. cheers -sam On Jul 11, 2014, at 12:15 AM, > > = wrote: Hi Nobo, hi Sam the use case is to enable monitoring of an MPLS domain without accessing th= e control plane. To do so, a PMS needs MPLS topology awareness, which it ge= ts by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think. Monitoring without control plane access is part of the use case, not part o= f a solution discussion (to say it differently: using the data plane for OA= M purposes is not an option which may be removed). As many SR based OAM fea= tures can be used without OAM specific protocols or functions being added t= o Segment Routing, I think it=92s perfectly ok to formulate the use case as= is. The main requirement is: specify Segment Routing. Then one may add OAM= boxes which apply SR features. RFC4379 could also monitor LSPs, but it requires using the control plane an= d proxy-lsp-ping adds control plane based functionality to RFC4379. It is a= n approach resulting in similar features, but it is control plane based. Th= is is a different use case. If an operator needs to validate that a packet travels a certain path or tr= ace the path a lost packet has taken, then RFC4379 functionality is needed.= It=92s a difference whether RFC4379 is applied only at off peak times or a= fter a data plane only monitoring packet has been lost along one path or wh= ether that has to be done constantly. Regards, Ruediger Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] Gesendet: Donnerstag, 10. Juli 2014 21:46 An: Sam Aldrin Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase Betreff: RE: [spring] Questions Hi Sam, I just wanted to point out the key described behavior, wasn=92t saying anyt= hing about whether this document should be a use-case document or a solutio= n document :) Thanks! -Nobo From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Thursday, July 10, 2014 3:10 PM To: Nobo Akiya (nobo) Cc: Ruediger.Geib@telekom.de; spring; draf= t-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Nobo, Inline for my comments. On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) > wrote: Hi Sam, Just to point out one thing about this document =85 The test packet generated from a PMS/NMS/EMS/network-device can have the co= mplete segment stack on how to traverse the network as well as how to come = back to self without any further signaling, OAM state maintenance on networ= k nodes nor OAM involvement by network nodes. That is fine as a requirement/usecase and we should limit the scope to that= , than specifying how to solve it. That makes this approach quite different from using proxy LSP ping. You are talking about solution or use case? :D This certainly has some pros and cons but can be quite useful as one of the= OAMs (yes plural) used to monitor the network. Certainly. But I am struggling between use case and solution outlined in th= e document. Pick one :D -sam Thanks! -Nobo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Thursday, July 10, 2014 2:13 PM To: Ruediger.Geib@telekom.de Cc: spring; draft-geib-spring-oam-usecase Subject: Re: [spring] Questions Hi Ruediger, Thanks for the quick response. Please find my responses inline. On Thu, Jul 10, 2014 at 7:15 AM, > wrote: Hi Sam, my replies are marked [RG] and added to your text. - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft. - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= ) Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. %sam - I believe you say it is use case document below. Then solution is to= o premature at this point of time, as we haven't deliberated on the require= ments either. As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. Regards, Ruediger Sam Aldrin wrote: I have few questions about this draft. 1. The title is confusing to me. It says OAM use case but in section = #1 it says the following This document describes a solution to this problem statement and illustrates it with use-cases. The solution is described for a single IGP MPLS domain. The solution applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. In fact the draft is describing a solution to certain scenarios and = not just providing use cases/scenarios. My understanding was, use case draft = should document scenarios where it will drive new requirements. Solutions c= ould be covered with existing toolset or defined newly, depending on the = GAP analysis. But that should be separate as there could be more than 1 = solution, where as this document could just focus on use cases only. If infact this is supposed to be a solution document, then changing = the title would be more meaningful. That's my observation. [RG] Thanks. It's a use case document. We'll review the text of section 1. %sam - OK. then I'd like to see any specific solution content removed, that= way we dont have to discuss what other solutions does either or compare wi= th :D 2. w.r.t. Section number #2, the same problem is being solved with "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in thi= s section could be done with the proxy ping(solution wise) where, requ= est could be sent to monitor LER i and LER j segment, from a PMS. Is my unders= tanding right? If not, how is it different here? [RG] The PMS is able to set up packets which stay in data plane and execute= a desired chain of MPLS LSPs. %sam - Execute you mean traverse? or perform something else? [RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to allow a third party to remotely cause an MPLS Echo Request message to be sent down a LSP or part of an LSP. %sam - If it is proposing extensions, it has to be solution document and = cannot claim to be use case document. Also this document is on information = track. [RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds functionality: a) You don't need an additional protocol or functionality like proxy-ping t= o check data plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS imple= mentation. %sam - RFC4379 performs validation of dataplane and also find out lot more = errors. You need additional information to perform validation checks. For l= iveness detection, BFD is preferred tool, atleast in present deployments.So= are you saying, PMS solution is designed for liveness detection and not to= perform validation of data plane to control plane, etc? (I think you agree= to this in the later part of the doc also) b) once PMS detected data plane liveliness and correctness of MPLS topology= by RFC4379, it can continue to execute arbitrary LSP combinations and the monitoring= packets stay in data plane. Please point me to the text in proxy-ping offering this f= eature. %sam - This you could perform even without proxy ping. The function you are= describing is, how you use lsp ping rather than what lsp ping does. Again = I am not talking about non-mpls topology. To answer your question, how you perform. - Perform treetrace with rfc4379 to get topology info - pick any arbitary LSP paths discovered along with its multipath implement= ation. - perform ping with right selectors for the path and use TTL for limiting t= he hop [LER j]. - if you want to perform from LER i to LER j as in your draft, use proxy pi= ng to start from LER i 3. When the response is sent back to PMS which is not part of MPLS = or segment domain, there is a serious security aspect, which needs to consider= ed. I believe it applies to sending a request too. Will you be documenting that a= spect? [RG] That's a valid point. The domain external system is one option and the= team will deal with the security aspects raised by this option once we are= in solution space. We will not analyse this in depth for a use case docume= nt. %sam - nod 4. Sec 3.2 to monitor bundle links, one could perform that with RFC= 4379 ping with multpath + proxy ping. Could you kindly differentiate if there= is something new the solution brings here? [RG] The SR OAM author team has provided text how to monitor a bundled link= in the use case draft. You are a co-author of proxy-lsp. I couldn't find e= xplicit text on how to detect and monitor a bundled link in draft-proxy-lsp= . Please describe how proxy-lsp can be used to monitor a bundled link (sorr= y if this is obvious and I missed it). If there are differences to the SR O= AM approach, we'll discuss them. %sam - The same steps described above could be used if each bundled link me= mber is identified with a unique label. While performing tree trace or ping= with multipath, LER i will respond with DDMAP info for each of the links a= nd the multipath info for the same. If you say that each link member has same label stack, then you could use l= sp selectors as defined in RFC4379, in this case it is local host dest ip a= ddr, to identify each link member. Now if the MPLS forwarding layer sees the bundled link as one interface but= cannot discern its link members, then you could only validate the interfac= e and not its individual members. Same applies in your case too. Cannot see how it is different. 5. sec #5, Is the requirement here only for PMS to learn the topol= ogy, in the case of mixed env? [RG] MPLS topology awareness is the precondition to set up packets with lab= el stacks executing a desired chain of LSPs. If suitable Label/FEC/node rel= ation is known to the PMS, that LSP can be executed from that node on by a = PMS monitoring packet. %sam - So, you are saying that you still need to perform RFC4379 trace or t= reetrace to get topology. I do not think IGP extensions being proposed in S= PRING export any of the info other than label stack. And the proposed PMS solution (not use case) is that, it performs on demand= per segment, which Proxy ping also does, albeit only for MPLS topology. The case you are making is that no need of bells and whistles of RFC4379. Question I have for you is, if data plane packets are getting dropped and P= MS packets going through, for a given LSP or Segment, how do you know there= is a problem? if you know, how do you figure out where it is? At least with RFC4379 and/or proxy ping, you could validate each hop becaus= e of the bells and whistles it carries along with the packet. 6. In sec 3.1, Determining a path to be executed prior to a measurement may also = be done by setting up a label including all node SIDs along that path (if LER1 has Node SID 40 in the example and it should be passed between LER i and LER j, the label stack is 20 - 40 - 30 - 10). T= he advantage of this method is, that it does not involve MPLS OAM functionality and it is independent of ECMP functionalities. The method still is able to monitor all link combinations of all paths= of an MPLS domain. If correct forwarding along the desired paths has= to be checked, RFC4739 functionality should be applied also in this case. In the above you mention that it does not involve MPLS OAM. But la= ter you say, RFC4379 functionality could be used. Could you clarify how could y= ou verify a path, if MPLS validation is not done. More text will help. Also, m= ore importantly, the text earlier to the above says, for valid result,= MPLS OAM has to be performed for topology changes etc. If so, it contra= dicts here. [RG] The text should say that - without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information. - if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied. If you understand this statement and the text in the draft states something= different, I'll try to reword it. %sam - The problem I am having is, in the case of MPLS, for OAM, you have t= o validate the lsp. I definitely see a specific need for SPRING, but what I feel is, the use ca= se is too much catered to a specific envisioned solution. Once you remove solution or suggested enhancements, hope it should be clear= on what is being solved and scope out clear requirements for a solution. For solution part, please publish a separate ID. 7. Last but not the least, how different is PMS from EMS and NMS? Somehow I couldn't find the difference what PMS could do and NMS/EMS couldn't. [RG] I've never heard of an EMS/NMS which is MPLS topology aware and uses t= his topology awareness to create data plane packets executing LSP combinati= ons as desired by an operator. Had this feature been commercially available= , the company I work for wouldn't have been developing a PMS. %sam - There are tools which are part of NMS/OSS, which performs MPLS topol= ogy specific operations for a given set of LSP's. They perform Treetrace a= nd perform ping with multipath. Also perform LSP specific validation by cra= fting packets with data available with treetrace and ping with multipath. Y= ou could automate the workflow without the need for OSS/PMS, by using probe= technology. Will not say beyond that :D cheers -sam _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_A352426CD45540DBA1C664A5B6B4D959ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Sam,

Please find inline a quick follow-up.

On Jul 13, 2014, at 9:18 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Carlos,

comments inline.
On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Hi, Sam,

On Jul 11, 2014, at 6:25 PM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract generic= requirements and nothing else. Use case is not requirements to then think = of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to docum= ent to capture use cases, if that is what the authors intent for this docum= ent is.

This document describes the specific case of how to use a specific tec= hnology (spring) to solve a particular problem. The Abstract is pretty clea= r on that:

Abstract

   This document describes features and a use case of a path= monitoring
   system.  Segment based routing enables a scalable an= d simple method
   to monitor data plane liveliness of the complete set of p= aths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS domain.


The solution applies to monitoring of LDP LSP's as well as to
   monitoring of Segment Routed LSP's.
...
..
Th=
e proposed solution offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding paths.

<snip>



Thanks for pointing these out. I think you are cherry-picking and extr= apolating the word "solution" way further than intended, and addi= ng meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/

You are trivializing what I was eluding to in my earlier emails.
If indeed you are not talking about solution, do you think sections 4-= 7 talk about use cases?
When I read the document the way it is worded and understood was to PM= S solution (sec #2) trying to solve problem in a specific. If you don't bel= ieve, do "%s/PMS/NMS/g" and see.

Don't misconstrue that I am saying there is no use case.


I did not imply that you said there is no use case. My point is that t= he "solution" is part of the use case itself, and that a use case= is not a set of requirements -- this use case document explains how the us= e case works (i.e., the case of the benefits for OAM of having Source Packet Routing in Networks). You were asking abou= t removing solutions from the use case -- I am reacting to that. Otherwise,= I might be misunderstanding your point.
I am only providing comment, whether to remove or not is upto you, the auth= ors.
If you want to keep solution, that is fine too, but that will only del= ay the progression of the document, because, we will be discussing which so= lution is better and which isn=92t for a given use case.
I could see why some of the existing solutions could do some of the ta= sks, without the need of enhancement. As you could see from my earlier argu= ments, I was commenting on the solution parts, not for use case.
I prefer to see the use case be present in a simple and concise way an= d solution be deferred to solution document. Again, your call :D


I wanted to make sure I understood your point, because you always have= insightful and contractive input and feedback.

My take: What you call "solution" in the paragraph above is = actually part of the use case itself. There is no solution outside of and e= xternal to the use case. 

A simple and concise way of presenting the context of the use case wou= ld make for a very short draft -- see the first two sentences of the Abstra= ct:

   This document describes features and a use case of a path= monitoring
   system.  Segment based routing enables a scalable an= d simple method
   to monitor data plane liveliness of the complete set of p= aths
   belonging to a single domain.

However the use case is describing how segment based routing enables t= his OAM method.

To provide more reason for my argument, for ex: why should I care RFC4= 379 solve a specific use case or not? Use case is valid but it could be sol= ved multiple ways. Similarly, I need not solve a use case with PMS, rather = I could do with NMS. I do hope you see my point.


These are use cases that get enabled by Source Packet Routing in Netwo= rks. In the context of OAM, new ways of doing network-wide path monitoring = are enabled. The point of the use case is how it can be done in spring netw= orks that it cannot in non-spring ones.






I agree that additional text on showing how proxy-lsp-ping could suppo= rt it can potentially be useful, but not with "remove all solutions&qu= ot;. Further, maybe the use case can be generalized even more.


Again, it is up to you authors what to retain in the document or what = to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this ID,= then it will lead into solutions discussions, which is what is happening r= ight now.


What I think would be more useful would be to channel the review cycle= s towards oam uses that get enabled by the spring architecture. That is,
* is this a simple remote (proxy?) realization/use for oam in spring n= etworks?
* can this use case be generalized to the spring ipv6 dataplane? [I th= ink so]
* can this use case be used with S-BFD?

In addition, this document should add more details about the scenarios of I= Pv6 w.r.t SR, or add specific pointers for the same.

Certainly these scenarios need to also be documented.
cool

thanks

Anytime.

Thanks,

Carlos.


-sam

Also consider the comments in my earlier emails. As far as S-BFD goes,= refer to sec 3.4 of S-BFD use case document.


Yes, this citations should be good.

Thanks,

Carlos.

-sam


Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about vali= d use cases exist or not, rather it is about the document and what the text= says. Document is not clear on just use cases only because it touches vari= ous solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that di= scussion should happen after the requirements which gets originated by thes= e use cases.

Once you cleanup the document and remove solution specific parts, it s= hould be ok. We could defer the discussion of what the existing solutions c= ould and could not do, for solution document and continue discussions of th= ose pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> wrote:

Hi Nobo, hi Sam
 
the use case is to enable monitoring of an = MPLS domain without accessing the control plane. To do so, a PMS needs MPLS= topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, witho= ut going into too many details, I think.
 
Monitoring without control plane access is = part of the use case, not part of a solution discussion (to say it differen= tly: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features can = be used without OAM specific protocols or functions being added to Segment = Routing, I think it=92s perfectly ok to formulate the use case as is. The m= ain requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR features.
 
RFC4379 could also monitor LSPs, but it req= uires using the control plane and proxy-lsp-ping adds control plane based f= unctionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a di= fferent use case.
 
If an operator needs to validate that a pac= ket travels a certain path or trace the path a lost packet has taken, then = RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after a = data plane only monitoring packet has been lost along one path or whether t= hat has to be done constantly.
 
Regards,
 
Ruediger
 
Von:=  Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerst= ag, 10. Juli 2014 21:46
An: Sam Aldrin
Cc: Geib, R=FCdige= r; spring; draft-geib-spring-oam-usecase
Betreff: RE: [spri= ng] Questions
 
Hi Sam,
 
I just wanted to point out the key describe= d behavior, wasn=92t saying anything about whether this document should be = a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: = Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, Ju= ly 10, 2014 3:10 PM
To: Nobo Akiya (no= bo)
Cc: Ruediger.Geib@telekom.de; spring; draft-geib-spring-oam-usecase=
Subject: Re: [spri= ng] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) &l= t;nobo@cisco.com> wrote:
Hi Sam,
 
Just to point out one thing about this docu= ment =85
 
The test packet generated from a PMS/NMS/EM= S/network-device can have the complete segment stack on how to traverse the= network as well as how to come back to self without any further signaling, OAM state maintenance on network no= des nor OAM involvement by network nodes.<= /o:p>
That is fine as a requirement/usecase and we should li= mit the scope to that, than specifying how to solve it.
 
That makes this approach quite different fr= om using proxy LSP ping.
You are talking about solution or use case? :D
 
 
This certainly has some pros and cons but c= an be quite useful as one of the OAMs (yes plural) used to monitor the netw= ork.
Certainly. But I am struggling between use case and so= lution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: = spring [mailto:spring-bounces= @ietf.org] On Behalf Of Sam Aldrin=
Sent: Thursday, Ju= ly 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; draft-= geib-spring-oam-usecase
Subject: Re: [spri= ng] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my response= s inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for e= very SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and ICMPv6= )

Based on that, it=B9s a solution with broader scope and better fit for SPRI= NG as a whole. 
%sam - I believe you say it is use case document below= . Then solution is too premature at this point of time, as we haven't delib= erated on the requirements either. 

As you write, SR based OAM partially offers similar functions as proxy-lsp.= Without requiring the additional messages and LER/LSR processing introduce= d by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use case = but in section #1
      it says the following

      <snip>
       This document describes a solution to this probl= em statement and
       illustrates it with use-cases.

       The solution is described for a single IGP MPLS = domain.

       The solution applies to monitoring of LDP LSP's = as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to ce= rtain scenarios and not just
       providing use cases/scenarios. My understanding = was, use case draft should
       document scenarios where it will drive new requi= rements. Solutions could
       be covered with existing toolset or defined newl= y, depending on the GAP
       analysis. But that should be separate as there c= ould be more than 1 solution,
       where as this document could just focus on use c= ases only.

       If infact this is supposed to be a solution docu= ment, then changing the title
       would be more meaningful. That's my observation.=

[RG] Thanks. It's a use case document. We'll review th= e text of section 1.
%sam - OK. then I'd like to see any specific solution = content removed, that way we dont have to discuss what other solutions does= either or compare with :D
 


       2. w.r.t. Section number #2, the same problem is= being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . = What is being described in this
       section could be done with the proxy ping(soluti= on wise) where, request could
       be sent to monitor LER i and LER j segment, from= a PMS. Is my understanding
       right? If not, how is it different here?

[RG] The PMS is able to set up packets which stay in d= ata plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform something= else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS ping= [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request mes= sage to
   be sent down a LSP or part of an LSP.
%sam - If it is proposing extensions,  it has to = be solution document  and cannot claim to be use case document. Also t= his document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 fun= ctionality on any LSP, you could either use the PMS or proxy-ping. The PMS = however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like proxy-ping t= o check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom operates a= PMS implementation.
%sam - RFC4379 performs validation of dataplane and al= so find out lot more errors. You need additional information to perform val= idation checks. For liveness detection, BFD is preferred tool, atleast in p= resent deployments.So are you saying, PMS solution is designed for liveness detection and not to perform validat= ion of data plane to control plane, etc? (I think you agree to this in the = later part of the doc also)
 
b) once PMS detected data plane liveliness and correct= ness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
   in data plane. Please point me to the text in proxy-ping offer= ing this feature.
%sam - This you could perform even without proxy ping.= The function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology.
To answer your question, how you perform.
- Perform treetrace with rfc4379 to get topology info<= o:p>
- pick any arbitary LSP paths discovered along with it= s multipath implementation.
- perform ping with right selectors for the path and u= se TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in you= r draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS which = is not part of MPLS or segment
        domain, there is a serious security aspect, whi= ch needs to considered. I believe
        it applies to sending a request too. Will you b= e documenting that aspect?

[RG] That's a valid point. The domain external system = is one option and the team will deal with the security aspects raised by th= is option once we are in solution space. We will not analyse this in depth = for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one could p= erform that with RFC4379 ping
        with multpath + proxy ping. Could you kindl= y differentiate if there is something
        new the solution brings here?=

[RG] The SR OAM author team has provided text how to m= onitor a bundled link in the use case draft. You are a co-author of proxy-l= sp. I couldn't find explicit text on how to detect and monitor a bundled li= nk in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is obvi= ous and I missed it). If there are differences to the SR OAM approach, we'l= l discuss them.
%sam - The same steps described above could be used if= each bundled link member is identified with a unique label. While performi= ng tree trace or ping with multipath, LER i will respond with DDMAP info fo= r each of the links and the multipath info for the same.
If you say that each link member has same label stack,= then you could use lsp selectors as defined in RFC4379, in this case it is= local host dest ip addr, to identify each link member.
Now if the MPLS forwarding layer sees the bundled link= as one interface but cannot discern its link members, then you could only = validate the interface and not its individual members.
Same applies in your case too. Cannot see how it is di= fferent.
 



         5. sec #5, Is the requirement here only f= or PMS to learn the topology, in the
            case of mixed env?

[RG] MPLS topology awareness is the precondition to se= t up packets with label stacks executing a desired chain of LSPs. If suitab= le Label/FEC/node relation is known to the PMS, that LSP can be executed fr= om that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to perfo= rm RFC4379 trace or treetrace to get topology. I do not think IGP extension= s being proposed in SPRING export any of the info other than label stack.&n= bsp;
And the proposed PMS solution (not use case) is that, = it performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology.
The case you are making is that no need of bells and w= histles of RFC4379.
 
Question I have for you is, if data plane packets are = getting dropped and PMS packets going through, for a given LSP or Segment, = how do you know there is a problem? if you know, how do you figure out wher= e it is?
At least with RFC4379 and/or proxy ping, you could val= idate each hop because of the bells and whistles it carries along with the = packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed prior t= o a measurement may also be
         done by setting up a label including all = node SIDs along that path
         (if LER1 has Node SID 40 in the example a= nd it should be passed
         between LER i and LER j, the label stack = is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it does= not involve MPLS OAM
         functionality and it is independent of EC= MP functionalities.  The
         method still is able to monitor all link = combinations of all paths of
         an MPLS domain.  If correct forwardi= ng along the desired paths has to
         be checked, RFC4739 functionality should = be applied also in this
         case.

         <end snip>

         In the above you mention that it does not= involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. Coul= d you clarify how could you verify a
         path, if MPLS validation is not done. Mor= e text will help. Also, more
         importantly, the text earlier to the abov= e says, for valid result, MPLS
         OAM has to be performed for topology chan= ges etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based on= control plane information.
- if the operator wants to make sure that data plane corresponds to control= plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states something= different, I'll try to reword it.
%sam - The problem I am having is, in the case of MPLS= , for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but what = I feel is, the use case is too much catered to a specific envisioned soluti= on.
Once you remove solution or suggested enhancements, ho= pe it should be clear on what is being solved and scope out clear requireme= nts for a solution.
For solution part, please publish a separate ID.<= /o:p>
 


         7. Last but not the least, how different = is PMS from EMS and NMS?
         Somehow I couldn't find the difference wh= at PMS could do and
         NMS/EMS couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topo= logy aware and uses this topology awareness to create data plane packets ex= ecuting LSP combinations as desired by an operator. Had this feature been c= ommercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, whic= h performs MPLS topology specific operations  for a given set of LSP's= . They perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with treetrace and ping with multipath. You could auto= mate the workflow without the need for OSS/PMS, by using probe technology. = Will not say beyond that :D
 
cheers
-sam

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring




_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.o= rg/mailman/listinfo/spring

--_000_A352426CD45540DBA1C664A5B6B4D959ciscocom_-- From nobody Mon Jul 14 02:07:51 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8501A0070 for ; Mon, 14 Jul 2014 02:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSvI-IhyA5vY for ; Mon, 14 Jul 2014 02:07:45 -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 AF4B31A0063 for ; Mon, 14 Jul 2014 02:07:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE01730; Mon, 14 Jul 2014 09:07:43 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Jul 2014 10:07:41 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 14 Jul 2014 17:07:39 +0800 From: Qin Wu To: "Nobo Akiya (nobo)" , Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7JhndME/roR0Kh13/N0Tpo0QAT5ZsQAA/kkXD//77CAIAADOQA//naTZA= Date: Mon, 14 Jul 2014 09:07:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84582A0Enkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/rB2VAT2QXveWZbfmU3OgQLfuU3o Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 09:07:50 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84582A0Enkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmVyeSBnb29kIHBvaW50LCBzaW5jZSBzZWdtZW50IHJvdXRpbmcgZG9lc27igJl0IHJlcXVpcmUg ZWFjaCBuZXR3b3JrIG5vZGUgaW4gdGhlIHBhdGggdG8gbWFpbnRhaW4gc3RhdGUgYW5kIG9ubHkg aW5ncmVzcyBub2RlIG1haW50YWlucyB0aGUgc3RhdGUgd2hpbGUNClByb3h5LWxzcC1waW5nIHJl cXVpcmUgZWFjaCBuZXR3b3JrIG5vZGUgaW4gdGhlIHJldHVybiBwYXRoIHRvIG1haW50YWluIHRo ZSBzdGF0ZS4NCldoeSBhcHBseSBQcm94eS1sc3AtcGluZyB0byBzcHJpbmcgT0FNPw0KDQpSZWdh cmRzIQ0KLVFpbg0K5Y+R5Lu25Lq6OiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZ10g5Luj6KGoIE5vYm8gQWtpeWEgKG5vYm8pDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyI MTHml6UgMzowMA0K5pS25Lu25Lq6OiBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVrb20u ZGUNCuaKhOmAgTogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0K5Li76aKY OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIFNhbSwNCg0KSnVzdCB0byBwb2ludCBvdXQg b25lIHRoaW5nIGFib3V0IHRoaXMgZG9jdW1lbnQg4oCmDQoNClRoZSB0ZXN0IHBhY2tldCBnZW5l cmF0ZWQgZnJvbSBhIFBNUy9OTVMvRU1TL25ldHdvcmstZGV2aWNlIGNhbiBoYXZlIHRoZSBjb21w bGV0ZSBzZWdtZW50IHN0YWNrIG9uIGhvdyB0byB0cmF2ZXJzZSB0aGUgbmV0d29yayBhcyB3ZWxs IGFzIGhvdyB0byBjb21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBmdXJ0aGVyIHNpZ25hbGlu ZywgT0FNIHN0YXRlIG1haW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMgbm9yIE9BTSBpbnZvbHZl bWVudCBieSBuZXR3b3JrIG5vZGVzLg0KDQpUaGF0IG1ha2VzIHRoaXMgYXBwcm9hY2ggcXVpdGUg ZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkgTFNQIHBpbmcuDQoNClRoaXMgY2VydGFpbmx5IGhh cyBzb21lIHByb3MgYW5kIGNvbnMgYnV0IGNhbiBiZSBxdWl0ZSB1c2VmdWwgYXMgb25lIG9mIHRo ZSBPQU1zICh5ZXMgcGx1cmFsKSB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQoNClRoYW5r cyENCg0KLU5vYm8NCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBTYW0gQWxkcmluDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAx NCAyOjEzIFBNDQpUbzogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5H ZWliQHRlbGVrb20uZGU+DQpDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2Fz ZQ0KU3ViamVjdDogUmU6IFtzcHJpbmddIFF1ZXN0aW9ucw0KDQpIaSBSdWVkaWdlciwNCg0KVGhh bmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxp bmUuDQoNCk9uIFRodSwgSnVsIDEwLCAyMDE0IGF0IDc6MTUgQU0sIDxSdWVkaWdlci5HZWliQHRl bGVrb20uZGU8bWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4+IHdyb3RlOg0KSGkgU2Ft LA0KDQpteSByZXBsaWVzIGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRkZWQgdG8geW91ciB0ZXh0Lg0K DQotIFByb3h5LWxzcC1waW5nIGlzIE1QTFMgb25seSwgd2hpbGUgdGhlIFBNUyBhcmNoaXRlY3R1 cmUgaXMgaW50ZW5kZWQgZm9yIGV2ZXJ5IFNSIGRhdGEgcGxhbmUgKE1QTFMgKyBJUHY2KS4gV2Un bGwgY2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC4NCi0gUHJveHktbHNwLXBpbmcgaXMgZm9yIE1Q TFMgTFNQIFBpbmcgKFJGQyA0Mzc5IC8gUkZDIDY0MjQpLCB3aGlsZSBvdXIgdXNlIGNhc2UgY2Fu IHVzZSBhbnkgT0FNIChpbiBwYXJ0aWN1bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9yIEJGRCwg YW5kIElDTVB2NikNCg0KQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3aXRoIGJyb2Fk ZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yIFNQUklORyBhcyBhIHdob2xlLg0KJXNhbSAtIEkg YmVsaWV2ZSB5b3Ugc2F5IGl0IGlzIHVzZSBjYXNlIGRvY3VtZW50IGJlbG93LiBUaGVuIHNvbHV0 aW9uIGlzIHRvbyBwcmVtYXR1cmUgYXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyB3ZSBoYXZlbid0 IGRlbGliZXJhdGVkIG9uIHRoZSByZXF1aXJlbWVudHMgZWl0aGVyLg0KDQpBcyB5b3Ugd3JpdGUs IFNSIGJhc2VkIE9BTSBwYXJ0aWFsbHkgb2ZmZXJzIHNpbWlsYXIgZnVuY3Rpb25zIGFzIHByb3h5 LWxzcC4gV2l0aG91dCByZXF1aXJpbmcgdGhlIGFkZGl0aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9M U1IgcHJvY2Vzc2luZyBpbnRyb2R1Y2VkIGJ5IHByb3h5LWxzcC4NCg0KUmVnYXJkcywNCg0KUnVl ZGlnZXINCg0KDQogICAgICBTYW0gQWxkcmluIHdyb3RlOg0KDQogICAgICBJIGhhdmUgZmV3IHF1 ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Lg0KDQogICAgICAxLiBUaGUgdGl0bGUgaXMgY29uZnVz aW5nIHRvIG1lLiBJdCBzYXlzIE9BTSB1c2UgY2FzZSBidXQgaW4gc2VjdGlvbiAjMQ0KICAgICAg aXQgc2F5cyB0aGUgZm9sbG93aW5nDQoNCiAgICAgIDxzbmlwPg0KICAgICAgIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGEgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIHN0YXRlbWVudCBhbmQNCiAg ICAgICBpbGx1c3RyYXRlcyBpdCB3aXRoIHVzZS1jYXNlcy4NCg0KICAgICAgIFRoZSBzb2x1dGlv biBpcyBkZXNjcmliZWQgZm9yIGEgc2luZ2xlIElHUCBNUExTIGRvbWFpbi4NCg0KICAgICAgIFRo ZSBzb2x1dGlvbiBhcHBsaWVzIHRvIG1vbml0b3Jpbmcgb2YgTERQIExTUCdzIGFzIHdlbGwgYXMg dG8NCiAgICAgICBtb25pdG9yaW5nIG9mIFNlZ21lbnQgUm91dGVkIExTUCdzLg0KICAgICAgPGVu ZCBzbmlwPg0KDQogICAgICAgSW4gZmFjdCB0aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNvbHV0 aW9uIHRvIGNlcnRhaW4gc2NlbmFyaW9zIGFuZCBub3QganVzdA0KICAgICAgIHByb3ZpZGluZyB1 c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNhc2UgZHJhZnQg c2hvdWxkDQogICAgICAgZG9jdW1lbnQgc2NlbmFyaW9zIHdoZXJlIGl0IHdpbGwgZHJpdmUgbmV3 IHJlcXVpcmVtZW50cy4gU29sdXRpb25zIGNvdWxkDQogICAgICAgYmUgY292ZXJlZCB3aXRoIGV4 aXN0aW5nIHRvb2xzZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5nIG9uIHRoZSBHQVANCiAg ICAgICBhbmFseXNpcy4gQnV0IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxk IGJlIG1vcmUgdGhhbiAxIHNvbHV0aW9uLA0KICAgICAgIHdoZXJlIGFzIHRoaXMgZG9jdW1lbnQg Y291bGQganVzdCBmb2N1cyBvbiB1c2UgY2FzZXMgb25seS4NCg0KICAgICAgIElmIGluZmFjdCB0 aGlzIGlzIHN1cHBvc2VkIHRvIGJlIGEgc29sdXRpb24gZG9jdW1lbnQsIHRoZW4gY2hhbmdpbmcg dGhlIHRpdGxlDQogICAgICAgd291bGQgYmUgbW9yZSBtZWFuaW5nZnVsLiBUaGF0J3MgbXkgb2Jz ZXJ2YXRpb24uDQpbUkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCBy ZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLg0KJXNhbSAtIE9LLiB0aGVuIEknZCBsaWtlIHRv IHNlZSBhbnkgc3BlY2lmaWMgc29sdXRpb24gY29udGVudCByZW1vdmVkLCB0aGF0IHdheSB3ZSBk b250IGhhdmUgdG8gZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2VzIGVpdGhlciBvciBj b21wYXJlIHdpdGggOkQNCg0KDQogICAgICAgMi4gdy5yLnQuIFNlY3Rpb24gbnVtYmVyICMyLCB0 aGUgc2FtZSBwcm9ibGVtIGlzIGJlaW5nIHNvbHZlZCB3aXRoDQogICAgICAgImRyYWZ0LWlldGYt bXBscy1wcm94eS1sc3AtcGluZy0wMiIgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGlz DQogICAgICAgc2VjdGlvbiBjb3VsZCBiZSBkb25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRp b24gd2lzZSkgd2hlcmUsIHJlcXVlc3QgY291bGQNCiAgICAgICBiZSBzZW50IHRvIG1vbml0b3Ig TEVSIGkgYW5kIExFUiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3RhbmRpbmcN CiAgICAgICByaWdodD8gSWYgbm90LCBob3cgaXMgaXQgZGlmZmVyZW50IGhlcmU/DQpbUkddIFRo ZSBQTVMgaXMgYWJsZSB0byBzZXQgdXAgcGFja2V0cyB3aGljaCBzdGF5IGluIGRhdGEgcGxhbmUg YW5kIGV4ZWN1dGUgYSBkZXNpcmVkDQogICAgIGNoYWluIG9mIE1QTFMgTFNQcy4NCiVzYW0gLSBF eGVjdXRlIHlvdSBtZWFuIHRyYXZlcnNlPyBvciBwZXJmb3JtIHNvbWV0aGluZyBlbHNlPw0KDQpb UkddIFByb3h5LWxzcCBzYXlzOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgcHJvdG9jb2wgZXh0ZW5z aW9ucyB0byBNUExTIHBpbmcgW1JGQzQzNzldIHRvDQogICBhbGxvdyBhIHRoaXJkIHBhcnR5IHRv IHJlbW90ZWx5IGNhdXNlIGFuIE1QTFMgRWNobyBSZXF1ZXN0IG1lc3NhZ2UgdG8NCiAgIGJlIHNl bnQgZG93biBhIExTUCBvciBwYXJ0IG9mIGFuIExTUC4NCiVzYW0gLSBJZiBpdCBpcyBwcm9wb3Np bmcgZXh0ZW5zaW9ucywgIGl0IGhhcyB0byBiZSBzb2x1dGlvbiBkb2N1bWVudCAgYW5kIGNhbm5v dCBjbGFpbSB0byBiZSB1c2UgY2FzZSBkb2N1bWVudC4gQWxzbyB0aGlzIGRvY3VtZW50IGlzIG9u IGluZm9ybWF0aW9uIHRyYWNrLg0KDQpbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5 b3UnZCBsaWtlIHRvIHJlbW90ZWx5IGV4ZWN1dGUgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IG9uIGFu eSBMU1AsIHlvdSBjb3VsZCBlaXRoZXIgdXNlIHRoZSBQTVMgb3IgcHJveHktcGluZy4gVGhlIFBN UyBob3dldmVyIHNpbXBsaWZpZXMgYW5kIGFkZHMNCmZ1bmN0aW9uYWxpdHk6DQphKSBZb3UgZG9u J3QgbmVlZCBhbiBhZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlrZSBwcm94 eS1waW5nIHRvIGNoZWNrIGRhdGENCiAgIHBsYW5lIGxpdmVsaW5lc3MsIFJGQzQzNzkgaXMgZmlu ZS4gRGV1dHNjaGUgVGVsZWtvbSBvcGVyYXRlcyBhIFBNUyBpbXBsZW1lbnRhdGlvbi4NCiVzYW0g LSBSRkM0Mzc5IHBlcmZvcm1zIHZhbGlkYXRpb24gb2YgZGF0YXBsYW5lIGFuZCBhbHNvIGZpbmQg b3V0IGxvdCBtb3JlIGVycm9ycy4gWW91IG5lZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBw ZXJmb3JtIHZhbGlkYXRpb24gY2hlY2tzLiBGb3IgbGl2ZW5lc3MgZGV0ZWN0aW9uLCBCRkQgaXMg cHJlZmVycmVkIHRvb2wsIGF0bGVhc3QgaW4gcHJlc2VudCBkZXBsb3ltZW50cy5TbyBhcmUgeW91 IHNheWluZywgUE1TIHNvbHV0aW9uIGlzIGRlc2lnbmVkIGZvciBsaXZlbmVzcyBkZXRlY3Rpb24g YW5kIG5vdCB0byBwZXJmb3JtIHZhbGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0byBjb250cm9sIHBs YW5lLCBldGM/IChJIHRoaW5rIHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9m IHRoZSBkb2MgYWxzbykNCg0KYikgb25jZSBQTVMgZGV0ZWN0ZWQgZGF0YSBwbGFuZSBsaXZlbGlu ZXNzIGFuZCBjb3JyZWN0bmVzcyBvZiBNUExTIHRvcG9sb2d5IGJ5IFJGQzQzNzksDQogICBpdCBj YW4gY29udGludWUgdG8gZXhlY3V0ZSBhcmJpdHJhcnkgTFNQIGNvbWJpbmF0aW9ucyBhbmQgdGhl IG1vbml0b3JpbmcgcGFja2V0cyBzdGF5DQogICBpbiBkYXRhIHBsYW5lLiBQbGVhc2UgcG9pbnQg bWUgdG8gdGhlIHRleHQgaW4gcHJveHktcGluZyBvZmZlcmluZyB0aGlzIGZlYXR1cmUuDQolc2Ft IC0gVGhpcyB5b3UgY291bGQgcGVyZm9ybSBldmVuIHdpdGhvdXQgcHJveHkgcGluZy4gVGhlIGZ1 bmN0aW9uIHlvdSBhcmUgZGVzY3JpYmluZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVy IHRoYW4gd2hhdCBsc3AgcGluZyBkb2VzLiBBZ2FpbiBJIGFtIG5vdCB0YWxraW5nIGFib3V0IG5v bi1tcGxzIHRvcG9sb2d5Lg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9y bS4NCi0gUGVyZm9ybSB0cmVldHJhY2Ugd2l0aCByZmM0Mzc5IHRvIGdldCB0b3BvbG9neSBpbmZv DQotIHBpY2sgYW55IGFyYml0YXJ5IExTUCBwYXRocyBkaXNjb3ZlcmVkIGFsb25nIHdpdGggaXRz IG11bHRpcGF0aCBpbXBsZW1lbnRhdGlvbi4NCi0gcGVyZm9ybSBwaW5nIHdpdGggcmlnaHQgc2Vs ZWN0b3JzIGZvciB0aGUgcGF0aCBhbmQgdXNlIFRUTCBmb3IgbGltaXRpbmcgdGhlIGhvcCBbTEVS IGpdLg0KLSBpZiB5b3Ugd2FudCB0byBwZXJmb3JtIGZyb20gTEVSIGkgdG8gTEVSIGogYXMgaW4g eW91ciBkcmFmdCwgdXNlIHByb3h5IHBpbmcgdG8gc3RhcnQgZnJvbSBMRVIgaQ0KDQogICAgICAg IDMuIFdoZW4gdGhlIHJlc3BvbnNlIGlzIHNlbnQgYmFjayB0byBQTVMgd2hpY2ggaXMgbm90IHBh cnQgb2YgTVBMUyBvciBzZWdtZW50DQogICAgICAgIGRvbWFpbiwgdGhlcmUgaXMgYSBzZXJpb3Vz IHNlY3VyaXR5IGFzcGVjdCwgd2hpY2ggbmVlZHMgdG8gY29uc2lkZXJlZC4gSSBiZWxpZXZlDQog ICAgICAgIGl0IGFwcGxpZXMgdG8gc2VuZGluZyBhIHJlcXVlc3QgdG9vLiBXaWxsIHlvdSBiZSBk b2N1bWVudGluZyB0aGF0IGFzcGVjdD8NCltSR10gVGhhdCdzIGEgdmFsaWQgcG9pbnQuIFRoZSBk b21haW4gZXh0ZXJuYWwgc3lzdGVtIGlzIG9uZSBvcHRpb24gYW5kIHRoZSB0ZWFtIHdpbGwgZGVh bCB3aXRoIHRoZSBzZWN1cml0eSBhc3BlY3RzIHJhaXNlZCBieSB0aGlzIG9wdGlvbiBvbmNlIHdl IGFyZSBpbiBzb2x1dGlvbiBzcGFjZS4gV2Ugd2lsbCBub3QgYW5hbHlzZSB0aGlzIGluIGRlcHRo IGZvciBhIHVzZSBjYXNlIGRvY3VtZW50Lg0KJXNhbSAtIG5vZA0KDQogICAgICAgIDQuIFNlYyAz LjIgdG8gbW9uaXRvciBidW5kbGUgbGlua3MsIG9uZSBjb3VsZCBwZXJmb3JtIHRoYXQgd2l0aCBS RkM0Mzc5IHBpbmcNCiAgICAgICAgd2l0aCBtdWx0cGF0aCArIHByb3h5IHBpbmcuIENvdWxkIHlv dSBraW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmcNCiAgICAgICAgbmV3 IHRoZSBzb2x1dGlvbiBicmluZ3MgaGVyZT8NCltSR10gVGhlIFNSIE9BTSBhdXRob3IgdGVhbSBo YXMgcHJvdmlkZWQgdGV4dCBob3cgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbiB0aGUgdXNl IGNhc2UgZHJhZnQuIFlvdSBhcmUgYSBjby1hdXRob3Igb2YgcHJveHktbHNwLiBJIGNvdWxkbid0 IGZpbmQgZXhwbGljaXQgdGV4dCBvbiBob3cgdG8gZGV0ZWN0IGFuZCBtb25pdG9yIGEgYnVuZGxl ZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhvdyBwcm94eS1sc3Ag Y2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkgaWYgdGhpcyBpcyBv YnZpb3VzIGFuZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyB0byB0aGUg U1IgT0FNIGFwcHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uDQolc2FtIC0gVGhlIHNhbWUgc3Rl cHMgZGVzY3JpYmVkIGFib3ZlIGNvdWxkIGJlIHVzZWQgaWYgZWFjaCBidW5kbGVkIGxpbmsgbWVt YmVyIGlzIGlkZW50aWZpZWQgd2l0aCBhIHVuaXF1ZSBsYWJlbC4gV2hpbGUgcGVyZm9ybWluZyB0 cmVlIHRyYWNlIG9yIHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRo IERETUFQIGluZm8gZm9yIGVhY2ggb2YgdGhlIGxpbmtzIGFuZCB0aGUgbXVsdGlwYXRoIGluZm8g Zm9yIHRoZSBzYW1lLg0KSWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUg bGFiZWwgc3RhY2ssIHRoZW4geW91IGNvdWxkIHVzZSBsc3Agc2VsZWN0b3JzIGFzIGRlZmluZWQg aW4gUkZDNDM3OSwgaW4gdGhpcyBjYXNlIGl0IGlzIGxvY2FsIGhvc3QgZGVzdCBpcCBhZGRyLCB0 byBpZGVudGlmeSBlYWNoIGxpbmsgbWVtYmVyLg0KTm93IGlmIHRoZSBNUExTIGZvcndhcmRpbmcg bGF5ZXIgc2VlcyB0aGUgYnVuZGxlZCBsaW5rIGFzIG9uZSBpbnRlcmZhY2UgYnV0IGNhbm5vdCBk aXNjZXJuIGl0cyBsaW5rIG1lbWJlcnMsIHRoZW4geW91IGNvdWxkIG9ubHkgdmFsaWRhdGUgdGhl IGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRpdmlkdWFsIG1lbWJlcnMuDQpTYW1lIGFwcGxpZXMg aW4geW91ciBjYXNlIHRvby4gQ2Fubm90IHNlZSBob3cgaXQgaXMgZGlmZmVyZW50Lg0KDQoNCg0K ICAgICAgICAgNS4gc2VjICM1LCBJcyB0aGUgcmVxdWlyZW1lbnQgaGVyZSBvbmx5IGZvciBQTVMg dG8gbGVhcm4gdGhlIHRvcG9sb2d5LCBpbiB0aGUNCiAgICAgICAgICAgIGNhc2Ugb2YgbWl4ZWQg ZW52Pw0KW1JHXSBNUExTIHRvcG9sb2d5IGF3YXJlbmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRv IHNldCB1cCBwYWNrZXRzIHdpdGggbGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hh aW4gb2YgTFNQcy4gSWYgc3VpdGFibGUgTGFiZWwvRkVDL25vZGUgcmVsYXRpb24gaXMga25vd24g dG8gdGhlIFBNUywgdGhhdCBMU1AgY2FuIGJlIGV4ZWN1dGVkIGZyb20gdGhhdCBub2RlIG9uIGJ5 IGEgUE1TIG1vbml0b3JpbmcgcGFja2V0Lg0KJXNhbSAtIFNvLCB5b3UgYXJlIHNheWluZyB0aGF0 IHlvdSBzdGlsbCBuZWVkIHRvIHBlcmZvcm0gUkZDNDM3OSB0cmFjZSBvciB0cmVldHJhY2UgdG8g Z2V0IHRvcG9sb2d5LiBJIGRvIG5vdCB0aGluayBJR1AgZXh0ZW5zaW9ucyBiZWluZyBwcm9wb3Nl ZCBpbiBTUFJJTkcgZXhwb3J0IGFueSBvZiB0aGUgaW5mbyBvdGhlciB0aGFuIGxhYmVsIHN0YWNr Lg0KQW5kIHRoZSBwcm9wb3NlZCBQTVMgc29sdXRpb24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwg aXQgcGVyZm9ybXMgb24gZGVtYW5kIHBlciBzZWdtZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28g ZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgdG9wb2xvZ3kuDQpUaGUgY2FzZSB5b3UgYXJlIG1h a2luZyBpcyB0aGF0IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9mIFJGQzQzNzkuDQoN ClF1ZXN0aW9uIEkgaGF2ZSBmb3IgeW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMgYXJlIGdl dHRpbmcgZHJvcHBlZCBhbmQgUE1TIHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4g TFNQIG9yIFNlZ21lbnQsIGhvdyBkbyB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlv dSBrbm93LCBob3cgZG8geW91IGZpZ3VyZSBvdXQgd2hlcmUgaXQgaXM/DQpBdCBsZWFzdCB3aXRo IFJGQzQzNzkgYW5kL29yIHByb3h5IHBpbmcsIHlvdSBjb3VsZCB2YWxpZGF0ZSBlYWNoIGhvcCBi ZWNhdXNlIG9mIHRoZSBiZWxscyBhbmQgd2hpc3RsZXMgaXQgY2FycmllcyBhbG9uZyB3aXRoIHRo ZSBwYWNrZXQuDQoNCg0KDQogICAgICAgICA2LiBJbiBzZWMgMy4xLA0KICAgICAgICAgPHNuaXA+ DQogICAgICAgICBEZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8gYSBt ZWFzdXJlbWVudCBtYXkgYWxzbyBiZQ0KICAgICAgICAgZG9uZSBieSBzZXR0aW5nIHVwIGEgbGFi ZWwgaW5jbHVkaW5nIGFsbCBub2RlIFNJRHMgYWxvbmcgdGhhdCBwYXRoDQogICAgICAgICAoaWYg TEVSMSBoYXMgTm9kZSBTSUQgNDAgaW4gdGhlIGV4YW1wbGUgYW5kIGl0IHNob3VsZCBiZSBwYXNz ZWQNCiAgICAgICAgIGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLCB0aGUgbGFiZWwgc3RhY2sgaXMg MjAgLSA0MCAtIDMwIC0gMTApLiAgVGhlDQogICAgICAgICBhZHZhbnRhZ2Ugb2YgdGhpcyBtZXRo b2QgaXMsIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTQ0KICAgICAgICAgZnVuY3Rp b25hbGl0eSBhbmQgaXQgaXMgaW5kZXBlbmRlbnQgb2YgRUNNUCBmdW5jdGlvbmFsaXRpZXMuICBU aGUNCiAgICAgICAgIG1ldGhvZCBzdGlsbCBpcyBhYmxlIHRvIG1vbml0b3IgYWxsIGxpbmsgY29t YmluYXRpb25zIG9mIGFsbCBwYXRocyBvZg0KICAgICAgICAgYW4gTVBMUyBkb21haW4uICBJZiBj b3JyZWN0IGZvcndhcmRpbmcgYWxvbmcgdGhlIGRlc2lyZWQgcGF0aHMgaGFzIHRvDQogICAgICAg ICBiZSBjaGVja2VkLCBSRkM0NzM5IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGFwcGxpZWQgYWxz byBpbiB0aGlzDQogICAgICAgICBjYXNlLg0KDQogICAgICAgICA8ZW5kIHNuaXA+DQoNCiAgICAg ICAgIEluIHRoZSBhYm92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMgbm90IGludm9sdmUgTVBM UyBPQU0uIEJ1dCBsYXRlciB5b3Ugc2F5LA0KICAgICAgICAgUkZDNDM3OSBmdW5jdGlvbmFsaXR5 IGNvdWxkIGJlIHVzZWQuIENvdWxkIHlvdSBjbGFyaWZ5IGhvdyBjb3VsZCB5b3UgdmVyaWZ5IGEN CiAgICAgICAgIHBhdGgsIGlmIE1QTFMgdmFsaWRhdGlvbiBpcyBub3QgZG9uZS4gTW9yZSB0ZXh0 IHdpbGwgaGVscC4gQWxzbywgbW9yZQ0KICAgICAgICAgaW1wb3J0YW50bHksIHRoZSB0ZXh0IGVh cmxpZXIgdG8gdGhlIGFib3ZlIHNheXMsIGZvciB2YWxpZCByZXN1bHQsIE1QTFMNCiAgICAgICAg IE9BTSBoYXMgdG8gYmUgcGVyZm9ybWVkIGZvciB0b3BvbG9neSBjaGFuZ2VzIGV0Yy4gSWYgc28s IGl0IGNvbnRyYWRpY3RzIGhlcmUuDQpbUkddIFRoZSB0ZXh0IHNob3VsZCBzYXkgdGhhdA0KLSB3 aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVjdXRlcyBhIHNldCBvZiBwYXRo cyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24uDQotIGlmIHRoZSBvcGVy YXRvciB3YW50cyB0byBtYWtlIHN1cmUgdGhhdCBkYXRhIHBsYW5lIGNvcnJlc3BvbmRzIHRvIGNv bnRyb2wgcGxhbmUsIFJGQzQ3MzkgZnVuY3Rpb25zIHNob3VsZCBiZSBhcHBsaWVkLg0KSWYgeW91 IHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQgYW5kIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBzdGF0 ZXMgc29tZXRoaW5nIGRpZmZlcmVudCwgSSdsbCB0cnkgdG8gcmV3b3JkIGl0Lg0KJXNhbSAtIFRo ZSBwcm9ibGVtIEkgYW0gaGF2aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FNLCB5 b3UgaGF2ZSB0byB2YWxpZGF0ZSB0aGUgbHNwLg0KSSBkZWZpbml0ZWx5IHNlZSBhIHNwZWNpZmlj IG5lZWQgZm9yIFNQUklORywgYnV0IHdoYXQgSSBmZWVsIGlzLCB0aGUgdXNlIGNhc2UgaXMgdG9v IG11Y2ggY2F0ZXJlZCB0byBhIHNwZWNpZmljIGVudmlzaW9uZWQgc29sdXRpb24uDQpPbmNlIHlv dSByZW1vdmUgc29sdXRpb24gb3Igc3VnZ2VzdGVkIGVuaGFuY2VtZW50cywgaG9wZSBpdCBzaG91 bGQgYmUgY2xlYXIgb24gd2hhdCBpcyBiZWluZyBzb2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciBy ZXF1aXJlbWVudHMgZm9yIGEgc29sdXRpb24uDQpGb3Igc29sdXRpb24gcGFydCwgcGxlYXNlIHB1 Ymxpc2ggYSBzZXBhcmF0ZSBJRC4NCg0KDQogICAgICAgICA3LiBMYXN0IGJ1dCBub3QgdGhlIGxl YXN0LCBob3cgZGlmZmVyZW50IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPw0KICAgICAgICAgU29t ZWhvdyBJIGNvdWxkbid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ugd2hhdCBQTVMgY291bGQgZG8gYW5k DQogICAgICAgICBOTVMvRU1TIGNvdWxkbid0Lg0KW1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFu IEVNUy9OTVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9s b2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1Ag Y29tYmluYXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUg YmVlbiBjb21tZXJjaWFsbHkgYXZhaWxhYmxlLCB0aGUgY29tcGFueSBJIHdvcmsgZm9yIHdvdWxk bid0IGhhdmUgYmVlbiBkZXZlbG9waW5nIGEgUE1TLg0KJXNhbSAtIFRoZXJlIGFyZSB0b29scyB3 aGljaCBhcmUgcGFydCBvZiBOTVMvT1NTLCB3aGljaCBwZXJmb3JtcyBNUExTIHRvcG9sb2d5IHNw ZWNpZmljIG9wZXJhdGlvbnMgIGZvciBhIGdpdmVuIHNldCBvZiBMU1Ancy4gVGhleSBwZXJmb3Jt IFRyZWV0cmFjZSBhbmQgcGVyZm9ybSBwaW5nIHdpdGggbXVsdGlwYXRoLiBBbHNvIHBlcmZvcm0g TFNQIHNwZWNpZmljIHZhbGlkYXRpb24gYnkgY3JhZnRpbmcgcGFja2V0cyB3aXRoIGRhdGEgYXZh aWxhYmxlIHdpdGggdHJlZXRyYWNlIGFuZCBwaW5nIHdpdGggbXVsdGlwYXRoLiBZb3UgY291bGQg YXV0b21hdGUgdGhlIHdvcmtmbG93IHdpdGhvdXQgdGhlIG5lZWQgZm9yIE9TUy9QTVMsIGJ5IHVz aW5nIHByb2JlIHRlY2hub2xvZ3kuIFdpbGwgbm90IHNheSBiZXlvbmQgdGhhdCA6RA0KDQpjaGVl cnMNCi1zYW0NCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA84582A0Enkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5D aGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5WZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQg cm91dGluZyBkb2VzbuKAmXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcGF0aCB0 byBtYWludGFpbiBzdGF0ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0 ZQ0KIHdoaWxlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UHJv eHktbHNwLXBpbmcgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcmV0dXJuIHBhdGgg dG8gbWFpbnRhaW4gdGhlIHN0YXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2h5IGFwcGx5IFByb3h5LWxzcC1waW5nIHRvIHNwcmluZyBPQU0/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gc3ByaW5nIFttYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5Ob2Jv IEFraXlhIChub2JvKTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kyI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Nzwvc3Bhbj7m nIg8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDM6 MDA8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gU2FtIEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2U8YnI+ DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgU2FtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5KdXN0IHRvIHBvaW50 IG91dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIHRlc3QgcGFja2V0IGdlbmVyYXRlZCBmcm9tIGEgUE1TL05N Uy9FTVMvbmV0d29yay1kZXZpY2UgY2FuIGhhdmUgdGhlIGNvbXBsZXRlIHNlZ21lbnQgc3RhY2sg b24gaG93IHRvIHRyYXZlcnNlIHRoZSBuZXR3b3JrIGFzIHdlbGwgYXMgaG93IHRvDQogY29tZSBi YWNrIHRvIHNlbGYgd2l0aG91dCBhbnkgZnVydGhlciBzaWduYWxpbmcsIE9BTSBzdGF0ZSBtYWlu dGVuYW5jZSBvbiBuZXR3b3JrIG5vZGVzIG5vciBPQU0gaW52b2x2ZW1lbnQgYnkgbmV0d29yayBu b2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBtYWtlcyB0aGlz IGFwcHJvYWNoIHF1aXRlIGRpZmZlcmVudCBmcm9tIHVzaW5nIHByb3h5IExTUCBwaW5nLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGNlcnRhaW5seSBoYXMgc29tZSBw cm9zIGFuZCBjb25zIGJ1dCBjYW4gYmUgcXVpdGUgdXNlZnVsIGFzIG9uZSBvZiB0aGUgT0FNcyAo eWVzIHBsdXJhbCkgdXNlZCB0byBtb25pdG9yIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi1Ob2JvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZyBbPGEgaHJlZj0i bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TYW0gQWxkcmluPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZTwvYT48YnI+DQo8Yj5DYzo8L2I+IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVz ZWNhc2U8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5IaSBSdWVkaWdlciw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGFua3MgZm9yIHRoZSBxdWljayByZXNw b25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk9uIFRo dSwgSnVsIDEwLCAyMDE0IGF0IDc6MTUgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86UnVlZGlnZXIu R2VpYkB0ZWxla29tLmRlIiB0YXJnZXQ9Il9ibGFuayI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkhpIFNhbSw8YnI+DQo8YnI+DQpteSByZXBsaWVzIGFyZSBt YXJrZWQgW1JHXSBhbmQgYWRkZWQgdG8geW91ciB0ZXh0Ljxicj4NCjxicj4NCi0gUHJveHktbHNw LXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBpcyBpbnRlbmRl ZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyAmIzQzOyBJUHY2KS4gV2UnbGwgY2xhcmlm eSB0aGF0IGluIHRoZSBkcmFmdC48YnI+DQotIFByb3h5LWxzcC1waW5nIGlzIGZvciBNUExTIExT UCBQaW5nIChSRkMgNDM3OSAvIFJGQyA2NDI0KSwgd2hpbGUgb3VyIHVzZSBjYXNlIGNhbiB1c2Ug YW55IE9BTSAoaW4gcGFydGljdWxhciwgc3BlY2lmaWMgZ29vZCB1c2VzIGZvciBCRkQsIGFuZCBJ Q01QdjYpPGJyPg0KPGJyPg0KQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3aXRoIGJy b2FkZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yIFNQUklORyBhcyBhIHdob2xlLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+JXNhbSAtIEkgYmVsaWV2ZSB5b3Ugc2F5IGl0IGlzIHVzZSBjYXNlIGRvY3Vt ZW50IGJlbG93LiBUaGVuIHNvbHV0aW9uIGlzIHRvbyBwcmVtYXR1cmUgYXQgdGhpcyBwb2ludCBv ZiB0aW1lLCBhcyB3ZSBoYXZlbid0IGRlbGliZXJhdGVkIG9uIHRoZSByZXF1aXJlbWVudHMgZWl0 aGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KQXMgeW91IHdyaXRlLCBTUiBiYXNlZCBPQU0gcGFydGlh bGx5IG9mZmVycyBzaW1pbGFyIGZ1bmN0aW9ucyBhcyBwcm94eS1sc3AuIFdpdGhvdXQgcmVxdWly aW5nIHRoZSBhZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBMRVIvTFNSIHByb2Nlc3NpbmcgaW50cm9k dWNlZCBieSBwcm94eS1sc3AuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KUmVnYXJkcyw8YnI+ DQo8YnI+DQpSdWVkaWdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB Ij48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBTYW0gQWxkcmluIHdyb3RlOjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSBmZXcgcXVlc3Rpb25zIGFib3V0IHRo aXMgZHJhZnQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgMS4gVGhlIHRpdGxlIGlz IGNvbmZ1c2luZyB0byBtZS4gSXQgc2F5cyBPQU0gdXNlIGNhc2UgYnV0IGluIHNlY3Rpb24gIzE8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpdCBzYXlzIHRoZSBmb2xsb3dpbmc8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7c25pcCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNvbHV0aW9uIHRvIHRoaXMgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWxsdXN0 cmF0ZXMgaXQgd2l0aCB1c2UtY2FzZXMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7VGhlIHNvbHV0aW9uIGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9t YWluLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBzb2x1dGlvbiBh cHBsaWVzIHRvIG1vbml0b3Jpbmcgb2YgTERQIExTUCdzIGFzIHdlbGwgYXMgdG88YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttb25pdG9yaW5nIG9mIFNlZ21lbnQgUm91dGVkIExTUCdz Ljxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtlbmQgc25pcCZndDs8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5n IGEgc29sdXRpb24gdG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvdmlkaW5nIHVzZSBjYXNlcy9zY2VuYXJpb3MuIE15IHVu ZGVyc3RhbmRpbmcgd2FzLCB1c2UgY2FzZSBkcmFmdCBzaG91bGQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBkcml2ZSBuZXcg cmVxdWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtiZSBjb3ZlcmVkIHdpdGggZXhpc3RpbmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBk ZXBlbmRpbmcgb24gdGhlIEdBUDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuYWx5 c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhlcmUgY291bGQgYmUgbW9yZSB0 aGFuIDEgc29sdXRpb24sPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hlcmUgYXMg dGhpcyBkb2N1bWVudCBjb3VsZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Ljxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmIGluZmFjdCB0aGlzIGlzIHN1cHBvc2Vk IHRvIGJlIGEgc29sdXRpb24gZG9jdW1lbnQsIHRoZW4gY2hhbmdpbmcgdGhlIHRpdGxlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d291bGQgYmUgbW9yZSBtZWFuaW5nZnVsLiBUaGF0 J3MgbXkgb2JzZXJ2YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+W1JHXSBUaGFua3MuIEl0J3MgYSB1c2Ug Y2FzZSBkb2N1bWVudC4gV2UnbGwgcmV2aWV3IHRoZSB0ZXh0IG9mIHNlY3Rpb24gMS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiVzYW0gLSBPSy4gdGhlbiBJJ2QgbGlrZSB0byBzZWUgYW55 IHNwZWNpZmljIHNvbHV0aW9uIGNvbnRlbnQgcmVtb3ZlZCwgdGhhdCB3YXkgd2UgZG9udCBoYXZl IHRvIGRpc2N1c3Mgd2hhdCBvdGhlciBzb2x1dGlvbnMgZG9lcyBlaXRoZXIgb3IgY29tcGFyZSB3 aXRoIDpEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4g dy5yLnQuIFNlY3Rpb24gbnVtYmVyICMyLCB0aGUgc2FtZSBwcm9ibGVtIGlzIGJlaW5nIHNvbHZl ZCB3aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7ZHJhZnQtaWV0Zi1t cGxzLXByb3h5LWxzcC1waW5nLTAyJnF1b3Q7IC4gV2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaW4g dGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlY3Rpb24gY291bGQgYmUgZG9u ZSB3aXRoIHRoZSBwcm94eSBwaW5nKHNvbHV0aW9uIHdpc2UpIHdoZXJlLCByZXF1ZXN0IGNvdWxk PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgc2VudCB0byBtb25pdG9yIExFUiBp IGFuZCBMRVIgaiBzZWdtZW50LCBmcm9tIGEgUE1TLiBJcyBteSB1bmRlcnN0YW5kaW5nPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmlnaHQ/IElmIG5vdCwgaG93IGlzIGl0IGRpZmZl cmVudCBoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBw YWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwO2NoYWluIG9mIE1QTFMgTFNQcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiPiVzYW0gLSBFeGVjdXRlIHlvdSBtZWFuIHRyYXZlcnNlPyBvciBwZXJmb3Jt IHNvbWV0aGluZyBlbHNlPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KW1JHXSBQcm94eS1sc3Agc2F5czog VGhpcyBkb2N1bWVudCBkZWZpbmVzIHByb3RvY29sIGV4dGVuc2lvbnMgdG8gTVBMUyBwaW5nIFtS RkM0Mzc5XSB0bzxicj4NCiZuYnNwOyAmbmJzcDthbGxvdyBhIHRoaXJkIHBhcnR5IHRvIHJlbW90 ZWx5IGNhdXNlIGFuIE1QTFMgRWNobyBSZXF1ZXN0IG1lc3NhZ2UgdG88YnI+DQombmJzcDsgJm5i c3A7YmUgc2VudCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+JXNhbSAtIElmIGl0IGlzIHByb3Bvc2luZyBleHRlbnNpb25zLCAmbmJzcDtp dCBoYXMgdG8gYmUgc29sdXRpb24gZG9jdW1lbnQgJm5ic3A7YW5kIGNhbm5vdCBjbGFpbSB0byBi ZSB1c2UgY2FzZSBkb2N1bWVudC4gQWxzbyB0aGlzIGRvY3VtZW50IGlzIG9uIGluZm9ybWF0aW9u IHRyYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+PGJyPg0KW1JHXSBJIHRha2UgaXQgYXMgc2F5aW5nIHRoYXQgaWYgeW91 J2QgbGlrZSB0byByZW1vdGVseSBleGVjdXRlIFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBvbiBhbnkg TFNQLCB5b3UgY291bGQgZWl0aGVyIHVzZSB0aGUgUE1TIG9yIHByb3h5LXBpbmcuIFRoZSBQTVMg aG93ZXZlciBzaW1wbGlmaWVzIGFuZCBhZGRzPGJyPg0KZnVuY3Rpb25hbGl0eTo8YnI+DQphKSBZ b3UgZG9uJ3QgbmVlZCBhbiBhZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlr ZSBwcm94eS1waW5nIHRvIGNoZWNrIGRhdGE8YnI+DQombmJzcDsgJm5ic3A7cGxhbmUgbGl2ZWxp bmVzcywgUkZDNDM3OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGlt cGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+JXNhbSAtIFJGQzQzNzkg cGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxhbmUgYW5kIGFsc28gZmluZCBvdXQgbG90IG1v cmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHBlcmZvcm0gdmFs aWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVmZXJyZWQg dG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRlcGxveW1lbnRzLlNvDQogYXJlIHlvdSBzYXlpbmcs IFBNUyBzb2x1dGlvbiBpcyBkZXNpZ25lZCBmb3IgbGl2ZW5lc3MgZGV0ZWN0aW9uIGFuZCBub3Qg dG8gcGVyZm9ybSB2YWxpZGF0aW9uIG9mIGRhdGEgcGxhbmUgdG8gY29udHJvbCBwbGFuZSwgZXRj PyAoSSB0aGluayB5b3UgYWdyZWUgdG8gdGhpcyBpbiB0aGUgbGF0ZXIgcGFydCBvZiB0aGUgZG9j IGFsc28pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Yikgb25jZSBQTVMgZGV0 ZWN0ZWQgZGF0YSBwbGFuZSBsaXZlbGluZXNzIGFuZCBjb3JyZWN0bmVzcyBvZiBNUExTIHRvcG9s b2d5IGJ5IFJGQzQzNzksPGJyPg0KJm5ic3A7ICZuYnNwO2l0IGNhbiBjb250aW51ZSB0byBleGVj dXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9uaXRvcmluZyBwYWNrZXRz IHN0YXk8YnI+DQombmJzcDsgJm5ic3A7aW4gZGF0YSBwbGFuZS4gUGxlYXNlIHBvaW50IG1lIHRv IHRoZSB0ZXh0IGluIHByb3h5LXBpbmcgb2ZmZXJpbmcgdGhpcyBmZWF0dXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+JXNhbSAtIFRoaXMgeW91IGNvdWxkIHBlcmZvcm0gZXZlbiB3aXRo b3V0IHByb3h5IHBpbmcuIFRoZSBmdW5jdGlvbiB5b3UgYXJlIGRlc2NyaWJpbmcgaXMsIGhvdyB5 b3UgdXNlIGxzcCBwaW5nIHJhdGhlciB0aGFuIHdoYXQgbHNwIHBpbmcgZG9lcy4gQWdhaW4gSSBh bSBub3QgdGFsa2luZyBhYm91dCBub24tbXBscyB0b3BvbG9neS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSI+VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+LSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5 IGluZm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+LSBwaWNrIGFueSBhcmJpdGFyeSBMU1AgcGF0aHMg ZGlzY292ZXJlZCBhbG9uZyB3aXRoIGl0cyBtdWx0aXBhdGggaW1wbGVtZW50YXRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiPi0gcGVyZm9ybSBwaW5nIHdpdGggcmlnaHQgc2VsZWN0b3JzIGZvciB0 aGUgcGF0aCBhbmQgdXNlIFRUTCBmb3IgbGltaXRpbmcgdGhlIGhvcCBbTEVSIGpdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj4tIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIg aiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgMy4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBN UyB3aGljaCBpcyBub3QgcGFydCBvZiBNUExTIG9yIHNlZ21lbnQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0 LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmU8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwg eW91IGJlIGRvY3VtZW50aW5nIHRoYXQgYXNwZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPltSR10gVGhhdCdz IGEgdmFsaWQgcG9pbnQuIFRoZSBkb21haW4gZXh0ZXJuYWwgc3lzdGVtIGlzIG9uZSBvcHRpb24g YW5kIHRoZSB0ZWFtIHdpbGwgZGVhbCB3aXRoIHRoZSBzZWN1cml0eSBhc3BlY3RzIHJhaXNlZCBi eSB0aGlzIG9wdGlvbiBvbmNlIHdlIGFyZSBpbiBzb2x1dGlvbiBzcGFjZS4gV2Ugd2lsbCBub3Qg YW5hbHlzZSB0aGlzIGluIGRlcHRoIGZvciBhIHVzZSBjYXNlDQogZG9jdW1lbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gbm9kJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg NC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhh dCB3aXRoIFJGQzQzNzkgcGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRo IG11bHRwYXRoICYjNDM7IHByb3h5IHBpbmcuIENvdWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0 ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg bmV3IHRoZSBzb2x1dGlvbiBicmluZ3MgaGVyZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bUkddIFRoZSBTUiBP QU0gYXV0aG9yIHRlYW0gaGFzIHByb3ZpZGVkIHRleHQgaG93IHRvIG1vbml0b3IgYSBidW5kbGVk IGxpbmsgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LiBZb3UgYXJlIGEgY28tYXV0aG9yIG9mIHByb3h5 LWxzcC4gSSBjb3VsZG4ndCBmaW5kIGV4cGxpY2l0IHRleHQgb24gaG93IHRvIGRldGVjdCBhbmQg bW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbiBkcmFmdC1wcm94eS1sc3AuDQogUGxlYXNlIGRlc2Ny aWJlIGhvdyBwcm94eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAo c29ycnkgaWYgdGhpcyBpcyBvYnZpb3VzIGFuZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBk aWZmZXJlbmNlcyB0byB0aGUgU1IgT0FNIGFwcHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gVGhlIHNhbWUgc3RlcHMgZGVzY3JpYmVk IGFib3ZlIGNvdWxkIGJlIHVzZWQgaWYgZWFjaCBidW5kbGVkIGxpbmsgbWVtYmVyIGlzIGlkZW50 aWZpZWQgd2l0aCBhIHVuaXF1ZSBsYWJlbC4gV2hpbGUgcGVyZm9ybWluZyB0cmVlIHRyYWNlIG9y IHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRoIERETUFQIGluZm8g Zm9yIGVhY2ggb2YgdGhlDQogbGlua3MgYW5kIHRoZSBtdWx0aXBhdGggaW5mbyBmb3IgdGhlIHNh bWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPklmIHlvdSBzYXkgdGhhdCBlYWNoIGxpbmsgbWVtYmVy IGhhcyBzYW1lIGxhYmVsIHN0YWNrLCB0aGVuIHlvdSBjb3VsZCB1c2UgbHNwIHNlbGVjdG9ycyBh cyBkZWZpbmVkIGluIFJGQzQzNzksIGluIHRoaXMgY2FzZSBpdCBpcyBsb2NhbCBob3N0IGRlc3Qg aXAgYWRkciwgdG8gaWRlbnRpZnkgZWFjaCBsaW5rIG1lbWJlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSI+Tm93IGlmIHRoZSBNUExTIGZvcndhcmRpbmcgbGF5ZXIgc2VlcyB0aGUgYnVuZGxlZCBsaW5r IGFzIG9uZSBpbnRlcmZhY2UgYnV0IGNhbm5vdCBkaXNjZXJuIGl0cyBsaW5rIG1lbWJlcnMsIHRo ZW4geW91IGNvdWxkIG9ubHkgdmFsaWRhdGUgdGhlIGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRp dmlkdWFsIG1lbWJlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlNhbWUgYXBwbGllcyBpbiB5b3Vy IGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+ PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzUuIHNlYyAjNSwg SXMgdGhlIHJlcXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3BvbG9n eSwgaW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Y2FzZSBvZiBtaXhlZCBlbnY/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+W1JHXSBNUExTIHRvcG9sb2d5IGF3YXJl bmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1cCBwYWNrZXRzIHdpdGggbGFiZWwgc3Rh Y2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQcy4gSWYgc3VpdGFibGUgTGFiZWwv RkVDL25vZGUgcmVsYXRpb24gaXMga25vd24gdG8gdGhlIFBNUywgdGhhdCBMU1AgY2FuIGJlIGV4 ZWN1dGVkIGZyb20gdGhhdCBub2RlDQogb24gYnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQg eW91IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0cmFjZSB0byBn ZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2Vk IGluIFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFiZWwgc3RhY2su Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkFuZCB0aGUgcHJvcG9zZWQgUE1TIHNvbHV0aW9u IChub3QgdXNlIGNhc2UpIGlzIHRoYXQsIGl0IHBlcmZvcm1zIG9uIGRlbWFuZCBwZXIgc2VnbWVu dCwgd2hpY2ggUHJveHkgcGluZyBhbHNvIGRvZXMsIGFsYmVpdCBvbmx5IGZvciBNUExTIHRvcG9s b2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBpcyB0aGF0 IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9mIFJGQzQzNzkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5RdWVzdGlvbiBJIGhhdmUgZm9yIHlv dSBpcywgaWYgZGF0YSBwbGFuZSBwYWNrZXRzIGFyZSBnZXR0aW5nIGRyb3BwZWQgYW5kIFBNUyBw YWNrZXRzIGdvaW5nIHRocm91Z2gsIGZvciBhIGdpdmVuIExTUCBvciBTZWdtZW50LCBob3cgZG8g eW91IGtub3cgdGhlcmUgaXMgYSBwcm9ibGVtPyBpZiB5b3Uga25vdywgaG93IGRvIHlvdSBmaWd1 cmUgb3V0IHdoZXJlIGl0IGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5BdCBsZWFzdCB3aXRoIFJG QzQzNzkgYW5kL29yIHByb3h5IHBpbmcsIHlvdSBjb3VsZCB2YWxpZGF0ZSBlYWNoIGhvcCBiZWNh dXNlIG9mIHRoZSBiZWxscyBhbmQgd2hpc3RsZXMgaXQgY2FycmllcyBhbG9uZyB3aXRoIHRoZSBw YWNrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzYuIEluIHNlYyAzLjEsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDtzbmlwJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtEZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8gYSBtZWFzdXJlbWVu dCBtYXkgYWxzbyBiZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb25l IGJ5IHNldHRpbmcgdXAgYSBsYWJlbCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0 IHBhdGg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KGlmIExFUjEgaGFz IE5vZGUgU0lEIDQwIGluIHRoZSBleGFtcGxlIGFuZCBpdCBzaG91bGQgYmUgcGFzc2VkPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JldHdlZW4gTEVSIGkgYW5kIExFUiBq LCB0aGUgbGFiZWwgc3RhY2sgaXMgMjAgLSA0MCAtIDMwIC0gMTApLiAmbmJzcDtUaGU8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWR2YW50YWdlIG9mIHRoaXMgbWV0aG9k IGlzLCB0aGF0IGl0IGRvZXMgbm90IGludm9sdmUgTVBMUyBPQU08YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZnVuY3Rpb25hbGl0eSBhbmQgaXQgaXMgaW5kZXBlbmRlbnQg b2YgRUNNUCBmdW5jdGlvbmFsaXRpZXMuICZuYnNwO1RoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDttZXRob2Qgc3RpbGwgaXMgYWJsZSB0byBtb25pdG9yIGFsbCBsaW5r IGNvbWJpbmF0aW9ucyBvZiBhbGwgcGF0aHMgb2Y8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YW4gTVBMUyBkb21haW4uICZuYnNwO0lmIGNvcnJlY3QgZm9yd2FyZGluZyBh bG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YmUgY2hlY2tlZCwgUkZDNDczOSBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBh cHBsaWVkIGFsc28gaW4gdGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtjYXNlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7 ZW5kIHNuaXAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0luIHRoZSBhYm92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMgbm90IGludm9sdmUgTVBMUyBP QU0uIEJ1dCBsYXRlciB5b3Ugc2F5LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgY291bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJp ZnkgaG93IGNvdWxkIHlvdSB2ZXJpZnkgYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtwYXRoLCBpZiBNUExTIHZhbGlkYXRpb24gaXMgbm90IGRvbmUuIE1vcmUgdGV4dCB3 aWxsIGhlbHAuIEFsc28sIG1vcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7aW1wb3J0YW50bHksIHRoZSB0ZXh0IGVhcmxpZXIgdG8gdGhlIGFib3ZlIHNheXMsIGZvciB2 YWxpZCByZXN1bHQsIE1QTFM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 T0FNIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRjLiBJZiBzbywg aXQgY29udHJhZGljdHMgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bUkddIFRoZSB0ZXh0IHNob3VsZCBz YXkgdGhhdDxicj4NCi0gd2l0aG91dCBNUExTIE9BTSBmdW5jdGlvbnMsIHRoZSBQTVMgZXhlY3V0 ZXMgYSBzZXQgb2YgcGF0aHMgb25seSBiYXNlZCBvbiBjb250cm9sIHBsYW5lIGluZm9ybWF0aW9u Ljxicj4NCi0gaWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxh bmUgY29ycmVzcG9uZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxk IGJlIGFwcGxpZWQuPGJyPg0KSWYgeW91IHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQgYW5kIHRo ZSB0ZXh0IGluIHRoZSBkcmFmdCBzdGF0ZXMgc29tZXRoaW5nIGRpZmZlcmVudCwgSSdsbCB0cnkg dG8gcmV3b3JkIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+JXNhbSAtIFRoZSBwcm9i bGVtIEkgYW0gaGF2aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FNLCB5b3UgaGF2 ZSB0byB2YWxpZGF0ZSB0aGUgbHNwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5JIGRlZmluaXRlbHkg c2VlIGEgc3BlY2lmaWMgbmVlZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1 c2UgY2FzZSBpcyB0b28gbXVjaCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1 dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+T25jZSB5b3UgcmVtb3ZlIHNvbHV0aW9uIG9yIHN1 Z2dlc3RlZCBlbmhhbmNlbWVudHMsIGhvcGUgaXQgc2hvdWxkIGJlIGNsZWFyIG9uIHdoYXQgaXMg YmVpbmcgc29sdmVkIGFuZCBzY29wZSBvdXQgY2xlYXIgcmVxdWlyZW1lbnRzIGZvciBhIHNvbHV0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5Gb3Igc29sdXRpb24gcGFydCwgcGxlYXNlIHB1Ymxp c2ggYSBzZXBhcmF0ZSBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Ny4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZlcmVudCBp cyBQTVMgZnJvbSBFTVMgYW5kIE5NUz88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7U29tZWhvdyBJIGNvdWxkbid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ugd2hhdCBQTVMgY291 bGQgZG8gYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05NUy9FTVMg Y291bGRuJ3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+W1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9O TVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3 YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmlu YXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUgYmVlbiBj b21tZXJjaWFsbHkgYXZhaWxhYmxlLA0KIHRoZSBjb21wYW55IEkgd29yayBmb3Igd291bGRuJ3Qg aGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4l c2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBl cmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lmaWMgb3BlcmF0aW9ucyAmbmJzcDtmb3IgYSBnaXZl biBzZXQgb2YgTFNQJ3MuIFRoZXkgcGVyZm9ybSBUcmVldHJhY2UgYW5kIHBlcmZvcm0gcGluZyB3 aXRoIG11bHRpcGF0aC4gQWxzbyBwZXJmb3JtIExTUCBzcGVjaWZpYyB2YWxpZGF0aW9uDQogYnkg Y3JhZnRpbmcgcGFja2V0cyB3aXRoIGRhdGEgYXZhaWxhYmxlIHdpdGggdHJlZXRyYWNlIGFuZCBw aW5nIHdpdGggbXVsdGlwYXRoLiBZb3UgY291bGQgYXV0b21hdGUgdGhlIHdvcmtmbG93IHdpdGhv dXQgdGhlIG5lZWQgZm9yIE9TUy9QTVMsIGJ5IHVzaW5nIHByb2JlIHRlY2hub2xvZ3kuIFdpbGwg bm90IHNheSBiZXlvbmQgdGhhdCA6RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+Y2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPi1zYW08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA84582A0Enkgeml501mbschi_-- From nobody Mon Jul 14 05:39:13 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E51A03C2 for ; Mon, 14 Jul 2014 05:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.551 X-Spam-Level: X-Spam-Status: No, score=-114.551 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, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKlblxSOlOYV for ; Mon, 14 Jul 2014 05:39:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287711A039B for ; Mon, 14 Jul 2014 05:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75736; q=dns/txt; s=iport; t=1405341545; x=1406551145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=elOGK2DSoObobEQvdHtL6TyRpfga9z3NndTsPlvlOAI=; b=lrskmQH6nLpVjJYo9PCTIEEffPnuxwe5TDLZEMKlPVwh5v+EXICg6+Yw oN3TIm/tUwqa01b1vdTOOr50ledQF+bV1w9j7Td12yyJINNpfFSNpcYGl saK7KyrSobgiD6g5S3PVx9wRbzt4z8b9rEZB186GWVJm6PtaHehJpbSBc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAA3Ow1OtJA2H/2dsb2JhbABPCoJHIyRSWoJxvleHSwEZfxZ1hAMBAQEEGgkKOgsHEAIBBgIOAwEDAQELFgEGAwICAjAUAwYIAgQBDQUIE4gnAZNznCiXUReObysGByQGAQIEA4JuNoEWBZxYklSDRIFwJBw X-IronPort-AV: E=Sophos;i="5.01,658,1400025600"; d="scan'208,217";a="339843872" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 14 Jul 2014 12:39:04 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ECd39P031003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 12:39:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 14 Jul 2014 07:39:03 -0500 From: "Nobo Akiya (nobo)" To: Qin Wu , Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLwAKzC+wAABEV34A== Date: Mon, 14 Jul 2014 12:39:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E2651F1xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/MDuw8k7ztvfDXu04rC3NMkxkmKw Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 12:39:09 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E2651F1xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWluLCBldCBhbCwNCg0KRWFjaCBuZXR3b3JrIG5vZGUgd2lsbCBzdGlsbCBoYXZlIHNvbWUg c3RhdGVzIChpLmUuIG5vZGUvYWRqYWNlbmN5L3NlcnZpY2Ugc2VnbWVudHMpLg0KDQpJIHNlZSB0 aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZSBhcyBh IHdheSB0byBtb25pdG9yIHRoZSBuZXR3b3JrLCBidXQgbm90IGEgd2F5IHRvIHZhbGlkYXRlIHRo ZSBzZWdtZW50cy4gSW4gcGFydGljdWxhciB0aGUgZm9sbG93aW5nIGFzcGVjdHMgY2Fubm90IGJl IHZhbGlkYXRlZCBieSB0aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBkcmFmdC1nZWliLXNwcmluZy1v YW0tdXNlY2FzZS4NCg0KDQoxLiAgICAgIFVzaW5nIGEgc2VnbWVudCBvciBjb21iaW5hdGlvbiBv ZiBzZWdtZW50cyByZXN1bHQgaW4gYSBwYWNrZXQgdG8gcmVhY2ggYW4gZXhwZWN0ZWQgbmV0d29y ayBub2RlLg0KDQoyLiAgICAgIFVzaW5nIGFuIGFkamFjZW5jeSBzZWdtZW50IHJlc3VsdHMgaW4g YSBwYWNrZXQgdG8gdHJhdmVyc2Ugb3ZlciBhbiBleHBlY3RlZCBhZGphY2VuY3kuDQoNCjMuICAg ICAgVXNpbmcgYSBzZXJ2aWNlIHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byBoaXQgYW4g ZXhwZWN0ZWQgc2VydmljZS4NCg0KVGhpcyBpcyB3aHkgSSBwcmV2aW91c2x5IG1lbnRpb25lZCB0 aGF0IHRoZSB0ZWNobmlxdWUgaXMgdXNlZnVsIGFzIG9uZSBvZiB0aGUgT0FNcyB1c2VkIHRvIG1v bml0b3IgdGhlIG5ldHdvcmsuDQoNCkluIG90aGVyIHdvcmRzLCB3ZSB3b3VsZCBzdGlsbCB3YW50 IHRoaW5ncyBpbiBhZGRpdGlvbiB0byB2YWxpZGF0ZSB0aGUgc3RhdGVzIG9uIGVhY2ggbmV0d29y ayBub2RlIHNvIHRoYXQsIHdoZW4gaW5ncmVzc2VzIHN0ZWVyIHBhY2tldHMgdXNpbmcgY29tYmlu YXRpb25zIHNlZ21lbnRzICh0aGF0IG1ha2VzIHVzZSBvZiB0aG9zZSBzdGF0ZXMpLCB0aGVuIGV4 cGVjdGVkIGFuZCBhY3R1YWwgcGF0aHMgYWxpZ25zLg0KDQpJIGludGVudGlvbmFsbHkgZGlkbuKA mXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24gb24gdGhlIHVzZWZ1bG5lc3Mgb2YgUHJveHkgTFNQIFBp bmcgbiBTZWdtZW50IFJvdXRpbmcsIGJ1dCBJIHdhbnRlZCB0byBoaWdobGlnaHQgd2hhdCBhcmUg dGhlIGFkZGl0aW9uYWwgcG9pbnRzIHdlIHdvdWxkIHdhbnQgdG8gY292ZXIgZnJvbSBPQU0gcGVy c3BlY3RpdmUuDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KRnJvbTogUWluIFd1IFttYWlsdG86Ymls bC53dUBodWF3ZWkuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDU6MDggQU0NClRv OiBOb2JvIEFraXlhIChub2JvKTsgU2FtIEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl DQpDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KU3ViamVjdDogUkU6 IFtzcHJpbmddIFF1ZXN0aW9ucw0KDQpWZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQgcm91 dGluZyBkb2VzbuKAmXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcGF0aCB0byBt YWludGFpbiBzdGF0ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0ZSB3 aGlsZQ0KUHJveHktbHNwLXBpbmcgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcmV0 dXJuIHBhdGggdG8gbWFpbnRhaW4gdGhlIHN0YXRlLg0KV2h5IGFwcGx5IFByb3h5LWxzcC1waW5n IHRvIHNwcmluZyBPQU0/DQoNClJlZ2FyZHMhDQotUWluDQrlj5Hku7bkuro6IHNwcmluZyBbbWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTm9ibyBBa2l5YSAobm9ibykNCuWP kemAgeaXtumXtDogMjAxNOW5tDfmnIgxMeaXpSAzOjAwDQrmlLbku7bkuro6IFNhbSBBbGRyaW47 IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRl Pg0K5oqE6YCBOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQrkuLvpopg6 IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnMNCg0KSGkgU2FtLA0KDQpKdXN0IHRvIHBvaW50IG91dCBv bmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKYNCg0KVGhlIHRlc3QgcGFja2V0IGdlbmVy YXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1kZXZpY2UgY2FuIGhhdmUgdGhlIGNvbXBs ZXRlIHNlZ21lbnQgc3RhY2sgb24gaG93IHRvIHRyYXZlcnNlIHRoZSBuZXR3b3JrIGFzIHdlbGwg YXMgaG93IHRvIGNvbWUgYmFjayB0byBzZWxmIHdpdGhvdXQgYW55IGZ1cnRoZXIgc2lnbmFsaW5n LCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0d29yayBub2RlcyBub3IgT0FNIGludm9sdmVt ZW50IGJ5IG5ldHdvcmsgbm9kZXMuDQoNClRoYXQgbWFrZXMgdGhpcyBhcHByb2FjaCBxdWl0ZSBk aWZmZXJlbnQgZnJvbSB1c2luZyBwcm94eSBMU1AgcGluZy4NCg0KVGhpcyBjZXJ0YWlubHkgaGFz IHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2YgdGhl IE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay4NCg0KVGhhbmtz IQ0KDQotTm9ibw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0 IDI6MTMgUE0NClRvOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU8bWFpbHRvOlJ1ZWRpZ2VyLkdl aWJAdGVsZWtvbS5kZT4NCkNjOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNl DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIFJ1ZWRpZ2VyLA0KDQpUaGFu a3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGlu ZS4NCg0KT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwgPFJ1ZWRpZ2VyLkdlaWJAdGVs ZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBTYW0s DQoNCm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuDQoN Ci0gUHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVy ZSBpcyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyArIElQdjYpLiBXZSds bCBjbGFyaWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Lg0KLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBM UyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2UgY2FzZSBjYW4g dXNlIGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBmb3IgQkZELCBh bmQgSUNNUHY2KQ0KDQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGggYnJvYWRl ciBzY29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuDQolc2FtIC0gSSBi ZWxpZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cuIFRoZW4gc29sdXRp b24gaXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9mIHRpbWUsIGFzIHdlIGhhdmVuJ3Qg ZGVsaWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBlaXRoZXIuDQoNCkFzIHlvdSB3cml0ZSwg U1IgYmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJveHkt bHNwLiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBhbmQgTEVSL0xT UiBwcm9jZXNzaW5nIGludHJvZHVjZWQgYnkgcHJveHktbHNwLg0KDQpSZWdhcmRzLA0KDQpSdWVk aWdlcg0KDQoNCiAgICAgIFNhbSBBbGRyaW4gd3JvdGU6DQoNCiAgICAgIEkgaGF2ZSBmZXcgcXVl c3Rpb25zIGFib3V0IHRoaXMgZHJhZnQuDQoNCiAgICAgIDEuIFRoZSB0aXRsZSBpcyBjb25mdXNp bmcgdG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxDQogICAgICBp dCBzYXlzIHRoZSBmb2xsb3dpbmcNCg0KICAgICAgPHNuaXA+DQogICAgICAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KICAg ICAgIGlsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLg0KDQogICAgICAgVGhlIHNvbHV0aW9u IGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLg0KDQogICAgICAgVGhl IHNvbHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0 bw0KICAgICAgIG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuDQogICAgICA8ZW5k IHNuaXA+DQoNCiAgICAgICBJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5nIGEgc29sdXRp b24gdG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0DQogICAgICAgcHJvdmlkaW5nIHVz ZSBjYXNlcy9zY2VuYXJpb3MuIE15IHVuZGVyc3RhbmRpbmcgd2FzLCB1c2UgY2FzZSBkcmFmdCBz aG91bGQNCiAgICAgICBkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBkcml2ZSBuZXcg cmVxdWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQNCiAgICAgICBiZSBjb3ZlcmVkIHdpdGggZXhp c3RpbmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBlbmRpbmcgb24gdGhlIEdBUA0KICAg ICAgIGFuYWx5c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhlcmUgY291bGQg YmUgbW9yZSB0aGFuIDEgc29sdXRpb24sDQogICAgICAgd2hlcmUgYXMgdGhpcyBkb2N1bWVudCBj b3VsZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Lg0KDQogICAgICAgSWYgaW5mYWN0IHRo aXMgaXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0 aGUgdGl0bGUNCiAgICAgICB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBteSBvYnNl cnZhdGlvbi4NCltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNhc2UgZG9jdW1lbnQuIFdlJ2xsIHJl dmlldyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuDQolc2FtIC0gT0suIHRoZW4gSSdkIGxpa2UgdG8g c2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIHRoYXQgd2F5IHdlIGRv bnQgaGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRpb25zIGRvZXMgZWl0aGVyIG9yIGNv bXBhcmUgd2l0aCA6RA0KDQoNCiAgICAgICAyLiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRo ZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIHdpdGgNCiAgICAgICAiZHJhZnQtaWV0Zi1t cGxzLXByb3h5LWxzcC1waW5nLTAyIiAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXMN CiAgICAgICBzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJveHkgcGluZyhzb2x1dGlv biB3aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZA0KICAgICAgIGJlIHNlbnQgdG8gbW9uaXRvciBM RVIgaSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJzdGFuZGluZw0K ICAgICAgIHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT8NCltSR10gVGhl IFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0YSBwbGFuZSBh bmQgZXhlY3V0ZSBhIGRlc2lyZWQNCiAgICAgY2hhaW4gb2YgTVBMUyBMU1BzLg0KJXNhbSAtIEV4 ZWN1dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVsc2U/DQoNCltS R10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbCBleHRlbnNp b25zIHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG8NCiAgIGFsbG93IGEgdGhpcmQgcGFydHkgdG8g cmVtb3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bw0KICAgYmUgc2Vu dCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLg0KJXNhbSAtIElmIGl0IGlzIHByb3Bvc2lu ZyBleHRlbnNpb25zLCAgaXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICBhbmQgY2Fubm90 IGNsYWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24g aW5mb3JtYXRpb24gdHJhY2suDQoNCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0IGlmIHlv dSdkIGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55 IExTUCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBUaGUgUE1T IGhvd2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkcw0KZnVuY3Rpb25hbGl0eToNCmEpIFlvdSBkb24n dCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBsaWtlIHByb3h5 LXBpbmcgdG8gY2hlY2sgZGF0YQ0KICAgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3OSBpcyBmaW5l LiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxlbWVudGF0aW9uLg0KJXNhbSAt IFJGQzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxhbmUgYW5kIGFsc28gZmluZCBv dXQgbG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHBl cmZvcm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24sIEJGRCBpcyBw cmVmZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRlcGxveW1lbnRzLlNvIGFyZSB5b3Ug c2F5aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9yIGxpdmVuZXNzIGRldGVjdGlvbiBh bmQgbm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRhIHBsYW5lIHRvIGNvbnRyb2wgcGxh bmUsIGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMgaW4gdGhlIGxhdGVyIHBhcnQgb2Yg dGhlIGRvYyBhbHNvKQ0KDQpiKSBvbmNlIFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5l c3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSwNCiAgIGl0IGNh biBjb250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUg bW9uaXRvcmluZyBwYWNrZXRzIHN0YXkNCiAgIGluIGRhdGEgcGxhbmUuIFBsZWFzZSBwb2ludCBt ZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVhdHVyZS4NCiVzYW0g LSBUaGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5nLiBUaGUgZnVu Y3Rpb24geW91IGFyZSBkZXNjcmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGluZyByYXRoZXIg dGhhbiB3aGF0IGxzcCBwaW5nIGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9u LW1wbHMgdG9wb2xvZ3kuDQpUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3Jt Lg0KLSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5IGluZm8N Ci0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMg bXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLg0KLSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxl Y3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIg al0uDQotIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIgaiBhcyBpbiB5 b3VyIGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpDQoNCiAgICAgICAg My4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBNUyB3aGljaCBpcyBub3QgcGFy dCBvZiBNUExTIG9yIHNlZ21lbnQNCiAgICAgICAgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMg c2VjdXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmUNCiAg ICAgICAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91IGJlIGRv Y3VtZW50aW5nIHRoYXQgYXNwZWN0Pw0KW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRv bWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0gd2lsbCBkZWFs IHdpdGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2Ug YXJlIGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGgg Zm9yIGEgdXNlIGNhc2UgZG9jdW1lbnQuDQolc2FtIC0gbm9kDQoNCiAgICAgICAgNC4gU2VjIDMu MiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRoIFJG QzQzNzkgcGluZw0KICAgICAgICB3aXRoIG11bHRwYXRoICsgcHJveHkgcGluZy4gQ291bGQgeW91 IGtpbmRseSBkaWZmZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZw0KICAgICAgICBuZXcg dGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KW1JHXSBUaGUgU1IgT0FNIGF1dGhvciB0ZWFtIGhh cyBwcm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIHRoZSB1c2Ug Y2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkgY291bGRuJ3Qg ZmluZCBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVk IGxpbmsgaW4gZHJhZnQtcHJveHktbHNwLiBQbGVhc2UgZGVzY3JpYmUgaG93IHByb3h5LWxzcCBj YW4gYmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIChzb3JyeSBpZiB0aGlzIGlzIG9i dmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIHRvIHRoZSBT UiBPQU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS4NCiVzYW0gLSBUaGUgc2FtZSBzdGVw cyBkZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1i ZXIgaXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRy ZWUgdHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNwb25kIHdpdGgg RERNQVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBhdGggaW5mbyBm b3IgdGhlIHNhbWUuDQpJZiB5b3Ugc2F5IHRoYXQgZWFjaCBsaW5rIG1lbWJlciBoYXMgc2FtZSBs YWJlbCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBzZWxlY3RvcnMgYXMgZGVmaW5lZCBp biBSRkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdCBkZXN0IGlwIGFkZHIsIHRv IGlkZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQpOb3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBs YXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBidXQgY2Fubm90IGRp c2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2YWxpZGF0ZSB0aGUg aW50ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy4NClNhbWUgYXBwbGllcyBp biB5b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuDQoNCg0KDQog ICAgICAgICA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVudCBoZXJlIG9ubHkgZm9yIFBNUyB0 byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZQ0KICAgICAgICAgICAgY2FzZSBvZiBtaXhlZCBl bnY/DQpbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24gdG8g c2V0IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhlY3V0aW5nIGEgZGVzaXJlZCBjaGFp biBvZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9kZSByZWxhdGlvbiBpcyBrbm93biB0 byB0aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUgb24gYnkg YSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuDQolc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQg eW91IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0cmFjZSB0byBn ZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2Vk IGluIFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFiZWwgc3RhY2su DQpBbmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBpcyB0aGF0LCBp dCBwZXJmb3JtcyBvbiBkZW1hbmQgcGVyIHNlZ21lbnQsIHdoaWNoIFByb3h5IHBpbmcgYWxzbyBk b2VzLCBhbGJlaXQgb25seSBmb3IgTVBMUyB0b3BvbG9neS4NClRoZSBjYXNlIHlvdSBhcmUgbWFr aW5nIGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS4NCg0K UXVlc3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEgcGxhbmUgcGFja2V0cyBhcmUgZ2V0 dGluZyBkcm9wcGVkIGFuZCBQTVMgcGFja2V0cyBnb2luZyB0aHJvdWdoLCBmb3IgYSBnaXZlbiBM U1Agb3IgU2VnbWVudCwgaG93IGRvIHlvdSBrbm93IHRoZXJlIGlzIGEgcHJvYmxlbT8gaWYgeW91 IGtub3csIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBpdCBpcz8NCkF0IGxlYXN0IHdpdGgg UkZDNDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIGJl Y2F1c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25nIHdpdGggdGhl IHBhY2tldC4NCg0KDQoNCiAgICAgICAgIDYuIEluIHNlYyAzLjEsDQogICAgICAgICA8c25pcD4N CiAgICAgICAgIERldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlvciB0byBhIG1l YXN1cmVtZW50IG1heSBhbHNvIGJlDQogICAgICAgICBkb25lIGJ5IHNldHRpbmcgdXAgYSBsYWJl bCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IHBhdGgNCiAgICAgICAgIChpZiBM RVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxkIGJlIHBhc3Nl ZA0KICAgICAgICAgYmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAy MCAtIDQwIC0gMzAgLSAxMCkuICBUaGUNCiAgICAgICAgIGFkdmFudGFnZSBvZiB0aGlzIG1ldGhv ZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNDQogICAgICAgICBmdW5jdGlv bmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gIFRo ZQ0KICAgICAgICAgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21i aW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9mDQogICAgICAgICBhbiBNUExTIGRvbWFpbi4gIElmIGNv cnJlY3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG8NCiAgICAgICAg IGJlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNv IGluIHRoaXMNCiAgICAgICAgIGNhc2UuDQoNCiAgICAgICAgIDxlbmQgc25pcD4NCg0KICAgICAg ICAgSW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExT IE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksDQogICAgICAgICBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkg Y291bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IGNvdWxkIHlvdSB2ZXJpZnkgYQ0K ICAgICAgICAgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBNb3JlIHRleHQg d2lsbCBoZWxwLiBBbHNvLCBtb3JlDQogICAgICAgICBpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFy bGllciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUw0KICAgICAgICAg T0FNIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRjLiBJZiBzbywg aXQgY29udHJhZGljdHMgaGVyZS4NCltSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0DQotIHdp dGhvdXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVzIGEgc2V0IG9mIHBhdGhz IG9ubHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCi0gaWYgdGhlIG9wZXJh dG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVzcG9uZHMgdG8gY29u dHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxpZWQuDQpJZiB5b3Ug dW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRl cyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdvcmQgaXQuDQolc2FtIC0gVGhl IHByb2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlv dSBoYXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQpJIGRlZmluaXRlbHkgc2VlIGEgc3BlY2lmaWMg bmVlZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1c2UgY2FzZSBpcyB0b28g bXVjaCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1dGlvbi4NCk9uY2UgeW91 IHJlbW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNob3Vs ZCBiZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJl cXVpcmVtZW50cyBmb3IgYSBzb2x1dGlvbi4NCkZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVi bGlzaCBhIHNlcGFyYXRlIElELg0KDQoNCiAgICAgICAgIDcuIExhc3QgYnV0IG5vdCB0aGUgbGVh c3QsIGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFuZCBOTVM/DQogICAgICAgICBTb21l aG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQN CiAgICAgICAgIE5NUy9FTVMgY291bGRuJ3QuDQpbUkddIEkndmUgbmV2ZXIgaGVhcmQgb2YgYW4g RU1TL05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCB1c2VzIHRoaXMgdG9wb2xv Z3kgYXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0aW5nIExTUCBj b21iaW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBi ZWVuIGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29yayBmb3Igd291bGRu J3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQolc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdo aWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3Bl Y2lmaWMgb3BlcmF0aW9ucyAgZm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5IHBlcmZvcm0g VHJlZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0aXBhdGguIEFsc28gcGVyZm9ybSBM U1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFp bGFibGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0aCBtdWx0aXBhdGguIFlvdSBjb3VsZCBh dXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNp bmcgcHJvYmUgdGVjaG5vbG9neS4gV2lsbCBub3Qgc2F5IGJleW9uZCB0aGF0IDpEDQoNCmNoZWVy cw0KLXNhbQ0KDQoNCg== --_000_CECE764681BE964CBE1DFF78F3CDD3941E2651F1xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5 bGUtbmFtZTrmibnms6jmoYbmlofmnKw7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+ac rCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bh bi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250 LWZhbWlseTpTaW1TdW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo2MTA4MTYyMzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0yMDg0NDIwNDcyIDI2OTAyNTI5NSAyNjkwMjUzMDUgMjY5MDI1MzA3IDI2OTAy NTI5NSAyNjkwMjUzMDUgMjY5MDI1MzA3IDI2OTAyNTI5NSAyNjkwMjUzMDUgMjY5MDI1MzA3O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjg2MTU1MDgyOTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NjA1MTQ4MjAgMjY5 MDI1Mjk1IDI2OTAyNTMwNSAyNjkwMjUzMDcgMjY5MDI1Mjk1IDI2OTAyNTMwNSAyNjkwMjUzMDcg MjY5MDI1Mjk1IDI2OTAyNTMwNSAyNjkwMjUzMDc7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBRaW4sIGV0IGFsLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RWFjaCBu ZXR3b3JrIG5vZGUgd2lsbCBzdGlsbCBoYXZlIHNvbWUgc3RhdGVzIChpLmUuIG5vZGUvYWRqYWNl bmN5L3NlcnZpY2Ugc2VnbWVudHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzZWUgdGhlIHRlY2huaXF1ZSBkZXNj cmliZWQgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UgYXMgYSB3YXkgdG8gbW9uaXRvciB0 aGUgbmV0d29yaywgYnV0IG5vdCBhIHdheSB0byB2YWxpZGF0ZSB0aGUgc2VnbWVudHMuIEluIHBh cnRpY3VsYXIgdGhlIGZvbGxvd2luZw0KIGFzcGVjdHMgY2Fubm90IGJlIHZhbGlkYXRlZCBieSB0 aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVzaW5nIGEg c2VnbWVudCBvciBjb21iaW5hdGlvbiBvZiBzZWdtZW50cyByZXN1bHQgaW4gYSBwYWNrZXQgdG8g cmVhY2ggYW4gZXhwZWN0ZWQgbmV0d29yayBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vc2luZyBhbiBh ZGphY2VuY3kgc2VnbWVudCByZXN1bHRzIGluIGEgcGFja2V0IHRvIHRyYXZlcnNlIG92ZXIgYW4g ZXhwZWN0ZWQgYWRqYWNlbmN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vc2luZyBhIHNlcnZpY2Ugc2VnbWVu dCByZXN1bHRzIGluIGEgcGFja2V0IHRvIGhpdCBhbiBleHBlY3RlZCBzZXJ2aWNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhpcyBpcyB3aHkgSSBwcmV2aW91c2x5IG1lbnRpb25lZCB0aGF0IHRoZSB0ZWNobmlxdWUg aXMgdXNlZnVsIGFzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPm9uZSBvZiB0aGUgT0FNcyB1c2VkIHRv IG1vbml0b3IgdGhlIG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBvdGhlciB3b3Jkcywgd2Ugd291bGQg c3RpbGwgd2FudCB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdmFsaWRhdGUgdGhlIHN0YXRlcyBvbiBl YWNoIG5ldHdvcmsgbm9kZSBzbyB0aGF0LCB3aGVuIGluZ3Jlc3NlcyBzdGVlciBwYWNrZXRzIHVz aW5nIGNvbWJpbmF0aW9ucw0KIHNlZ21lbnRzICh0aGF0IG1ha2VzIHVzZSBvZiB0aG9zZSBzdGF0 ZXMpLCB0aGVuIGV4cGVjdGVkIGFuZCBhY3R1YWwgcGF0aHMgYWxpZ25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBp bnRlbnRpb25hbGx5IGRpZG7igJl0IGFuc3dlciB5b3VyIHF1ZXN0aW9uIG9uIHRoZSB1c2VmdWxu ZXNzIG9mIFByb3h5IExTUCBQaW5nIG4gU2VnbWVudCBSb3V0aW5nLCBidXQgSSB3YW50ZWQgdG8g aGlnaGxpZ2h0IHdoYXQgYXJlIHRoZSBhZGRpdGlvbmFsIHBvaW50cw0KIHdlIHdvdWxkIHdhbnQg dG8gY292ZXIgZnJvbSBPQU0gcGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tTm9ibzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUWluIFd1IFtt YWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVs eSAxNCwgMjAxNCA1OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBOb2JvIEFraXlhIChub2JvKTsgU2Ft IEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmc7 IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb c3ByaW5nXSBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlZlcnkgZ29vZCBwb2ludCwgc2luY2Ug c2VnbWVudCByb3V0aW5nIGRvZXNu4oCZdCByZXF1aXJlIGVhY2ggbmV0d29yayBub2RlIGluIHRo ZSBwYXRoIHRvIG1haW50YWluIHN0YXRlIGFuZCBvbmx5IGluZ3Jlc3MNCiBub2RlIG1haW50YWlu cyB0aGUgc3RhdGUgd2hpbGUgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Qcm94eS1sc3AtcGluZyByZXF1aXJlIGVh Y2ggbmV0d29yayBub2RlIGluIHRoZSByZXR1cm4gcGF0aCB0byBtYWludGFpbiB0aGUgc3RhdGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5XaHkgYXBwbHkgUHJveHktbHNwLXBpbmcgdG8gc3ByaW5nIE9BTT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi1RaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ 5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBzcHJpbmcgWzxh IGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj7ku6PooagNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Tm9ibyBBa2l5YSAobm9ibyk8YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4N CiAyMDE0PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuW5tDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj43PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4xMTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7ml6U8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1 bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogMzowMDxicj4NCjwvc3Bhbj48Yj48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPg0KIFNhbSBBbGRyaW47IDxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5H ZWliQHRlbGVrb20uZGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvYT48YnI+DQo8L3NwYW4+ PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5oqE6YCBPC9zcGFuPjwvYj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4NCiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2Vj YXNlPGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS4u+mi mDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogUmU6IFtzcHJpbmddIFF1ZXN0 aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SGkgU2FtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SnVzdCB0byBwb2ludCBvdXQgb25lIHRoaW5nIGFi b3V0IHRoaXMgZG9jdW1lbnQg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgdGVzdCBwYWNrZXQgZ2VuZXJhdGVkIGZy b20gYSBQTVMvTk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4gaGF2ZSB0aGUgY29tcGxldGUgc2Vn bWVudCBzdGFjayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdvcmsgYXMNCiB3ZWxsIGFzIGhv dyB0byBjb21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBmdXJ0aGVyIHNpZ25hbGluZywgT0FN IHN0YXRlIG1haW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMgbm9yIE9BTSBpbnZvbHZlbWVudCBi eSBuZXR3b3JrIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhhdCBtYWtlcyB0aGlzIGFwcHJvYWNoIHF1aXRlIGRp ZmZlcmVudCBmcm9tIHVzaW5nIHByb3h5IExTUCBwaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhpcyBjZXJ0YWlubHkg aGFzIHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2Yg dGhlIE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPi1Ob2JvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4gc3ByaW5nDQogWzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+DQpPbiBCZWhhbGYgT2YgPC9iPlNh bSBBbGRyaW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjoxMyBQ TTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5k ZSI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPjxicj4NCjxiPkNjOjwvYj4gc3ByaW5nOyBk cmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nw cmluZ10gUXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGkgUnVlZGlnZXIs PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25z ZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T24gVGh1LCBKdWwgMTAsIDIwMTQg YXQgNzoxNSBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUi IHRhcmdldD0iX2JsYW5rIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIFNhbSw8YnI+DQo8YnI+DQpteSByZXBsaWVz IGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRkZWQgdG8geW91ciB0ZXh0Ljxicj4NCjxicj4NCi0gUHJv eHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBpcyBp bnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyAmIzQzOyBJUHY2KS4gV2UnbGwg Y2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC48YnI+DQotIFByb3h5LWxzcC1waW5nIGlzIGZvciBN UExTIExTUCBQaW5nIChSRkMgNDM3OSAvIFJGQyA2NDI0KSwgd2hpbGUgb3VyIHVzZSBjYXNlIGNh biB1c2UgYW55IE9BTSAoaW4gcGFydGljdWxhciwgc3BlY2lmaWMgZ29vZCB1c2VzIGZvciBCRkQs IGFuZCBJQ01QdjYpPGJyPg0KPGJyPg0KQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3 aXRoIGJyb2FkZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yIFNQUklORyBhcyBhIHdob2xlLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiVzYW0gLSBJIGJlbGlldmUg eW91IHNheSBpdCBpcyB1c2UgY2FzZSBkb2N1bWVudCBiZWxvdy4gVGhlbiBzb2x1dGlvbiBpcyB0 b28gcHJlbWF0dXJlIGF0IHRoaXMgcG9pbnQgb2YgdGltZSwgYXMgd2UgaGF2ZW4ndCBkZWxpYmVy YXRlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIGVpdGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48YnI+DQpBcyB5b3Ugd3JpdGUsIFNSIGJhc2VkIE9BTSBwYXJ0aWFsbHkgb2Zm ZXJzIHNpbWlsYXIgZnVuY3Rpb25zIGFzIHByb3h5LWxzcC4gV2l0aG91dCByZXF1aXJpbmcgdGhl IGFkZGl0aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9MU1IgcHJvY2Vzc2luZyBpbnRyb2R1Y2VkIGJ5 IHByb3h5LWxzcC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJy Pg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpSdWVkaWdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgU2FtIEFsZHJpbiB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyBJIGhhdmUgZmV3IHF1ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0Ljxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcgdG8gbWUuIEl0 IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgaXQgc2F5cyB0aGUgZm9sbG93aW5nPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmx0O3NuaXAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGFuZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNh c2VzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBzb2x1dGlvbiBp cyBkZXNjcmliZWQgZm9yIGEgc2luZ2xlIElHUCBNUExTIGRvbWFpbi48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc29sdXRpb24gYXBwbGllcyB0byBtb25pdG9yaW5n IG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7bW9uaXRvcmluZyBvZiBTZWdtZW50IFJvdXRlZCBMU1Ancy48YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7ZW5kIHNuaXAmZ3Q7PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7SW4gZmFjdCB0aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNvbHV0aW9uIHRvIGNlcnRh aW4gc2NlbmFyaW9zIGFuZCBub3QganVzdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3Byb3ZpZGluZyB1c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNl IGNhc2UgZHJhZnQgc2hvdWxkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1l bnQgc2NlbmFyaW9zIHdoZXJlIGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVpcmVtZW50cy4gU29sdXRp b25zIGNvdWxkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgY292ZXJlZCB3aXRo IGV4aXN0aW5nIHRvb2xzZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5nIG9uIHRoZSBHQVA8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmFseXNpcy4gQnV0IHRoYXQgc2hvdWxk IGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhhbiAxIHNvbHV0aW9uLDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZXJlIGFzIHRoaXMgZG9jdW1lbnQgY291bGQg anVzdCBmb2N1cyBvbiB1c2UgY2FzZXMgb25seS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtJZiBpbmZhY3QgdGhpcyBpcyBzdXBwb3NlZCB0byBiZSBhIHNvbHV0aW9uIGRv Y3VtZW50LCB0aGVuIGNoYW5naW5nIHRoZSB0aXRsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3dvdWxkIGJlIG1vcmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15IG9ic2VydmF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5bUkddIFRoYW5rcy4gSXQncyBhIHVz ZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiVzYW0gLSBPSy4g dGhlbiBJJ2QgbGlrZSB0byBzZWUgYW55IHNwZWNpZmljIHNvbHV0aW9uIGNvbnRlbnQgcmVtb3Zl ZCwgdGhhdCB3YXkgd2UgZG9udCBoYXZlIHRvIGRpc2N1c3Mgd2hhdCBvdGhlciBzb2x1dGlvbnMg ZG9lcyBlaXRoZXIgb3IgY29tcGFyZSB3aXRoIDpEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsyLiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMg YmVpbmcgc29sdmVkIHdpdGg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtk cmFmdC1pZXRmLW1wbHMtcHJveHktbHNwLXBpbmctMDImcXVvdDsgLiBXaGF0IGlzIGJlaW5nIGRl c2NyaWJlZCBpbiB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VjdGlvbiBj b3VsZCBiZSBkb25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRpb24gd2lzZSkgd2hlcmUsIHJl cXVlc3QgY291bGQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBzZW50IHRvIG1v bml0b3IgTEVSIGkgYW5kIExFUiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3Rh bmRpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyaWdodD8gSWYgbm90LCBob3cg aXMgaXQgZGlmZmVyZW50IGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0 YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO2No YWluIG9mIE1QTFMgTFNQcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4lc2FtIC0gRXhlY3V0ZSB5b3UgbWVhbiB0cmF2ZXJzZT8gb3IgcGVyZm9ybSBz b21ldGhpbmcgZWxzZT8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQpb UkddIFByb3h5LWxzcCBzYXlzOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgcHJvdG9jb2wgZXh0ZW5z aW9ucyB0byBNUExTIHBpbmcgW1JGQzQzNzldIHRvPGJyPg0KJm5ic3A7ICZuYnNwO2FsbG93IGEg dGhpcmQgcGFydHkgdG8gcmVtb3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2Fn ZSB0bzxicj4NCiZuYnNwOyAmbmJzcDtiZSBzZW50IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBM U1AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+JXNh bSAtIElmIGl0IGlzIHByb3Bvc2luZyBleHRlbnNpb25zLCAmbmJzcDtpdCBoYXMgdG8gYmUgc29s dXRpb24gZG9jdW1lbnQgJm5ic3A7YW5kIGNhbm5vdCBjbGFpbSB0byBiZSB1c2UgY2FzZSBkb2N1 bWVudC4gQWxzbyB0aGlzIGRvY3VtZW50IGlzIG9uIGluZm9ybWF0aW9uIHRyYWNrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0 IGlmIHlvdSdkIGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkg b24gYW55IExTUCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBU aGUgUE1TIGhvd2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkczxicj4NCmZ1bmN0aW9uYWxpdHk6PGJy Pg0KYSkgWW91IGRvbid0IG5lZWQgYW4gYWRkaXRpb25hbCBwcm90b2NvbCBvciBmdW5jdGlvbmFs aXR5IGxpa2UgcHJveHktcGluZyB0byBjaGVjayBkYXRhPGJyPg0KJm5ic3A7ICZuYnNwO3BsYW5l IGxpdmVsaW5lc3MsIFJGQzQzNzkgaXMgZmluZS4gRGV1dHNjaGUgVGVsZWtvbSBvcGVyYXRlcyBh IFBNUyBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4lc2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIGRhdGFw bGFuZSBhbmQgYWxzbyBmaW5kIG91dCBsb3QgbW9yZSBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNoZWNrcy4gRm9yIGxpdmVuZXNz IGRldGVjdGlvbiwgQkZEIGlzIHByZWZlcnJlZCB0b29sLCBhdGxlYXN0DQogaW4gcHJlc2VudCBk ZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1TIHNvbHV0aW9uIGlzIGRlc2lnbmVkIGZv ciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5vdCB0byBwZXJmb3JtIHZhbGlkYXRpb24gb2YgZGF0 YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBldGM/IChJIHRoaW5rIHlvdSBhZ3JlZSB0byB0aGlz IGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxzbyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PmIpIG9uY2UgUE1TIGRldGVjdGVkIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcyBhbmQgY29ycmVjdG5l c3Mgb2YgTVBMUyB0b3BvbG9neSBieSBSRkM0Mzc5LDxicj4NCiZuYnNwOyAmbmJzcDtpdCBjYW4g Y29udGludWUgdG8gZXhlY3V0ZSBhcmJpdHJhcnkgTFNQIGNvbWJpbmF0aW9ucyBhbmQgdGhlIG1v bml0b3JpbmcgcGFja2V0cyBzdGF5PGJyPg0KJm5ic3A7ICZuYnNwO2luIGRhdGEgcGxhbmUuIFBs ZWFzZSBwb2ludCBtZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVh dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4l c2FtIC0gVGhpcyB5b3UgY291bGQgcGVyZm9ybSBldmVuIHdpdGhvdXQgcHJveHkgcGluZy4gVGhl IGZ1bmN0aW9uIHlvdSBhcmUgZGVzY3JpYmluZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0 aGVyIHRoYW4gd2hhdCBsc3AgcGluZyBkb2VzLiBBZ2FpbiBJIGFtIG5vdCB0YWxraW5nIGFib3V0 IG5vbi1tcGxzIHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0gUGVyZm9ybSB0cmVldHJhY2Ugd2l0 aCByZmM0Mzc5IHRvIGdldCB0b3BvbG9neSBpbmZvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4tIHBpY2sgYW55IGFyYml0YXJ5IExTUCBwYXRocyBkaXNjb3ZlcmVk IGFsb25nIHdpdGggaXRzIG11bHRpcGF0aCBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0gcGVyZm9ybSBwaW5nIHdpdGggcmlnaHQgc2Vs ZWN0b3JzIGZvciB0aGUgcGF0aCBhbmQgdXNlIFRUTCBmb3IgbGltaXRpbmcgdGhlIGhvcCBbTEVS IGpdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+LSBpZiB5b3Ug d2FudCB0byBwZXJmb3JtIGZyb20gTEVSIGkgdG8gTEVSIGogYXMgaW4geW91ciBkcmFmdCwgdXNl IHByb3h5IHBpbmcgdG8gc3RhcnQgZnJvbSBMRVIgaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50IGJhY2sgdG8gUE1T IHdoaWNoIGlzIG5vdCBwYXJ0IG9mIE1QTFMgb3Igc2VnbWVudDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBkb21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1cml0eSBhc3BlY3Qs IHdoaWNoIG5lZWRzIHRvIGNvbnNpZGVyZWQuIEkgYmVsaWV2ZTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBpdCBhcHBsaWVzIHRvIHNlbmRpbmcgYSByZXF1ZXN0IHRvby4gV2lsbCB5 b3UgYmUgZG9jdW1lbnRpbmcgdGhhdCBhc3BlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPltSR10gVGhhdCdzIGEgdmFsaWQgcG9pbnQuIFRoZSBkb21haW4gZXh0ZXJuYWwg c3lzdGVtIGlzIG9uZSBvcHRpb24gYW5kIHRoZSB0ZWFtIHdpbGwgZGVhbCB3aXRoIHRoZSBzZWN1 cml0eSBhc3BlY3RzIHJhaXNlZCBieSB0aGlzIG9wdGlvbiBvbmNlIHdlIGFyZSBpbiBzb2x1dGlv biBzcGFjZS4gV2Ugd2lsbCBub3QgYW5hbHlzZSB0aGlzDQogaW4gZGVwdGggZm9yIGEgdXNlIGNh c2UgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+JXNhbSAtIG5vZCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA0LiBTZWMgMy4yIHRvIG1vbml0b3IgYnVuZGxlIGxpbmtzLCBvbmUgY291bGQgcGVy Zm9ybSB0aGF0IHdpdGggUkZDNDM3OSBwaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHdpdGggbXVsdHBhdGggJiM0MzsgcHJveHkgcGluZy4gQ291bGQgeW91IGtpbmRseSBkaWZm ZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBuZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5bUkddIFRoZSBTUiBPQU0gYXV0aG9yIHRlYW0gaGFzIHByb3ZpZGVk IHRleHQgaG93IHRvIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0 LiBZb3UgYXJlIGEgY28tYXV0aG9yIG9mIHByb3h5LWxzcC4gSSBjb3VsZG4ndCBmaW5kIGV4cGxp Y2l0IHRleHQgb24gaG93IHRvIGRldGVjdCBhbmQgbW9uaXRvciBhIGJ1bmRsZWQNCiBsaW5rIGlu IGRyYWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhvdyBwcm94eS1sc3AgY2FuIGJlIHVz ZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkgaWYgdGhpcyBpcyBvYnZpb3VzIGFu ZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyB0byB0aGUgU1IgT0FNIGFw cHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+JXNhbSAtIFRoZSBzYW1lIHN0ZXBzIGRlc2NyaWJlZCBhYm92 ZSBjb3VsZCBiZSB1c2VkIGlmIGVhY2ggYnVuZGxlZCBsaW5rIG1lbWJlciBpcyBpZGVudGlmaWVk IHdpdGggYSB1bmlxdWUgbGFiZWwuIFdoaWxlIHBlcmZvcm1pbmcgdHJlZSB0cmFjZSBvciBwaW5n IHdpdGggbXVsdGlwYXRoLCBMRVIgaSB3aWxsIHJlc3BvbmQgd2l0aCBERE1BUA0KIGluZm8gZm9y IGVhY2ggb2YgdGhlIGxpbmtzIGFuZCB0aGUgbXVsdGlwYXRoIGluZm8gZm9yIHRoZSBzYW1lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgeW91IHNheSB0aGF0 IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUgbGFiZWwgc3RhY2ssIHRoZW4geW91IGNvdWxkIHVz ZSBsc3Agc2VsZWN0b3JzIGFzIGRlZmluZWQgaW4gUkZDNDM3OSwgaW4gdGhpcyBjYXNlIGl0IGlz IGxvY2FsIGhvc3QgZGVzdCBpcCBhZGRyLCB0byBpZGVudGlmeSBlYWNoIGxpbmsgbWVtYmVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Tm93IGlmIHRoZSBNUExT IGZvcndhcmRpbmcgbGF5ZXIgc2VlcyB0aGUgYnVuZGxlZCBsaW5rIGFzIG9uZSBpbnRlcmZhY2Ug YnV0IGNhbm5vdCBkaXNjZXJuIGl0cyBsaW5rIG1lbWJlcnMsIHRoZW4geW91IGNvdWxkIG9ubHkg dmFsaWRhdGUgdGhlIGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRpdmlkdWFsIG1lbWJlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TYW1lIGFwcGxpZXMgaW4g eW91ciBjYXNlIHRvby4gQ2Fubm90IHNlZSBob3cgaXQgaXMgZGlmZmVyZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzUuIHNlYyAjNSwgSXMgdGhlIHJl cXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3BvbG9neSwgaW4gdGhl PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FzZSBvZiBt aXhlZCBlbnY/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPltSR10gTVBMUyB0 b3BvbG9neSBhd2FyZW5lc3MgaXMgdGhlIHByZWNvbmRpdGlvbiB0byBzZXQgdXAgcGFja2V0cyB3 aXRoIGxhYmVsIHN0YWNrcyBleGVjdXRpbmcgYSBkZXNpcmVkIGNoYWluIG9mIExTUHMuIElmIHN1 aXRhYmxlIExhYmVsL0ZFQy9ub2RlIHJlbGF0aW9uIGlzIGtub3duIHRvIHRoZSBQTVMsIHRoYXQg TFNQIGNhbiBiZSBleGVjdXRlZA0KIGZyb20gdGhhdCBub2RlIG9uIGJ5IGEgUE1TIG1vbml0b3Jp bmcgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiVzYW0gLSBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCB5b3Ugc3RpbGwgbmVlZCB0byBwZXJm b3JtIFJGQzQzNzkgdHJhY2Ugb3IgdHJlZXRyYWNlIHRvIGdldCB0b3BvbG9neS4gSSBkbyBub3Qg dGhpbmsgSUdQIGV4dGVuc2lvbnMgYmVpbmcgcHJvcG9zZWQgaW4gU1BSSU5HIGV4cG9ydCBhbnkg b2YgdGhlIGluZm8gb3RoZXIgdGhhbiBsYWJlbA0KIHN0YWNrLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QW5kIHRoZSBwcm9wb3NlZCBQTVMgc29sdXRp b24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwgaXQgcGVyZm9ybXMgb24gZGVtYW5kIHBlciBzZWdt ZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28gZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgdG9w b2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgY2Fz ZSB5b3UgYXJlIG1ha2luZyBpcyB0aGF0IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9m IFJGQzQzNzkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlF1ZXN0aW9uIEkg aGF2ZSBmb3IgeW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMgYXJlIGdldHRpbmcgZHJvcHBl ZCBhbmQgUE1TIHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4gTFNQIG9yIFNlZ21l bnQsIGhvdyBkbyB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cg ZG8geW91IGZpZ3VyZQ0KIG91dCB3aGVyZSBpdCBpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPkF0IGxlYXN0IHdpdGggUkZDNDM3OSBhbmQvb3IgcHJveHkgcGlu ZywgeW91IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIGJlY2F1c2Ugb2YgdGhlIGJlbGxzIGFuZCB3 aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25nIHdpdGggdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs2LiBJbiBzZWMgMy4xLDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7c25pcCZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGV0ZXJtaW5pbmcgYSBwYXRoIHRvIGJlIGV4ZWN1dGVk IHByaW9yIHRvIGEgbWVhc3VyZW1lbnQgbWF5IGFsc28gYmU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZG9uZSBieSBzZXR0aW5nIHVwIGEgbGFiZWwgaW5jbHVkaW5nIGFs bCBub2RlIFNJRHMgYWxvbmcgdGhhdCBwYXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyhpZiBMRVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQg c2hvdWxkIGJlIHBhc3NlZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDti ZXR3ZWVuIExFUiBpIGFuZCBMRVIgaiwgdGhlIGxhYmVsIHN0YWNrIGlzIDIwIC0gNDAgLSAzMCAt IDEwKS4gJm5ic3A7VGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fk dmFudGFnZSBvZiB0aGlzIG1ldGhvZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMg T0FNPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Z1bmN0aW9uYWxpdHkg YW5kIGl0IGlzIGluZGVwZW5kZW50IG9mIEVDTVAgZnVuY3Rpb25hbGl0aWVzLiAmbmJzcDtUaGU8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0aG9kIHN0aWxsIGlzIGFi bGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9mPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuIE1QTFMgZG9tYWluLiAmbmJzcDtJ ZiBjb3JyZWN0IGZvcndhcmRpbmcgYWxvbmcgdGhlIGRlc2lyZWQgcGF0aHMgaGFzIHRvPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIGNoZWNrZWQsIFJGQzQ3MzkgZnVu Y3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNvIGluIHRoaXM8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2FzZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2VuZCBzbmlwJmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbiB0aGUgYWJvdmUgeW91IG1lbnRpb24gdGhhdCBpdCBk b2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNLiBCdXQgbGF0ZXIgeW91IHNheSw8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDNDM3OSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJl IHVzZWQuIENvdWxkIHlvdSBjbGFyaWZ5IGhvdyBjb3VsZCB5b3UgdmVyaWZ5IGE8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlz IG5vdCBkb25lLiBNb3JlIHRleHQgd2lsbCBoZWxwLiBBbHNvLCBtb3JlPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ltcG9ydGFudGx5LCB0aGUgdGV4dCBlYXJsaWVyIHRv IHRoZSBhYm92ZSBzYXlzLCBmb3IgdmFsaWQgcmVzdWx0LCBNUExTPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO09BTSBoYXMgdG8gYmUgcGVyZm9ybWVkIGZvciB0b3BvbG9n eSBjaGFuZ2VzIGV0Yy4gSWYgc28sIGl0IGNvbnRyYWRpY3RzIGhlcmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPltSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0PGJyPg0K LSB3aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVjdXRlcyBhIHNldCBvZiBw YXRocyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24uPGJyPg0KLSBpZiB0 aGUgb3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBwbGFuZSBjb3JyZXNwb25k cyB0byBjb250cm9sIHBsYW5lLCBSRkM0NzM5IGZ1bmN0aW9ucyBzaG91bGQgYmUgYXBwbGllZC48 YnI+DQpJZiB5b3UgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRleHQgaW4gdGhl IGRyYWZ0IHN0YXRlcyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdvcmQgaXQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+JXNhbSAt IFRoZSBwcm9ibGVtIEkgYW0gaGF2aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FN LCB5b3UgaGF2ZSB0byB2YWxpZGF0ZSB0aGUgbHNwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SSBkZWZpbml0ZWx5IHNlZSBhIHNwZWNpZmljIG5lZWQgZm9yIFNQ UklORywgYnV0IHdoYXQgSSBmZWVsIGlzLCB0aGUgdXNlIGNhc2UgaXMgdG9vIG11Y2ggY2F0ZXJl ZCB0byBhIHNwZWNpZmljIGVudmlzaW9uZWQgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbmNlIHlvdSByZW1vdmUgc29sdXRpb24gb3Igc3VnZ2Vz dGVkIGVuaGFuY2VtZW50cywgaG9wZSBpdCBzaG91bGQgYmUgY2xlYXIgb24gd2hhdCBpcyBiZWlu ZyBzb2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMgZm9yIGEgc29sdXRpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gb3Igc29sdXRpb24g cGFydCwgcGxlYXNlIHB1Ymxpc2ggYSBzZXBhcmF0ZSBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs3LiBMYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCBob3cgZGlmZmVy ZW50IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtTb21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBN UyBjb3VsZCBkbyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Tk1T L0VNUyBjb3VsZG4ndC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+W1JHXSBJ J3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9OTVMgd2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2Fy ZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBw YWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmluYXRpb25zIGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0 b3IuIEhhZCB0aGlzIGZlYXR1cmUNCiBiZWVuIGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBj b21wYW55IEkgd29yayBmb3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+JXNhbSAtIFRo ZXJlIGFyZSB0b29scyB3aGljaCBhcmUgcGFydCBvZiBOTVMvT1NTLCB3aGljaCBwZXJmb3JtcyBN UExTIHRvcG9sb2d5IHNwZWNpZmljIG9wZXJhdGlvbnMgJm5ic3A7Zm9yIGEgZ2l2ZW4gc2V0IG9m IExTUCdzLiBUaGV5IHBlcmZvcm0gVHJlZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0 aXBhdGguIEFsc28gcGVyZm9ybQ0KIExTUCBzcGVjaWZpYyB2YWxpZGF0aW9uIGJ5IGNyYWZ0aW5n IHBhY2tldHMgd2l0aCBkYXRhIGF2YWlsYWJsZSB3aXRoIHRyZWV0cmFjZSBhbmQgcGluZyB3aXRo IG11bHRpcGF0aC4gWW91IGNvdWxkIGF1dG9tYXRlIHRoZSB3b3JrZmxvdyB3aXRob3V0IHRoZSBu ZWVkIGZvciBPU1MvUE1TLCBieSB1c2luZyBwcm9iZSB0ZWNobm9sb2d5LiBXaWxsIG5vdCBzYXkg YmV5b25kIHRoYXQgOkQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Y2hlZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tc2FtPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CECE764681BE964CBE1DFF78F3CDD3941E2651F1xmbalnx01ciscoc_-- From nobody Mon Jul 14 05:59:08 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA89B1A03D4 for ; Mon, 14 Jul 2014 05:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPIox0QmLfvM for ; Mon, 14 Jul 2014 05:58:56 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573D21A03C5 for ; Mon, 14 Jul 2014 05:58:54 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 14 Jul 2014 14:58:16 +0200 X-IronPort-AV: E=Sophos;i="5.01,658,1400018400"; d="scan'208,217";a="621530208" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 14 Jul 2014 14:58:15 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 14 Jul 2014 14:58:15 +0200 From: To: Date: Mon, 14 Jul 2014 14:58:14 +0200 Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLwAKzC+wAABEV34AAHFKkw Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8D513E9HE111643EMEA1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Lc9drRpmmj6OHAt2khwVpQBnN-U Cc: spring@ietf.org, draft-geib-spring-oam-usecase@tools.ietf.org Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 12:59:02 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8D513E9HE111643EMEA1_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTm9ibywNCg0KdGhhbmtzLCBmdWxseSBjb3JyZWN0LiBUaGUgdXNlIGNhc2UgZGVzY3JpYmVz IGFuIExTUCBtb25pdG9yaW5nIG1ldGhvZC4gVG8gdmFsaWRhdGUgdGhlIExTUCBhbm90aGVyIHRv b2wgbXVzdCBiZSB1c2VkLiBBbiBleGFtcGxlIG9mIHRoZSBsYXR0ZXIgaXMgUkZDNDM3OSwgcHJv eHkgbHNwIG9yIHdoYXRldmVyIGVsc2UuIFRoZSB1c2UgY2FzZSB0ZXh0IHdpbGwgYmUgY2xhcmlm aWVkIGluIHRoZSBuZXh0IHZlcnNpb24gKGFuZCB0aGUgZXhwcmVzc2lvbiBzb2x1dGlvbiB3aWxs IGJlIHJlbW92ZWQpLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQpWb246IE5vYm8gQWtpeWEg KG5vYm8pIFttYWlsdG86bm9ib0BjaXNjby5jb21dDQpHZXNlbmRldDogTW9udGFnLCAxNC4gSnVs aSAyMDE0IDE0OjM5DQpBbjogUWluIFd1OyBTYW0gQWxkcmluOyBHZWliLCBSw7xkaWdlcg0KQ2M6 IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNCkJldHJlZmY6IFJFOiBbc3By aW5nXSBRdWVzdGlvbnMNCg0KSGkgUWluLCBldCBhbCwNCg0KRWFjaCBuZXR3b3JrIG5vZGUgd2ls bCBzdGlsbCBoYXZlIHNvbWUgc3RhdGVzIChpLmUuIG5vZGUvYWRqYWNlbmN5L3NlcnZpY2Ugc2Vn bWVudHMpLg0KDQpJIHNlZSB0aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBkcmFmdC1nZWliLXNwcmlu Zy1vYW0tdXNlY2FzZSBhcyBhIHdheSB0byBtb25pdG9yIHRoZSBuZXR3b3JrLCBidXQgbm90IGEg d2F5IHRvIHZhbGlkYXRlIHRoZSBzZWdtZW50cy4gSW4gcGFydGljdWxhciB0aGUgZm9sbG93aW5n IGFzcGVjdHMgY2Fubm90IGJlIHZhbGlkYXRlZCBieSB0aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBk cmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZS4NCg0KDQoxLiAgICAgICBVc2luZyBhIHNlZ21l bnQgb3IgY29tYmluYXRpb24gb2Ygc2VnbWVudHMgcmVzdWx0IGluIGEgcGFja2V0IHRvIHJlYWNo IGFuIGV4cGVjdGVkIG5ldHdvcmsgbm9kZS4NCg0KMi4gICAgICAgVXNpbmcgYW4gYWRqYWNlbmN5 IHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byB0cmF2ZXJzZSBvdmVyIGFuIGV4cGVjdGVk IGFkamFjZW5jeS4NCg0KMy4gICAgICAgVXNpbmcgYSBzZXJ2aWNlIHNlZ21lbnQgcmVzdWx0cyBp biBhIHBhY2tldCB0byBoaXQgYW4gZXhwZWN0ZWQgc2VydmljZS4NCg0KVGhpcyBpcyB3aHkgSSBw cmV2aW91c2x5IG1lbnRpb25lZCB0aGF0IHRoZSB0ZWNobmlxdWUgaXMgdXNlZnVsIGFzIG9uZSBv ZiB0aGUgT0FNcyB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQoNCkluIG90aGVyIHdvcmRz LCB3ZSB3b3VsZCBzdGlsbCB3YW50IHRoaW5ncyBpbiBhZGRpdGlvbiB0byB2YWxpZGF0ZSB0aGUg c3RhdGVzIG9uIGVhY2ggbmV0d29yayBub2RlIHNvIHRoYXQsIHdoZW4gaW5ncmVzc2VzIHN0ZWVy IHBhY2tldHMgdXNpbmcgY29tYmluYXRpb25zIHNlZ21lbnRzICh0aGF0IG1ha2VzIHVzZSBvZiB0 aG9zZSBzdGF0ZXMpLCB0aGVuIGV4cGVjdGVkIGFuZCBhY3R1YWwgcGF0aHMgYWxpZ25zLg0KDQpJ IGludGVudGlvbmFsbHkgZGlkbuKAmXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24gb24gdGhlIHVzZWZ1 bG5lc3Mgb2YgUHJveHkgTFNQIFBpbmcgbiBTZWdtZW50IFJvdXRpbmcsIGJ1dCBJIHdhbnRlZCB0 byBoaWdobGlnaHQgd2hhdCBhcmUgdGhlIGFkZGl0aW9uYWwgcG9pbnRzIHdlIHdvdWxkIHdhbnQg dG8gY292ZXIgZnJvbSBPQU0gcGVyc3BlY3RpdmUuDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KRnJv bTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogTW9uZGF5LCBKdWx5 IDE0LCAyMDE0IDU6MDggQU0NClRvOiBOb2JvIEFraXlhIChub2JvKTsgU2FtIEFsZHJpbjsgUnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGU+DQpD Yzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KU3ViamVjdDogUkU6IFtz cHJpbmddIFF1ZXN0aW9ucw0KDQpWZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQgcm91dGlu ZyBkb2VzbuKAmXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcGF0aCB0byBtYWlu dGFpbiBzdGF0ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0ZSB3aGls ZQ0KUHJveHktbHNwLXBpbmcgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcmV0dXJu IHBhdGggdG8gbWFpbnRhaW4gdGhlIHN0YXRlLg0KV2h5IGFwcGx5IFByb3h5LWxzcC1waW5nIHRv IHNwcmluZyBPQU0/DQoNClJlZ2FyZHMhDQotUWluDQrlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRv OnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTm9ibyBBa2l5YSAobm9ibykNCuWPkemA geaXtumXtDogMjAxNOW5tDfmnIgxMeaXpSAzOjAwDQrmlLbku7bkuro6IFNhbSBBbGRyaW47IFJ1 ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0K 5oqE6YCBOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQrkuLvpopg6IFJl OiBbc3ByaW5nXSBRdWVzdGlvbnMNCg0KSGkgU2FtLA0KDQpKdXN0IHRvIHBvaW50IG91dCBvbmUg dGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKYNCg0KVGhlIHRlc3QgcGFja2V0IGdlbmVyYXRl ZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1kZXZpY2UgY2FuIGhhdmUgdGhlIGNvbXBsZXRl IHNlZ21lbnQgc3RhY2sgb24gaG93IHRvIHRyYXZlcnNlIHRoZSBuZXR3b3JrIGFzIHdlbGwgYXMg aG93IHRvIGNvbWUgYmFjayB0byBzZWxmIHdpdGhvdXQgYW55IGZ1cnRoZXIgc2lnbmFsaW5nLCBP QU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0d29yayBub2RlcyBub3IgT0FNIGludm9sdmVtZW50 IGJ5IG5ldHdvcmsgbm9kZXMuDQoNClRoYXQgbWFrZXMgdGhpcyBhcHByb2FjaCBxdWl0ZSBkaWZm ZXJlbnQgZnJvbSB1c2luZyBwcm94eSBMU1AgcGluZy4NCg0KVGhpcyBjZXJ0YWlubHkgaGFzIHNv bWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9B TXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay4NCg0KVGhhbmtzIQ0K DQotTm9ibw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6 MTMgUE0NClRvOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU8bWFpbHRvOlJ1ZWRpZ2VyLkdlaWJA dGVsZWtvbS5kZT4NCkNjOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQpT dWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoNCkhpIFJ1ZWRpZ2VyLA0KDQpUaGFua3Mg Zm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZS4N Cg0KT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwgPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtv bS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBTYW0sDQoN Cm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuDQoNCi0g UHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBp cyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFuZSAoTVBMUyArIElQdjYpLiBXZSdsbCBj bGFyaWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Lg0KLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBM U1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2UgY2FzZSBjYW4gdXNl IGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBmb3IgQkZELCBhbmQg SUNNUHY2KQ0KDQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGggYnJvYWRlciBz Y29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuDQolc2FtIC0gSSBiZWxp ZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cuIFRoZW4gc29sdXRpb24g aXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9mIHRpbWUsIGFzIHdlIGhhdmVuJ3QgZGVs aWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBlaXRoZXIuDQoNCkFzIHlvdSB3cml0ZSwgU1Ig YmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJveHktbHNw LiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBhbmQgTEVSL0xTUiBw cm9jZXNzaW5nIGludHJvZHVjZWQgYnkgcHJveHktbHNwLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdl cg0KDQoNCiAgICAgIFNhbSBBbGRyaW4gd3JvdGU6DQoNCiAgICAgIEkgaGF2ZSBmZXcgcXVlc3Rp b25zIGFib3V0IHRoaXMgZHJhZnQuDQoNCiAgICAgIDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcg dG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxDQogICAgICBpdCBz YXlzIHRoZSBmb2xsb3dpbmcNCg0KICAgICAgPHNuaXA+DQogICAgICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IGFuZA0KICAgICAg IGlsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLg0KDQogICAgICAgVGhlIHNvbHV0aW9uIGlz IGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLg0KDQogICAgICAgVGhlIHNv bHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bw0K ICAgICAgIG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuDQogICAgICA8ZW5kIHNu aXA+DQoNCiAgICAgICBJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5nIGEgc29sdXRpb24g dG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0DQogICAgICAgcHJvdmlkaW5nIHVzZSBj YXNlcy9zY2VuYXJpb3MuIE15IHVuZGVyc3RhbmRpbmcgd2FzLCB1c2UgY2FzZSBkcmFmdCBzaG91 bGQNCiAgICAgICBkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBkcml2ZSBuZXcgcmVx dWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQNCiAgICAgICBiZSBjb3ZlcmVkIHdpdGggZXhpc3Rp bmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBlbmRpbmcgb24gdGhlIEdBUA0KICAgICAg IGFuYWx5c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhlcmUgY291bGQgYmUg bW9yZSB0aGFuIDEgc29sdXRpb24sDQogICAgICAgd2hlcmUgYXMgdGhpcyBkb2N1bWVudCBjb3Vs ZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Lg0KDQogICAgICAgSWYgaW5mYWN0IHRoaXMg aXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUg dGl0bGUNCiAgICAgICB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBteSBvYnNlcnZh dGlvbi4NCltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNhc2UgZG9jdW1lbnQuIFdlJ2xsIHJldmll dyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuDQolc2FtIC0gT0suIHRoZW4gSSdkIGxpa2UgdG8gc2Vl IGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIHRoYXQgd2F5IHdlIGRvbnQg aGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRpb25zIGRvZXMgZWl0aGVyIG9yIGNvbXBh cmUgd2l0aCA6RA0KDQoNCiAgICAgICAyLiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBz YW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIHdpdGgNCiAgICAgICAiZHJhZnQtaWV0Zi1tcGxz LXByb3h5LWxzcC1waW5nLTAyIiAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXMNCiAg ICAgICBzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJveHkgcGluZyhzb2x1dGlvbiB3 aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZA0KICAgICAgIGJlIHNlbnQgdG8gbW9uaXRvciBMRVIg aSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJzdGFuZGluZw0KICAg ICAgIHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT8NCltSR10gVGhlIFBN UyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4gZGF0YSBwbGFuZSBhbmQg ZXhlY3V0ZSBhIGRlc2lyZWQNCiAgICAgY2hhaW4gb2YgTVBMUyBMU1BzLg0KJXNhbSAtIEV4ZWN1 dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0gc29tZXRoaW5nIGVsc2U/DQoNCltSR10g UHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbCBleHRlbnNpb25z IHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG8NCiAgIGFsbG93IGEgdGhpcmQgcGFydHkgdG8gcmVt b3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bw0KICAgYmUgc2VudCBk b3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLg0KJXNhbSAtIElmIGl0IGlzIHByb3Bvc2luZyBl eHRlbnNpb25zLCAgaXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICBhbmQgY2Fubm90IGNs YWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24gaW5m b3JtYXRpb24gdHJhY2suDQoNCltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0IGlmIHlvdSdk IGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55IExT UCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBUaGUgUE1TIGhv d2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkcw0KZnVuY3Rpb25hbGl0eToNCmEpIFlvdSBkb24ndCBu ZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBsaWtlIHByb3h5LXBp bmcgdG8gY2hlY2sgZGF0YQ0KICAgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3OSBpcyBmaW5lLiBE ZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxlbWVudGF0aW9uLg0KJXNhbSAtIFJG QzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxhbmUgYW5kIGFsc28gZmluZCBvdXQg bG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIHBlcmZv cm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVm ZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRlcGxveW1lbnRzLlNvIGFyZSB5b3Ugc2F5 aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9yIGxpdmVuZXNzIGRldGVjdGlvbiBhbmQg bm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRhIHBsYW5lIHRvIGNvbnRyb2wgcGxhbmUs IGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMgaW4gdGhlIGxhdGVyIHBhcnQgb2YgdGhl IGRvYyBhbHNvKQ0KDQpiKSBvbmNlIFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3Mg YW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSwNCiAgIGl0IGNhbiBj b250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9u aXRvcmluZyBwYWNrZXRzIHN0YXkNCiAgIGluIGRhdGEgcGxhbmUuIFBsZWFzZSBwb2ludCBtZSB0 byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVhdHVyZS4NCiVzYW0gLSBU aGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rp b24geW91IGFyZSBkZXNjcmliaW5nIGlzLCBob3cgeW91IHVzZSBsc3AgcGluZyByYXRoZXIgdGhh biB3aGF0IGxzcCBwaW5nIGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9uLW1w bHMgdG9wb2xvZ3kuDQpUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLg0K LSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5IGluZm8NCi0g cGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVs dGlwYXRoIGltcGxlbWVudGF0aW9uLg0KLSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxlY3Rv cnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIgal0u DQotIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBMRVIgaiBhcyBpbiB5b3Vy IGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpDQoNCiAgICAgICAgMy4g V2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRvIFBNUyB3aGljaCBpcyBub3QgcGFydCBv ZiBNUExTIG9yIHNlZ21lbnQNCiAgICAgICAgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2Vj dXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmUNCiAgICAg ICAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91IGJlIGRvY3Vt ZW50aW5nIHRoYXQgYXNwZWN0Pw0KW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRvbWFp biBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0gd2lsbCBkZWFsIHdp dGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJl IGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9y IGEgdXNlIGNhc2UgZG9jdW1lbnQuDQolc2FtIC0gbm9kDQoNCiAgICAgICAgNC4gU2VjIDMuMiB0 byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRoIFJGQzQz NzkgcGluZw0KICAgICAgICB3aXRoIG11bHRwYXRoICsgcHJveHkgcGluZy4gQ291bGQgeW91IGtp bmRseSBkaWZmZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZw0KICAgICAgICBuZXcgdGhl IHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KW1JHXSBUaGUgU1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBw cm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIHRoZSB1c2UgY2Fz ZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3AuIEkgY291bGRuJ3QgZmlu ZCBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBkZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVkIGxp bmsgaW4gZHJhZnQtcHJveHktbHNwLiBQbGVhc2UgZGVzY3JpYmUgaG93IHByb3h5LWxzcCBjYW4g YmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIChzb3JyeSBpZiB0aGlzIGlzIG9idmlv dXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBP QU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS4NCiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBk ZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIg aXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUg dHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNwb25kIHdpdGggRERN QVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBhdGggaW5mbyBmb3Ig dGhlIHNhbWUuDQpJZiB5b3Ugc2F5IHRoYXQgZWFjaCBsaW5rIG1lbWJlciBoYXMgc2FtZSBsYWJl bCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBzZWxlY3RvcnMgYXMgZGVmaW5lZCBpbiBS RkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdCBkZXN0IGlwIGFkZHIsIHRvIGlk ZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQpOb3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBsYXll ciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBidXQgY2Fubm90IGRpc2Nl cm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2YWxpZGF0ZSB0aGUgaW50 ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy4NClNhbWUgYXBwbGllcyBpbiB5 b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuDQoNCg0KDQogICAg ICAgICA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVudCBoZXJlIG9ubHkgZm9yIFBNUyB0byBs ZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZQ0KICAgICAgICAgICAgY2FzZSBvZiBtaXhlZCBlbnY/ DQpbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24gdG8gc2V0 IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhlY3V0aW5nIGEgZGVzaXJlZCBjaGFpbiBv ZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9kZSByZWxhdGlvbiBpcyBrbm93biB0byB0 aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQ TVMgbW9uaXRvcmluZyBwYWNrZXQuDQolc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91 IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRyZWV0cmFjZSB0byBnZXQg dG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2VkIGlu IFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFiZWwgc3RhY2suDQpB bmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBpcyB0aGF0LCBpdCBw ZXJmb3JtcyBvbiBkZW1hbmQgcGVyIHNlZ21lbnQsIHdoaWNoIFByb3h5IHBpbmcgYWxzbyBkb2Vz LCBhbGJlaXQgb25seSBmb3IgTVBMUyB0b3BvbG9neS4NClRoZSBjYXNlIHlvdSBhcmUgbWFraW5n IGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS4NCg0KUXVl c3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEgcGxhbmUgcGFja2V0cyBhcmUgZ2V0dGlu ZyBkcm9wcGVkIGFuZCBQTVMgcGFja2V0cyBnb2luZyB0aHJvdWdoLCBmb3IgYSBnaXZlbiBMU1Ag b3IgU2VnbWVudCwgaG93IGRvIHlvdSBrbm93IHRoZXJlIGlzIGEgcHJvYmxlbT8gaWYgeW91IGtu b3csIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBpdCBpcz8NCkF0IGxlYXN0IHdpdGggUkZD NDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIGJlY2F1 c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25nIHdpdGggdGhlIHBh Y2tldC4NCg0KDQoNCiAgICAgICAgIDYuIEluIHNlYyAzLjEsDQogICAgICAgICA8c25pcD4NCiAg ICAgICAgIERldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlvciB0byBhIG1lYXN1 cmVtZW50IG1heSBhbHNvIGJlDQogICAgICAgICBkb25lIGJ5IHNldHRpbmcgdXAgYSBsYWJlbCBp bmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IHBhdGgNCiAgICAgICAgIChpZiBMRVIx IGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxkIGJlIHBhc3NlZA0K ICAgICAgICAgYmV0d2VlbiBMRVIgaSBhbmQgTEVSIGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAt IDQwIC0gMzAgLSAxMCkuICBUaGUNCiAgICAgICAgIGFkdmFudGFnZSBvZiB0aGlzIG1ldGhvZCBp cywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNDQogICAgICAgICBmdW5jdGlvbmFs aXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gIFRoZQ0K ICAgICAgICAgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21iaW5h dGlvbnMgb2YgYWxsIHBhdGhzIG9mDQogICAgICAgICBhbiBNUExTIGRvbWFpbi4gIElmIGNvcnJl Y3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBwYXRocyBoYXMgdG8NCiAgICAgICAgIGJl IGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNvIGlu IHRoaXMNCiAgICAgICAgIGNhc2UuDQoNCiAgICAgICAgIDxlbmQgc25pcD4NCg0KICAgICAgICAg SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9B TS4gQnV0IGxhdGVyIHlvdSBzYXksDQogICAgICAgICBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgY291 bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IGNvdWxkIHlvdSB2ZXJpZnkgYQ0KICAg ICAgICAgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBNb3JlIHRleHQgd2ls bCBoZWxwLiBBbHNvLCBtb3JlDQogICAgICAgICBpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGll ciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUw0KICAgICAgICAgT0FN IGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRjLiBJZiBzbywgaXQg Y29udHJhZGljdHMgaGVyZS4NCltSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0DQotIHdpdGhv dXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVzIGEgc2V0IG9mIHBhdGhzIG9u bHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCi0gaWYgdGhlIG9wZXJhdG9y IHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxhbmUgY29ycmVzcG9uZHMgdG8gY29udHJv bCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxpZWQuDQpJZiB5b3UgdW5k ZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRlcyBz b21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdvcmQgaXQuDQolc2FtIC0gVGhlIHBy b2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlvdSBo YXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQpJIGRlZmluaXRlbHkgc2VlIGEgc3BlY2lmaWMgbmVl ZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMsIHRoZSB1c2UgY2FzZSBpcyB0b28gbXVj aCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25lZCBzb2x1dGlvbi4NCk9uY2UgeW91IHJl bW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNob3VsZCBi ZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJlcXVp cmVtZW50cyBmb3IgYSBzb2x1dGlvbi4NCkZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVibGlz aCBhIHNlcGFyYXRlIElELg0KDQoNCiAgICAgICAgIDcuIExhc3QgYnV0IG5vdCB0aGUgbGVhc3Qs IGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFuZCBOTVM/DQogICAgICAgICBTb21laG93 IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQNCiAg ICAgICAgIE5NUy9FTVMgY291bGRuJ3QuDQpbUkddIEkndmUgbmV2ZXIgaGVhcmQgb2YgYW4gRU1T L05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCB1c2VzIHRoaXMgdG9wb2xvZ3kg YXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0aW5nIExTUCBjb21i aW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVu IGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29yayBmb3Igd291bGRuJ3Qg aGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQolc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNo IGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lm aWMgb3BlcmF0aW9ucyAgZm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5IHBlcmZvcm0gVHJl ZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0aXBhdGguIEFsc28gcGVyZm9ybSBMU1Ag c3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFi bGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0aCBtdWx0aXBhdGguIFlvdSBjb3VsZCBhdXRv bWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcg cHJvYmUgdGVjaG5vbG9neS4gV2lsbCBub3Qgc2F5IGJleW9uZCB0aGF0IDpEDQoNCmNoZWVycw0K LXNhbQ0KDQoNCg== --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8D513E9HE111643EMEA1_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlNwcmVjaGJsYXNlbnRleHQg WmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLlNwcmVjaGJsYXNlbnRleHRaY2huDQoJe21zby1z dHlsZS1uYW1lOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazpTcHJlY2hibGFzZW50ZXh0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpwLmEsIGxpLmEsIGRpdi5h DQoJe21zby1zdHlsZS1uYW1lOuaJueazqOahhuaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om5 5rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLkJhbGxvb25UZXh0LCBsaS5CYWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkUtTWFpbEZv cm1hdHZvcmxhZ2UyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3Jt YXR2b3JsYWdlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0 dm9ybGFnZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZv cmxhZ2UyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg2 MTU1MDgyOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE2NjA1MTQ4MjAgMjY5MDI1Mjk1IDI2OTAyNTMwNSAyNjkwMjUzMDcgMjY5MDI1Mjk1IDI2OTAy NTMwNSAyNjkwMjUzMDcgMjY5MDI1Mjk1IDI2OTAyNTMwNSAyNjkwMjUzMDc7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPURFIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5IaSBOb2JvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPnRoYW5rcywgZnVsbHkgY29ycmVjdC4gVGhlIHVzZSBjYXNlIGRlc2NyaWJlcyBh biBMU1AgbW9uaXRvcmluZyBtZXRob2QuIFRvIHZhbGlkYXRlIHRoZSBMU1AgYW5vdGhlciB0b29s IG11c3QgYmUgdXNlZC4gQW4gZXhhbXBsZSBvZiB0aGUgbGF0dGVyIGlzIFJGQzQzNzksIHByb3h5 IGxzcCBvciB3aGF0ZXZlciBlbHNlLiBUaGUgdXNlIGNhc2UgdGV4dCB3aWxsIGJlIGNsYXJpZmll ZCBpbiB0aGUgbmV4dCB2ZXJzaW9uIChhbmQgdGhlIGV4cHJlc3Npb24gc29sdXRpb24gd2lsbCBi ZSByZW1vdmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJ1ZWRpZ2VyPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPlZvbjo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IE5vYm8gQWtpeWEgKG5vYm8pIFttYWlsdG86bm9ib0BjaXNjby5jb21dIDxi cj48Yj5HZXNlbmRldDo8L2I+IE1vbnRhZywgMTQuIEp1bGkgMjAxNCAxNDozOTxicj48Yj5Bbjo8 L2I+IFFpbiBXdTsgU2FtIEFsZHJpbjsgR2VpYiwgUsO8ZGlnZXI8YnI+PGI+Q2M6PC9iPiBzcHJp bmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlPGJyPjxiPkJldHJlZmY6PC9iPiBSRTog W3NwcmluZ10gUXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIFFpbiwgZXQgYWwsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RWFjaCBuZXR3b3JrIG5vZGUgd2lsbCBzdGls bCBoYXZlIHNvbWUgc3RhdGVzIChpLmUuIG5vZGUvYWRqYWNlbmN5L3NlcnZpY2Ugc2VnbWVudHMp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1D QSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgc2VlIHRoZSB0ZWNo bmlxdWUgZGVzY3JpYmVkIGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlIGFzIGEgd2F5IHRv IG1vbml0b3IgdGhlIG5ldHdvcmssIGJ1dCBub3QgYSB3YXkgdG8gdmFsaWRhdGUgdGhlIHNlZ21l bnRzLiBJbiBwYXJ0aWN1bGFyIHRoZSBmb2xsb3dpbmcgYXNwZWN0cyBjYW5ub3QgYmUgdmFsaWRh dGVkIGJ5IHRoZSB0ZWNobmlxdWUgZGVzY3JpYmVkIGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2Vj YXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPUVOLUNBIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPUVOLUNB IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VXNpbmcgYSBzZWdtZW50IG9yIGNvbWJpbmF0aW9uIG9mIHNlZ21l bnRzIHJlc3VsdCBpbiBhIHBhY2tldCB0byByZWFjaCBhbiBleHBlY3RlZCBuZXR3b3JrIG5vZGUu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz4yLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Vc2luZyBhbiBh ZGphY2VuY3kgc2VnbWVudCByZXN1bHRzIGluIGEgcGFja2V0IHRvIHRyYXZlcnNlIG92ZXIgYW4g ZXhwZWN0ZWQgYWRqYWNlbmN5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+VXNpbmcgYSBzZXJ2aWNlIHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byBo aXQgYW4gZXhwZWN0ZWQgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5UaGlzIGlzIHdoeSBJIHByZXZpb3VzbHkgbWVudGlvbmVkIHRoYXQgdGhlIHRlY2hu aXF1ZSBpcyB1c2VmdWwgYXMgPC9zcGFuPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5vbmUgb2YgdGhlIE9BTXMgdXNlZCB0byBtb25pdG9yIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkluIG90aGVyIHdvcmRzLCB3ZSB3b3VsZCBz dGlsbCB3YW50IHRoaW5ncyBpbiBhZGRpdGlvbiB0byB2YWxpZGF0ZSB0aGUgc3RhdGVzIG9uIGVh Y2ggbmV0d29yayBub2RlIHNvIHRoYXQsIHdoZW4gaW5ncmVzc2VzIHN0ZWVyIHBhY2tldHMgdXNp bmcgY29tYmluYXRpb25zIHNlZ21lbnRzICh0aGF0IG1ha2VzIHVzZSBvZiB0aG9zZSBzdGF0ZXMp LCB0aGVuIGV4cGVjdGVkIGFuZCBhY3R1YWwgcGF0aHMgYWxpZ25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgaW50ZW50aW9uYWxseSBkaWRu4oCZdCBhbnN3ZXIg eW91ciBxdWVzdGlvbiBvbiB0aGUgdXNlZnVsbmVzcyBvZiBQcm94eSBMU1AgUGluZyBuIFNlZ21l bnQgUm91dGluZywgYnV0IEkgd2FudGVkIHRvIGhpZ2hsaWdodCB3aGF0IGFyZSB0aGUgYWRkaXRp b25hbCBwb2ludHMgd2Ugd291bGQgd2FudCB0byBjb3ZlciBmcm9tIE9BTSBwZXJzcGVjdGl2ZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Eg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MhPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBRaW4gV3UgWzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPm1h aWx0bzpiaWxsLnd1QGh1YXdlaS5jb208L2E+XSA8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgSnVs eSAxNCwgMjAxNCA1OjA4IEFNPGJyPjxiPlRvOjwvYj4gTm9ibyBBa2l5YSAobm9ibyk7IFNhbSBB bGRyaW47IDxhIGhyZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUiPlJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZTwvYT48YnI+PGI+Q2M6PC9iPiBzcHJpbmc7IGRyYWZ0LWdlaWItc3By aW5nLW9hbS11c2VjYXNlPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW3NwcmluZ10gUXVlc3Rpb25z PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlZlcnkgZ29vZCBwb2ludCwgc2lu Y2Ugc2VnbWVudCByb3V0aW5nIGRvZXNu4oCZdCByZXF1aXJlIGVhY2ggbmV0d29yayBub2RlIGlu IHRoZSBwYXRoIHRvIG1haW50YWluIHN0YXRlIGFuZCBvbmx5IGluZ3Jlc3Mgbm9kZSBtYWludGFp bnMgdGhlIHN0YXRlIHdoaWxlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByb3h5LWxzcC1waW5nIHJlcXVp cmUgZWFjaCBuZXR3b3JrIG5vZGUgaW4gdGhlIHJldHVybiBwYXRoIHRvIG1haW50YWluIHRoZSBz dGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaHkgYXBwbHkgUHJveHktbHNwLXBpbmcgdG8gc3ByaW5n IE9BTT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZWdhcmRzITxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuJz7lj5Hku7bkuro8L3NwYW4+ PC9iPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6U2ltU3VuJz46PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bic+IHNwcmluZyBbPGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8 L3NwYW4+PGI+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTaW1TdW4nPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuJz5Ob2JvIEFraXlhIChub2JvKTxicj48 L3NwYW4+PGI+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpTaW1TdW4nPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4nPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu Jz4gMjAxNDwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bic+5bm0PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuJz43PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuJz7mnIg8L3NwYW4+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4n PjExPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U2ltU3VuJz7ml6U8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4nPiAzOjAwPGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5n PVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bic+5pS25Lu2 5Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1bic+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4nPiBTYW0gQWxkcmluOyA8YSBocmVm PSJtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIj5SdWVkaWdlci5HZWliQHRlbGVrb20u ZGU8L2E+PGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlNpbVN1bic+5oqE6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bic+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT aW1TdW4nPiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlPGJyPjwvc3Bhbj48 Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp bVN1bic+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bic+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4nPiBSZTogW3Nwcmlu Z10gUXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQSBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpIFNhbSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Eg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KdXN0IHRvIHBvaW50IG91 dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t Q0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgdGVzdCBwYWNrZXQgZ2VuZXJhdGVkIGZyb20gYSBQTVMv Tk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4gaGF2ZSB0aGUgY29tcGxldGUgc2VnbWVudCBzdGFj ayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdvcmsgYXMgd2VsbCBhcyBob3cgdG8gY29tZSBi YWNrIHRvIHNlbGYgd2l0aG91dCBhbnkgZnVydGhlciBzaWduYWxpbmcsIE9BTSBzdGF0ZSBtYWlu dGVuYW5jZSBvbiBuZXR3b3JrIG5vZGVzIG5vciBPQU0gaW52b2x2ZW1lbnQgYnkgbmV0d29yayBu b2Rlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGF0IG1ha2Vz IHRoaXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkgTFNQIHBpbmcu PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNB IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBjZXJ0YWlubHkg aGFzIHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2Yg dGhlIE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MhPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLUNBIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0Egc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHNwcmluZyBbPGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbSBBbGRyaW48YnI+PGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIj5SdWVkaWdlci5HZWliQHRlbGVrb20uZGU8L2E+ PGJyPjxiPkNjOjwvYj4gc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZTxicj48 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1DQT5IaSBSdWVkaWdlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1DQT48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5UaGFua3MgZm9yIHRoZSBx dWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlubGluZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPk9uIFRodSwgSnVsIDEw LCAyMDE0IGF0IDc6MTUgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxl a29tLmRlIiB0YXJnZXQ9Il9ibGFuayI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUNBPkhpIFNhbSw8YnI+PGJyPm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRl ZCB0byB5b3VyIHRleHQuPGJyPjxicj4tIFByb3h5LWxzcC1waW5nIGlzIE1QTFMgb25seSwgd2hp bGUgdGhlIFBNUyBhcmNoaXRlY3R1cmUgaXMgaW50ZW5kZWQgZm9yIGV2ZXJ5IFNSIGRhdGEgcGxh bmUgKE1QTFMgKyBJUHY2KS4gV2UnbGwgY2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC48YnI+LSBQ cm94eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCks IHdoaWxlIG91ciB1c2UgY2FzZSBjYW4gdXNlIGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNp ZmljIGdvb2QgdXNlcyBmb3IgQkZELCBhbmQgSUNNUHY2KTxicj48YnI+QmFzZWQgb24gdGhhdCwg aXTCuXMgYSBzb2x1dGlvbiB3aXRoIGJyb2FkZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yIFNQ UklORyBhcyBhIHdob2xlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBJIGJlbGlldmUgeW91IHNheSBpdCBp cyB1c2UgY2FzZSBkb2N1bWVudCBiZWxvdy4gVGhlbiBzb2x1dGlvbiBpcyB0b28gcHJlbWF0dXJl IGF0IHRoaXMgcG9pbnQgb2YgdGltZSwgYXMgd2UgaGF2ZW4ndCBkZWxpYmVyYXRlZCBvbiB0aGUg cmVxdWlyZW1lbnRzIGVpdGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+PGJyPkFzIHlvdSB3cml0ZSwgU1IgYmFzZWQgT0FNIHBh cnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJveHktbHNwLiBXaXRob3V0IHJl cXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBhbmQgTEVSL0xTUiBwcm9jZXNzaW5nIGlu dHJvZHVjZWQgYnkgcHJveHktbHNwLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+PGJyPlJlZ2FyZHMsPGJyPjxicj5SdWVk aWdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tQ0E+PGJyPjxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyBTYW0gQWxkcmluIHdyb3RlOjxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg SSBoYXZlIGZldyBxdWVzdGlvbnMgYWJvdXQgdGhpcyBkcmFmdC48YnI+PGJyPiZuYnNwOyAmbmJz cDsgJm5ic3A7IDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcgdG8gbWUuIEl0IHNheXMgT0FNIHVz ZSBjYXNlIGJ1dCBpbiBzZWN0aW9uICMxPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGl0IHNheXMg dGhlIGZvbGxvd2luZzxicj48YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3NuaXAmZ3Q7PGJy PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29s dXRpb24gdG8gdGhpcyBwcm9ibGVtIHN0YXRlbWVudCBhbmQ8YnI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7aWxsdXN0cmF0ZXMgaXQgd2l0aCB1c2UtY2FzZXMuPGJyPjxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtUaGUgc29sdXRpb24gaXMgZGVzY3JpYmVkIGZvciBhIHNpbmdsZSBJ R1AgTVBMUyBkb21haW4uPGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc29s dXRpb24gYXBwbGllcyB0byBtb25pdG9yaW5nIG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvPGJy PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQg TFNQJ3MuPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtlbmQgc25pcCZndDs8YnI+PGJyPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIGZhY3QgdGhlIGRyYWZ0IGlzIGRlc2NyaWJpbmcg YSBzb2x1dGlvbiB0byBjZXJ0YWluIHNjZW5hcmlvcyBhbmQgbm90IGp1c3Q8YnI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cHJvdmlkaW5nIHVzZSBjYXNlcy9zY2VuYXJpb3MuIE15IHVuZGVy c3RhbmRpbmcgd2FzLCB1c2UgY2FzZSBkcmFmdCBzaG91bGQ8YnI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZG9jdW1lbnQgc2NlbmFyaW9zIHdoZXJlIGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVp cmVtZW50cy4gU29sdXRpb25zIGNvdWxkPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jl IGNvdmVyZWQgd2l0aCBleGlzdGluZyB0b29sc2V0IG9yIGRlZmluZWQgbmV3bHksIGRlcGVuZGlu ZyBvbiB0aGUgR0FQPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuYWx5c2lzLiBCdXQg dGhhdCBzaG91bGQgYmUgc2VwYXJhdGUgYXMgdGhlcmUgY291bGQgYmUgbW9yZSB0aGFuIDEgc29s dXRpb24sPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZXJlIGFzIHRoaXMgZG9jdW1l bnQgY291bGQganVzdCBmb2N1cyBvbiB1c2UgY2FzZXMgb25seS48YnI+PGJyPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0lmIGluZmFjdCB0aGlzIGlzIHN1cHBvc2VkIHRvIGJlIGEgc29sdXRp b24gZG9jdW1lbnQsIHRoZW4gY2hhbmdpbmcgdGhlIHRpdGxlPGJyPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3dvdWxkIGJlIG1vcmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15IG9ic2VydmF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1DQT5bUkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZp ZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVv dGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4lc2FtIC0gT0suIHRo ZW4gSSdkIGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQs IHRoYXQgd2F5IHdlIGRvbnQgaGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRpb25zIGRv ZXMgZWl0aGVyIG9yIGNvbXBhcmUgd2l0aCA6RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPjxzcGFuIGxhbmc9RU4tQ0E+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIHcu ci50LiBTZWN0aW9uIG51bWJlciAjMiwgdGhlIHNhbWUgcHJvYmxlbSBpcyBiZWluZyBzb2x2ZWQg d2l0aDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtkcmFmdC1pZXRmLW1wbHMt cHJveHktbHNwLXBpbmctMDImcXVvdDsgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGlz PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlY3Rpb24gY291bGQgYmUgZG9uZSB3aXRo IHRoZSBwcm94eSBwaW5nKHNvbHV0aW9uIHdpc2UpIHdoZXJlLCByZXF1ZXN0IGNvdWxkPGJyPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIHNlbnQgdG8gbW9uaXRvciBMRVIgaSBhbmQgTEVS IGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJzdGFuZGluZzxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyaWdodD8gSWYgbm90LCBob3cgaXMgaXQgZGlmZmVyZW50IGhlcmU/ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUNBPltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkg aW4gZGF0YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQ8YnI+Jm5ic3A7ICZuYnNwOyAmbmJz cDtjaGFpbiBvZiBNUExTIExTUHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBFeGVjdXRlIHlv dSBtZWFuIHRyYXZlcnNlPyBvciBwZXJmb3JtIHNvbWV0aGluZyBlbHNlPyZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT48YnI+W1JHXSBQ cm94eS1sc3Agc2F5czogVGhpcyBkb2N1bWVudCBkZWZpbmVzIHByb3RvY29sIGV4dGVuc2lvbnMg dG8gTVBMUyBwaW5nIFtSRkM0Mzc5XSB0bzxicj4mbmJzcDsgJm5ic3A7YWxsb3cgYSB0aGlyZCBw YXJ0eSB0byByZW1vdGVseSBjYXVzZSBhbiBNUExTIEVjaG8gUmVxdWVzdCBtZXNzYWdlIHRvPGJy PiZuYnNwOyAmbmJzcDtiZSBzZW50IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBMU1AuPG86cD48 L286cD48L3NwYW4+PC9wPjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUNBPiVzYW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9ucywgJm5ic3A7 aXQgaGFzIHRvIGJlIHNvbHV0aW9uIGRvY3VtZW50ICZuYnNwO2FuZCBjYW5ub3QgY2xhaW0gdG8g YmUgdXNlIGNhc2UgZG9jdW1lbnQuIEFsc28gdGhpcyBkb2N1bWVudCBpcyBvbiBpbmZvcm1hdGlv biB0cmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tQ0E+PGJyPltSR10gSSB0YWtlIGl0IGFzIHNheWluZyB0aGF0IGlmIHlvdSdkIGxpa2UgdG8g cmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55IExTUCwgeW91IGNv dWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciBwcm94eS1waW5nLiBUaGUgUE1TIGhvd2V2ZXIgc2lt cGxpZmllcyBhbmQgYWRkczxicj5mdW5jdGlvbmFsaXR5Ojxicj5hKSBZb3UgZG9uJ3QgbmVlZCBh biBhZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlrZSBwcm94eS1waW5nIHRv IGNoZWNrIGRhdGE8YnI+Jm5ic3A7ICZuYnNwO3BsYW5lIGxpdmVsaW5lc3MsIFJGQzQzNzkgaXMg ZmluZS4gRGV1dHNjaGUgVGVsZWtvbSBvcGVyYXRlcyBhIFBNUyBpbXBsZW1lbnRhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQ0E+JXNhbSAtIFJGQzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRh cGxhbmUgYW5kIGFsc28gZmluZCBvdXQgbG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVz cyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVmZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRl cGxveW1lbnRzLlNvIGFyZSB5b3Ugc2F5aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9y IGxpdmVuZXNzIGRldGVjdGlvbiBhbmQgbm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRh IHBsYW5lIHRvIGNvbnRyb2wgcGxhbmUsIGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMg aW4gdGhlIGxhdGVyIHBhcnQgb2YgdGhlIGRvYyBhbHNvKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5iKSBvbmNl IFBNUyBkZXRlY3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1Q TFMgdG9wb2xvZ3kgYnkgUkZDNDM3OSw8YnI+Jm5ic3A7ICZuYnNwO2l0IGNhbiBjb250aW51ZSB0 byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9uaXRvcmluZyBw YWNrZXRzIHN0YXk8YnI+Jm5ic3A7ICZuYnNwO2luIGRhdGEgcGxhbmUuIFBsZWFzZSBwb2ludCBt ZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIHRoaXMgZmVhdHVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tQ0E+JXNhbSAtIFRoaXMgeW91IGNvdWxkIHBlcmZvcm0gZXZlbiB3aXRob3V0IHBy b3h5IHBpbmcuIFRoZSBmdW5jdGlvbiB5b3UgYXJlIGRlc2NyaWJpbmcgaXMsIGhvdyB5b3UgdXNl IGxzcCBwaW5nIHJhdGhlciB0aGFuIHdoYXQgbHNwIHBpbmcgZG9lcy4gQWdhaW4gSSBhbSBub3Qg dGFsa2luZyBhYm91dCBub24tbXBscyB0b3BvbG9neS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5UbyBhbnN3ZXIgeW91 ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPi0gUGVyZm9ybSB0cmVldHJh Y2Ugd2l0aCByZmM0Mzc5IHRvIGdldCB0b3BvbG9neSBpbmZvPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+LSBwaWNrIGFu eSBhcmJpdGFyeSBMU1AgcGF0aHMgZGlzY292ZXJlZCBhbG9uZyB3aXRoIGl0cyBtdWx0aXBhdGgg aW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+LSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxl Y3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIg al0uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tQ0E+LSBpZiB5b3Ugd2FudCB0byBwZXJmb3JtIGZyb20gTEVSIGkgdG8gTEVS IGogYXMgaW4geW91ciBkcmFmdCwgdXNlIHByb3h5IHBpbmcgdG8gc3RhcnQgZnJvbSBMRVIgaTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9RU4tQ0E+PGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50IGJhY2sgdG8gUE1TIHdoaWNoIGlzIG5v dCBwYXJ0IG9mIE1QTFMgb3Igc2VnbWVudDxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg ZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0 byBjb25zaWRlcmVkLiBJIGJlbGlldmU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGl0 IGFwcGxpZXMgdG8gc2VuZGluZyBhIHJlcXVlc3QgdG9vLiBXaWxsIHlvdSBiZSBkb2N1bWVudGlu ZyB0aGF0IGFzcGVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tQ0E+W1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRvbWFp biBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlIHRlYW0gd2lsbCBkZWFsIHdp dGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJl IGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9y IGEgdXNlIGNhc2UgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPiVzYW0gLSBub2QmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNBPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgNC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZv cm0gdGhhdCB3aXRoIFJGQzQzNzkgcGluZzxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg d2l0aCBtdWx0cGF0aCArIHByb3h5IHBpbmcuIENvdWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0 ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmc8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5l dyB0aGUgc29sdXRpb24gYnJpbmdzIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPltSR10gVGhlIFNSIE9BTSBhdXRob3Ig dGVhbSBoYXMgcHJvdmlkZWQgdGV4dCBob3cgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbiB0 aGUgdXNlIGNhc2UgZHJhZnQuIFlvdSBhcmUgYSBjby1hdXRob3Igb2YgcHJveHktbHNwLiBJIGNv dWxkbid0IGZpbmQgZXhwbGljaXQgdGV4dCBvbiBob3cgdG8gZGV0ZWN0IGFuZCBtb25pdG9yIGEg YnVuZGxlZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhvdyBwcm94 eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkgaWYgdGhp cyBpcyBvYnZpb3VzIGFuZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyB0 byB0aGUgU1IgT0FNIGFwcHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uPG86cD48L286cD48L3Nw YW4+PC9wPjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LUNBPiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBp ZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIgaXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxh YmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgdHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwg TEVSIGkgd2lsbCByZXNwb25kIHdpdGggRERNQVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3Mg YW5kIHRoZSBtdWx0aXBhdGggaW5mbyBmb3IgdGhlIHNhbWUuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+SWYgeW91IHNh eSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUgbGFiZWwgc3RhY2ssIHRoZW4geW91IGNv dWxkIHVzZSBsc3Agc2VsZWN0b3JzIGFzIGRlZmluZWQgaW4gUkZDNDM3OSwgaW4gdGhpcyBjYXNl IGl0IGlzIGxvY2FsIGhvc3QgZGVzdCBpcCBhZGRyLCB0byBpZGVudGlmeSBlYWNoIGxpbmsgbWVt YmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLUNBPk5vdyBpZiB0aGUgTVBMUyBmb3J3YXJkaW5nIGxheWVyIHNlZXMgdGhl IGJ1bmRsZWQgbGluayBhcyBvbmUgaW50ZXJmYWNlIGJ1dCBjYW5ub3QgZGlzY2VybiBpdHMgbGlu ayBtZW1iZXJzLCB0aGVuIHlvdSBjb3VsZCBvbmx5IHZhbGlkYXRlIHRoZSBpbnRlcmZhY2UgYW5k IG5vdCBpdHMgaW5kaXZpZHVhbCBtZW1iZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPlNhbWUgYXBwbGllcyBpbiB5 b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1DQT48YnI+PGJyPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVudCBoZXJl IG9ubHkgZm9yIFBNUyB0byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZTxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjYXNlIG9mIG1peGVkIGVudj88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+ W1JHXSBNUExTIHRvcG9sb2d5IGF3YXJlbmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1 cCBwYWNrZXRzIHdpdGggbGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2Yg TFNQcy4gSWYgc3VpdGFibGUgTGFiZWwvRkVDL25vZGUgcmVsYXRpb24gaXMga25vd24gdG8gdGhl IFBNUywgdGhhdCBMU1AgY2FuIGJlIGV4ZWN1dGVkIGZyb20gdGhhdCBub2RlIG9uIGJ5IGEgUE1T IG1vbml0b3JpbmcgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4lc2FtIC0gU28sIHlvdSBhcmUg c2F5aW5nIHRoYXQgeW91IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yIHRy ZWV0cmFjZSB0byBnZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJl aW5nIHByb3Bvc2VkIGluIFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4g bGFiZWwgc3RhY2suJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+QW5kIHRoZSBwcm9wb3NlZCBQTVMgc29sdXRp b24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwgaXQgcGVyZm9ybXMgb24gZGVtYW5kIHBlciBzZWdt ZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28gZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgdG9w b2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tQ0E+VGhlIGNhc2UgeW91IGFyZSBtYWtpbmcgaXMgdGhhdCBubyBuZWVk IG9mIGJlbGxzIGFuZCB3aGlzdGxlcyBvZiBSRkM0Mzc5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLUNBPlF1ZXN0aW9uIEkgaGF2ZSBmb3IgeW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMg YXJlIGdldHRpbmcgZHJvcHBlZCBhbmQgUE1TIHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEg Z2l2ZW4gTFNQIG9yIFNlZ21lbnQsIGhvdyBkbyB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/ IGlmIHlvdSBrbm93LCBob3cgZG8geW91IGZpZ3VyZSBvdXQgd2hlcmUgaXQgaXM/PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t Q0E+QXQgbGVhc3Qgd2l0aCBSRkM0Mzc5IGFuZC9vciBwcm94eSBwaW5nLCB5b3UgY291bGQgdmFs aWRhdGUgZWFjaCBob3AgYmVjYXVzZSBvZiB0aGUgYmVsbHMgYW5kIHdoaXN0bGVzIGl0IGNhcnJp ZXMgYWxvbmcgd2l0aCB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PjxzcGFuIGxhbmc9RU4tQ0E+PGJyPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Ni4gSW4gc2VjIDMuMSw8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDtzbmlwJmd0Ozxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RGV0ZXJtaW5p bmcgYSBwYXRoIHRvIGJlIGV4ZWN1dGVkIHByaW9yIHRvIGEgbWVhc3VyZW1lbnQgbWF5IGFsc28g YmU8YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvbmUgYnkgc2V0dGluZyB1 cCBhIGxhYmVsIGluY2x1ZGluZyBhbGwgbm9kZSBTSURzIGFsb25nIHRoYXQgcGF0aDxicj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KGlmIExFUjEgaGFzIE5vZGUgU0lEIDQwIGlu IHRoZSBleGFtcGxlIGFuZCBpdCBzaG91bGQgYmUgcGFzc2VkPGJyPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtiZXR3ZWVuIExFUiBpIGFuZCBMRVIgaiwgdGhlIGxhYmVsIHN0YWNr IGlzIDIwIC0gNDAgLSAzMCAtIDEwKS4gJm5ic3A7VGhlPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDthZHZhbnRhZ2Ugb2YgdGhpcyBtZXRob2QgaXMsIHRoYXQgaXQgZG9lcyBu b3QgaW52b2x2ZSBNUExTIE9BTTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZnVuY3Rpb25hbGl0eSBhbmQgaXQgaXMgaW5kZXBlbmRlbnQgb2YgRUNNUCBmdW5jdGlvbmFsaXRp ZXMuICZuYnNwO1RoZTxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0aG9k IHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBh dGhzIG9mPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbiBNUExTIGRvbWFp bi4gJm5ic3A7SWYgY29ycmVjdCBmb3J3YXJkaW5nIGFsb25nIHRoZSBkZXNpcmVkIHBhdGhzIGhh cyB0bzxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgY2hlY2tlZCwgUkZD NDczOSBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBhcHBsaWVkIGFsc28gaW4gdGhpczxicj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2FzZS48YnI+PGJyPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7ZW5kIHNuaXAmZ3Q7PGJyPjxicj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9l cyBub3QgaW52b2x2ZSBNUExTIE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksPGJyPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgY291bGQgYmUgdXNl ZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IGNvdWxkIHlvdSB2ZXJpZnkgYTxicj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBk b25lLiBNb3JlIHRleHQgd2lsbCBoZWxwLiBBbHNvLCBtb3JlPGJyPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGllciB0byB0aGUgYWJv dmUgc2F5cywgZm9yIHZhbGlkIHJlc3VsdCwgTVBMUzxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7T0FNIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMg ZXRjLiBJZiBzbywgaXQgY29udHJhZGljdHMgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+W1JHXSBUaGUgdGV4dCBzaG91 bGQgc2F5IHRoYXQ8YnI+LSB3aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVj dXRlcyBhIHNldCBvZiBwYXRocyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRp b24uPGJyPi0gaWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxh bmUgY29ycmVzcG9uZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxk IGJlIGFwcGxpZWQuPGJyPklmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUg dGV4dCBpbiB0aGUgZHJhZnQgc3RhdGVzIHNvbWV0aGluZyBkaWZmZXJlbnQsIEknbGwgdHJ5IHRv IHJld29yZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9ibG9ja3F1b3RlPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+JXNhbSAtIFRoZSBwcm9ibGVtIEkgYW0gaGF2 aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FNLCB5b3UgaGF2ZSB0byB2YWxpZGF0 ZSB0aGUgbHNwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUNBPkkgZGVmaW5pdGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZv ciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVlbCBpcywgdGhlIHVzZSBjYXNlIGlzIHRvbyBtdWNoIGNh dGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZpc2lvbmVkIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUNBPk9uY2Ug eW91IHJlbW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNo b3VsZCBiZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFy IHJlcXVpcmVtZW50cyBmb3IgYSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT5Gb3Igc29sdXRpb24gcGFy dCwgcGxlYXNlIHB1Ymxpc2ggYSBzZXBhcmF0ZSBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3BhbiBsYW5nPUVOLUNBPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Ny4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZlcmVudCBpcyBQTVMgZnJv bSBFTVMgYW5kIE5NUz88YnI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NvbWVo b3cgSSBjb3VsZG4ndCBmaW5kIHRoZSBkaWZmZXJlbmNlIHdoYXQgUE1TIGNvdWxkIGRvIGFuZDxi cj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Tk1TL0VNUyBjb3VsZG4ndC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t Q0E+W1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9OTVMgd2hpY2ggaXMgTVBMUyB0b3Bv bG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0 YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmluYXRpb25zIGFzIGRlc2lyZWQgYnkg YW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUgYmVlbiBjb21tZXJjaWFsbHkgYXZhaWxhYmxl LCB0aGUgY29tcGFueSBJIHdvcmsgZm9yIHdvdWxkbid0IGhhdmUgYmVlbiBkZXZlbG9waW5nIGEg UE1TLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4lc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNoIGFyZSBw YXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lmaWMgb3Bl cmF0aW9ucyAmbmJzcDtmb3IgYSBnaXZlbiBzZXQgb2YgTFNQJ3MuIFRoZXkgcGVyZm9ybSBUcmVl dHJhY2UgYW5kIHBlcmZvcm0gcGluZyB3aXRoIG11bHRpcGF0aC4gQWxzbyBwZXJmb3JtIExTUCBz cGVjaWZpYyB2YWxpZGF0aW9uIGJ5IGNyYWZ0aW5nIHBhY2tldHMgd2l0aCBkYXRhIGF2YWlsYWJs ZSB3aXRoIHRyZWV0cmFjZSBhbmQgcGluZyB3aXRoIG11bHRpcGF0aC4gWW91IGNvdWxkIGF1dG9t YXRlIHRoZSB3b3JrZmxvdyB3aXRob3V0IHRoZSBuZWVkIGZvciBPU1MvUE1TLCBieSB1c2luZyBw cm9iZSB0ZWNobm9sb2d5LiBXaWxsIG5vdCBzYXkgYmV5b25kIHRoYXQgOkQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1DQT5jaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1DQT4tc2FtPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tQ0E+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLUNBPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_CA7A7C64CC4ADB458B74477EA99DF6F502D8D513E9HE111643EMEA1_-- From nobody Mon Jul 14 08:17:41 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C251A0A89 for ; Mon, 14 Jul 2014 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL8S_LW3FJ1f for ; Mon, 14 Jul 2014 08:17:35 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30651A064A for ; Mon, 14 Jul 2014 08:17:35 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id et14so75842pad.9 for ; Mon, 14 Jul 2014 08:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vOh1LTx3V2gmnt6YXrjZnxhlXsWhst12guItKXEyGXw=; b=0LJePpbIPZ/KNJm96roDmXXgOUZZgdyhJWUfOnGN/xwZoNuhAL8A8EIumBrD1+tSH1 Qwwo8M+OwpUpA3P/zdp5FpYHUGsj2IG0OVWlIKcUQYxOK3e3PFCm5QrjHoPjjZJN9WqQ bmoRK6K5a1tO+k4L+4FjJtC2aHOqZvQvHG8rNKTcKK8LqXYCPVazFJdYu3dXp/qPn3Ht i03KJpj8ZxGQ8hzntdyVn313Suevf+6AwKxCnGzfudVccUUcUNfCP+Abou3hhWot0pU4 NEKc8uWm9hsRRF37+187YcE7mmstQKTOp05AuDComahllFXvyCjPXQRT7kcU8m8MQXmS ozdQ== X-Received: by 10.66.141.37 with SMTP id rl5mr3766185pab.103.1405351055230; Mon, 14 Jul 2014 08:17:35 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id hl1sm14890321pdb.41.2014.07.14.08.17.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 08:17:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E4E694C-8622-4261-9B2E-06BA8780FAB1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 14 Jul 2014 08:17:32 -0700 Message-Id: <43C21A33-ED76-4335-9568-62B5088E22ED@gmail.com> References: To: Qin Wu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/jod-cWLHBy7qVVH2Nawfa85B7Ss Cc: "Nobo Akiya \(nobo\)" , spring , draft-geib-spring-oam-usecase , "Ruediger.Geib@telekom.de" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 15:17:38 -0000 --Apple-Mail=_3E4E694C-8622-4261-9B2E-06BA8780FAB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 14, 2014, at 2:07 AM, Qin Wu wrote: > Very good point, since segment routing doesn=E2=80=99t require each = network node in the path to maintain state and only ingress node = maintains the state while > Proxy-lsp-ping require each network node in the return path to = maintain the state. Wrong!=20 No state is maintained except in the initiator. -sam > Why apply Proxy-lsp-ping to spring OAM? > =20 > Regards! > -Qin > =E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Nobo Akiya (nobo) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5= 3:00 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de > =E6=8A=84=E9=80=81: spring; draft-geib-spring-oam-usecase > =E4=B8=BB=E9=A2=98: Re: [spring] Questions > =20 > Hi Sam, > =20 > Just to point out one thing about this document =E2=80=A6 > =20 > The test packet generated from a PMS/NMS/EMS/network-device can have = the complete segment stack on how to traverse the network as well as how = to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. > =20 > That makes this approach quite different from using proxy LSP ping. > =20 > This certainly has some pros and cons but can be quite useful as one = of the OAMs (yes plural) used to monitor the network. > =20 > Thanks! > =20 > -Nobo > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 10, 2014 2:13 PM > To: Ruediger.Geib@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > =20 > Hi Ruediger, > =20 > Thanks for the quick response. Please find my responses inline. > =20 >=20 > On Thu, Jul 10, 2014 at 7:15 AM, wrote: > Hi Sam, >=20 > my replies are marked [RG] and added to your text. >=20 > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6) >=20 > Based on that, it=C2=B9s a solution with broader scope and better fit = for SPRING as a whole.=20 > %sam - I believe you say it is use case document below. Then solution = is too premature at this point of time, as we haven't deliberated on the = requirements either.=20 >=20 > As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >=20 > Regards, >=20 > Ruediger >=20 >=20 > Sam Aldrin wrote: >=20 > I have few questions about this draft. >=20 > 1. The title is confusing to me. It says OAM use case but in = section #1 > it says the following >=20 > > This document describes a solution to this problem statement = and > illustrates it with use-cases. >=20 > The solution is described for a single IGP MPLS domain. >=20 > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > >=20 > In fact the draft is describing a solution to certain scenarios = and not just > providing use cases/scenarios. My understanding was, use case = draft should > document scenarios where it will drive new requirements. = Solutions could > be covered with existing toolset or defined newly, depending on = the GAP > analysis. But that should be separate as there could be more = than 1 solution, > where as this document could just focus on use cases only. >=20 > If infact this is supposed to be a solution document, then = changing the title > would be more meaningful. That's my observation. >=20 > [RG] Thanks. It's a use case document. We'll review the text of = section 1. > %sam - OK. then I'd like to see any specific solution content removed, = that way we dont have to discuss what other solutions does either or = compare with :D > =20 >=20 > 2. w.r.t. Section number #2, the same problem is being solved = with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described = in this > section could be done with the proxy ping(solution wise) where, = request could > be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding > right? If not, how is it different here? >=20 > [RG] The PMS is able to set up packets which stay in data plane and = execute a desired > chain of MPLS LSPs. > %sam - Execute you mean traverse? or perform something else?=20 >=20 > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message = to > be sent down a LSP or part of an LSP. > %sam - If it is proposing extensions, it has to be solution document = and cannot claim to be use case document. Also this document is on = information track. >=20 > [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like = proxy-ping to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation. > %sam - RFC4379 performs validation of dataplane and also find out lot = more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) > =20 > b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the = monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering = this feature. > %sam - This you could perform even without proxy ping. The function = you are describing is, how you use lsp ping rather than what lsp ping = does. Again I am not talking about non-mpls topology. > To answer your question, how you perform. > - Perform treetrace with rfc4379 to get topology info > - pick any arbitary LSP paths discovered along with its multipath = implementation. > - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. > - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >=20 > 3. When the response is sent back to PMS which is not part of = MPLS or segment > domain, there is a serious security aspect, which needs to = considered. I believe > it applies to sending a request too. Will you be documenting = that aspect? >=20 > [RG] That's a valid point. The domain external system is one option = and the team will deal with the security aspects raised by this option = once we are in solution space. We will not analyse this in depth for a = use case document. > %sam - nod=20 >=20 > 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if = there is something > new the solution brings here? >=20 > [RG] The SR OAM author team has provided text how to monitor a bundled = link in the use case draft. You are a co-author of proxy-lsp. I couldn't = find explicit text on how to detect and monitor a bundled link in = draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a = bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. > %sam - The same steps described above could be used if each bundled = link member is identified with a unique label. While performing tree = trace or ping with multipath, LER i will respond with DDMAP info for = each of the links and the multipath info for the same. > If you say that each link member has same label stack, then you could = use lsp selectors as defined in RFC4379, in this case it is local host = dest ip addr, to identify each link member. > Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. > Same applies in your case too. Cannot see how it is different. > =20 >=20 >=20 > 5. sec #5, Is the requirement here only for PMS to learn the = topology, in the > case of mixed env? >=20 > [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. > %sam - So, you are saying that you still need to perform RFC4379 trace = or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 > And the proposed PMS solution (not use case) is that, it performs on = demand per segment, which Proxy ping also does, albeit only for MPLS = topology. > The case you are making is that no need of bells and whistles of = RFC4379. > =20 > Question I have for you is, if data plane packets are getting dropped = and PMS packets going through, for a given LSP or Segment, how do you = know there is a problem? if you know, how do you figure out where it is? > At least with RFC4379 and/or proxy ping, you could validate each hop = because of the bells and whistles it carries along with the packet. > =20 >=20 >=20 > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may = also be > done by setting up a label including all node SIDs along that = path > (if LER1 has Node SID 40 in the example and it should be = passed > between LER i and LER j, the label stack is 20 - 40 - 30 - = 10). The > advantage of this method is, that it does not involve MPLS = OAM > functionality and it is independent of ECMP functionalities. = The > method still is able to monitor all link combinations of all = paths of > an MPLS domain. If correct forwarding along the desired = paths has to > be checked, RFC4739 functionality should be applied also in = this > case. >=20 > >=20 > In the above you mention that it does not involve MPLS OAM. = But later you say, > RFC4379 functionality could be used. Could you clarify how = could you verify a > path, if MPLS validation is not done. More text will help. = Also, more > importantly, the text earlier to the above says, for valid = result, MPLS > OAM has to be performed for topology changes etc. If so, it = contradicts here. >=20 > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. > - if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states = something different, I'll try to reword it. > %sam - The problem I am having is, in the case of MPLS, for OAM, you = have to validate the lsp. > I definitely see a specific need for SPRING, but what I feel is, the = use case is too much catered to a specific envisioned solution. > Once you remove solution or suggested enhancements, hope it should be = clear on what is being solved and scope out clear requirements for a = solution. > For solution part, please publish a separate ID. > =20 >=20 > 7. Last but not the least, how different is PMS from EMS and = NMS? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. >=20 > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and = uses this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. > %sam - There are tools which are part of NMS/OSS, which performs MPLS = topology specific operations for a given set of LSP's. They perform = Treetrace and perform ping with multipath. Also perform LSP specific = validation by crafting packets with data available with treetrace and = ping with multipath. You could automate the workflow without the need = for OSS/PMS, by using probe technology. Will not say beyond that :D > =20 > cheers > -sam --Apple-Mail=_3E4E694C-8622-4261-9B2E-06BA8780FAB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 14, 2014, at 2:07 AM, Qin Wu = <bill.wu@huawei.com> = wrote:

Very good point, since segment = routing doesn=E2=80=99t require each network node in the path to = maintain state and only ingress node maintains the state = while
Proxy-lsp-ping require each = network node in the return path to maintain the = state.

Wrong! 
No state is maintained except in the = initiator.

-sam
Why apply = Proxy-lsp-ping to spring OAM?
 
Regards!
-Qin
=E5=8F=91=E4=BB= =B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org= ] =E4=BB=A3=E8=A1= =A8 Nobo Akiya (nobo)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5 3:00
=E6=94=B6=E4= =BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de
<= /span>=E6=8A=84=E9=80=81: spring; = draft-geib-spring-oam-usecase
=E4=B8=BB=E9=A2=98: Re: [spring] = Questions
 
Hi = Sam,
 
Just to = point out one thing about this document =E2=80=A6
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;"> 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any = further signaling, OAM state maintenance on network nodes nor OAM = involvement by network nodes.
 
That makes = this approach quite different from using proxy LSP = ping.
 
This = certainly has some pros and cons but can be quite useful as one of the = OAMs (yes plural) used to monitor the = network.
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, July 10, 2014 = 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: [spring] = Questions
 
Hi = Ruediger,
 
Thanks for the quick response. Please find = my responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to = your text.

- Proxy-lsp-ping is MPLS only, while the PMS = architecture is intended for every SR data plane (MPLS + IPv6). We'll = clarify that in the draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC = 4379 / RFC 6424), while our use case can use any OAM (in particular, = specific good uses for BFD, and ICMPv6)

Based on that, it=C2=B9s = a solution with broader scope and better fit for SPRING as a = whole. 
%sam - I believe you say it is use case document below. = Then solution is too premature at this point of time, as we haven't = deliberated on the requirements = either. 

As you = write, SR based OAM partially offers similar functions as proxy-lsp. = Without requiring the additional messages and LER/LSR processing = introduced by = proxy-lsp. 

Regards,

Ruediger


      Sam Aldrin = wrote:

      I have few questions about this = draft.

      1. The title is confusing to me. It = says OAM use case but in section #1
      it says the = following

      <snip>
    =    This document describes a solution to this problem = statement and
       illustrates it with = use-cases.

       The solution is described = for a single IGP MPLS domain.

       The = solution applies to monitoring of LDP LSP's as well as to
  =      monitoring of Segment Routed LSP's.
    =   <end snip>

       In fact the = draft is describing a solution to certain scenarios and not = just
       providing use cases/scenarios. My = understanding was, use case draft should
      =  document scenarios where it will drive new requirements. Solutions = could
       be covered with existing toolset or = defined newly, depending on the GAP
      =  analysis. But that should be separate as there could be more than = 1 solution,
       where as this document could = just focus on use cases only.

       If = infact this is supposed to be a solution document, then changing the = title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review the = text of section 1.
%sam - OK. then I'd like to see = any specific solution content removed, that way we dont have to discuss = what other solutions does either or compare with = :D
 


       2. w.r.t. Section number = #2, the same problem is being solved with
      =  "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in = this
       section could be done with the proxy = ping(solution wise) where, request could
      =  be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding
       right? If not, how is it = different here?

[RG] The PMS is able to set up packets which stay in data = plane and execute a desired
     chain of MPLS = LSPs.
%sam - Execute you mean traverse? or = perform something else? 

[RG] = Proxy-lsp says: This document defines protocol extensions to MPLS ping = [RFC4379] to
   allow a third party to remotely cause an = MPLS Echo Request message to
   be sent down a LSP or part = of an LSP.
%sam - If it is proposing extensions, =  it has to be solution document  and cannot claim to be use = case document. Also this document is on information = track.

[RG] I = take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't = need an additional protocol or functionality like proxy-ping to check = data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS = implementation.
%sam - RFC4379 performs = validation of dataplane and also find out lot more errors. You need = additional information to perform validation checks. For liveness = detection, BFD is preferred tool, atleast in present deployments.So are = you saying, PMS solution is designed for liveness detection and not to = perform validation of data plane to control plane, etc? (I think you = agree to this in the later part of the doc = also)
 
b) once PMS = detected data plane liveliness and correctness of MPLS topology by = RFC4379,
   it can continue to execute arbitrary LSP = combinations and the monitoring packets stay
   in data = plane. Please point me to the text in proxy-ping offering this = feature.
%sam - This you could perform even without = proxy ping. The function you are describing is, how you use lsp ping = rather than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with its = multipath implementation.
- perform ping with right = selectors for the path and use TTL for limiting the hop [LER = j].
- if you want to perform from LER i to LER j as in your = draft, use proxy ping to start from LER = i


        3. When the response is = sent back to PMS which is not part of MPLS or segment
    =     domain, there is a serious security aspect, which needs to = considered. I believe
        it applies to = sending a request too. Will you be documenting that = aspect?

[RG] That's a valid point. The domain external system is = one option and the team will deal with the security aspects raised by = this option once we are in solution space. We will not analyse this in = depth for a use case = document.
%sam - = nod 


        4. Sec 3.2 to monitor = bundle links, one could perform that with RFC4379 ping
    =     with multpath + proxy ping. Could you kindly differentiate = if there is something
        new the solution = brings here?

[RG] The SR OAM author team has provided text how to = monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be = used to monitor a bundled link (sorry if this is obvious and I missed = it). If there are differences to the SR OAM approach, we'll discuss = them.
%sam - The same steps described above could = be used if each bundled link member is identified with a unique label. = While performing tree trace or ping with multipath, LER i will respond = with DDMAP info for each of the links and the multipath info for the = same.
If you say that each link member has same label stack, = then you could use lsp selectors as defined in RFC4379, in this case it = is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled link as = one interface but cannot discern its link members, then you could only = validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is = the requirement here only for PMS to learn the topology, in = the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to set = up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring = packet.
%sam - So, you are saying that you still = need to perform RFC4379 trace or treetrace to get topology. I do not = think IGP extensions being proposed in SPRING export any of the info = other than label stack. 
And the proposed PMS solution = (not use case) is that, it performs on demand per segment, which Proxy = ping also does, albeit only for MPLS = topology.
The case you are making is that no need of = bells and whistles of RFC4379.
 
Question I have for you is, if data plane = packets are getting dropped and PMS packets going through, for a given = LSP or Segment, how do you know there is a problem? if you know, how do = you figure out where it is?
At least with RFC4379 and/or = proxy ping, you could validate each hop because of the bells and = whistles it carries along with the = packet.
 



         6. In sec = 3.1,
         <snip>
    =      Determining a path to be executed prior to a = measurement may also be
         done by = setting up a label including all node SIDs along that path
  =        (if LER1 has Node SID 40 in the example and = it should be passed
         between LER i = and LER j, the label stack is 20 - 40 - 30 - 10).  The
  =        advantage of this method is, that it does not = involve MPLS OAM
         functionality and = it is independent of ECMP functionalities.  The
    =      method still is able to monitor all link = combinations of all paths of
         an = MPLS domain.  If correct forwarding along the desired paths has = to
         be checked, RFC4739 = functionality should be applied also in this
      =    case.

         <end = snip>

         In the above you = mention that it does not involve MPLS OAM. But later you say,
  =        RFC4379 functionality could be used. Could = you clarify how could you verify a
        =  path, if MPLS validation is not done. More text will help. Also, = more
         importantly, the text earlier = to the above says, for valid result, MPLS
        =  OAM has to be performed for topology changes etc. If so, it = contradicts here.

[RG] The text should say that
- without = MPLS OAM functions, the PMS executes a set of paths only based on = control plane information.
- if the operator wants to make sure that = data plane corresponds to control plane, RFC4739 functions should be = applied.
If you understand this statement and the text in the draft = states something different, I'll try to reword = it.
%sam - The problem I am having is, in the = case of MPLS, for OAM, you have to validate the = lsp.
I definitely see a specific need for SPRING, but what I = feel is, the use case is too much catered to a specific envisioned = solution.
Once you remove solution or suggested = enhancements, hope it should be clear on what is being solved and scope = out clear requirements for a = solution.
For solution part, please publish a = separate ID.
 


         7. Last but not the = least, how different is PMS from EMS and NMS?
      =    Somehow I couldn't find the difference what PMS could do = and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't = have been developing a = PMS.
%sam - There are tools which are part of = NMS/OSS, which performs MPLS topology specific operations  for a = given set of LSP's. They perform Treetrace and perform ping with = multipath. Also perform LSP specific validation by crafting packets with = data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that = :D
 
cheers
-sam
=
= --Apple-Mail=_3E4E694C-8622-4261-9B2E-06BA8780FAB1-- From nobody Mon Jul 14 09:14:02 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28E81A0AC0 for ; Mon, 14 Jul 2014 09:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRqfjhLZKqxb for ; Mon, 14 Jul 2014 09:13:57 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A7C1A0AB8 for ; Mon, 14 Jul 2014 09:13:57 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so5660020pad.0 for ; Mon, 14 Jul 2014 09:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1QwNQ2y4JDgULbfIxc79+gxMyaW9aCF+Yu+Lpeu17RI=; b=C4QPXnEEk1NRHi0U4uadNiXC33DhZshlK/aMvWjCEEZzeRlYre45g+CF9vd+UD4hwh Wkk/SVF24dQWLKtfw5YJcxnUOnJk3K92Mis52mZzEijA74kWTKirp8VRj4WwEVokJsMv zNVGx4SWZpXztWIERRnbYZz7lHxImaqh/bpGDHoXmEevWVzECftsqr4m6myAExuzg7Lk PVo1hr7ZQfpTH5AZYpnYn1RPLN8kRGqlPHaJq5B02iaWPsTEoTWT6bLShBG+qSS3NqJn osv+akUHmdiw1W4jsf0SiBlVrwjISZEiuS/yflkj0iHqjV7PD5al9PpaY0Xz25R1unzO +wNQ== X-Received: by 10.70.42.203 with SMTP id q11mr17532130pdl.1.1405354436655; Mon, 14 Jul 2014 09:13:56 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id ph6sm11273934pbc.38.2014.07.14.09.13.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 09:13:54 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_26D53505-356B-4700-8A71-7FB30DBB2F37" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 14 Jul 2014 09:13:53 -0700 Message-Id: <1E356214-A057-42C3-BCC2-0E4B9980031A@gmail.com> References: <2A290853-13BA-4F6C-9061-782310F16C69@gmail.com> <39BF645D-D7E8-4A34-9A2F-DCB942062122@gmail.com> <168241F9-CBFD-4F8D-BB26-104ADC11FF6F@gmail.com> <8A0655C2-99CC-44C3-A287-1E73CD6BA51A@cisco.com> <6B4D46C6-B52A-4B16-906C-EC2684E3A670@gmail.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/WJr84m4TElwdmTNWK89gIXX4EPY Cc: "Nobo Akiya \(nobo\)" , "Ruediger.Geib@telekom.de" , "draft-geib-spring-oam-usecase@tools.ietf.org" , "spring@ietf.org" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:14:02 -0000 --Apple-Mail=_26D53505-356B-4700-8A71-7FB30DBB2F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Carlos, Inline for my reply. On Jul 13, 2014, at 1:35 AM, Carlos Pignataro (cpignata) = wrote: > Hi, Sam, >=20 > Please find inline a quick follow-up. >=20 > On Jul 13, 2014, at 9:18 AM, Sam Aldrin wrote: >=20 >> Hi Carlos, >>=20 >> comments inline. >> On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) = wrote: >>=20 >>> Hi, Sam, >>>=20 >>> On Jul 11, 2014, at 6:25 PM, Sam Aldrin = wrote: >>>=20 >>>> Hi Carlos, >>>>=20 >>>> On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) = wrote: >>>>=20 >>>>> Hi, Sam, >>>>>=20 >>>>> On Jul 11, 2014, at 12:07 PM, Sam Aldrin = wrote: >>>>>=20 >>>>>> Carlos, >>>>>>=20 >>>>>> On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) = wrote: >>>>>>=20 >>>>>>> Sam, >>>>>>>=20 >>>>>>> Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document. >>>>>> Neither did I ask for requirements only nor to be abstract, = rather to document to capture use cases, if that is what the authors = intent for this document is. >>>>>>>=20 >>>>>>> This document describes the specific case of how to use a = specific technology (spring) to solve a particular problem. The Abstract = is pretty clear on that: >>>>>>>=20 >>>>>>> Abstract >>>>>>>=20 >>>>>>> This document describes features and a use case of a path = monitoring >>>>>>> system. Segment based routing enables a scalable and simple = method >>>>>>> to monitor data plane liveliness of the complete set of paths >>>>>>> belonging to a single domain. [...] >>>>>>>=20 >>>>>>> This scenario cannot be decoupled from its actual use case. >>>>>> Well then the introduction says the following >>>>>> >>>>>> The solution is described for a single IGP MPLS domain. >>>>>>=20 >>>>>> The solution applies to monitoring of LDP LSP's as well as to >>>>>> monitoring of Segment Routed LSP's. >>>>>> ... >>>>>> .. >>>>>> The proposed solution offers several benefits for network = monitoring. >>>>>> A single centralized monitoring device is able to monitor the >>>>>> complete set of a domains forwarding paths. >>>>>>=20 >>>>>> >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements. >>>>>=20 >>>>> %s/The solution/The use case/ >>>>> s/The proposed solution/The presented use case/ >>>>=20 >>>> You are trivializing what I was eluding to in my earlier emails. >>>> If indeed you are not talking about solution, do you think sections = 4-7 talk about use cases? >>>> When I read the document the way it is worded and understood was to = PMS solution (sec #2) trying to solve problem in a specific. If you = don't believe, do "%s/PMS/NMS/g" and see. >>>>=20 >>>> Don't misconstrue that I am saying there is no use case. >>>>=20 >>>=20 >>> I did not imply that you said there is no use case. My point is that = the "solution" is part of the use case itself, and that a use case is = not a set of requirements -- this use case document explains how the use = case works (i.e., the case of the benefits for OAM of having Source = Packet Routing in Networks). You were asking about removing solutions = from the use case -- I am reacting to that. Otherwise, I might be = misunderstanding your point. >> I am only providing comment, whether to remove or not is upto you, = the authors. >> If you want to keep solution, that is fine too, but that will only = delay the progression of the document, because, we will be discussing = which solution is better and which isn=92t for a given use case. >> I could see why some of the existing solutions could do some of the = tasks, without the need of enhancement. As you could see from my earlier = arguments, I was commenting on the solution parts, not for use case. >> I prefer to see the use case be present in a simple and concise way = and solution be deferred to solution document. Again, your call :D >>=20 >=20 > I wanted to make sure I understood your point, because you always have = insightful and contractive input and feedback. >=20 > My take: What you call "solution" in the paragraph above is actually = part of the use case itself. There is no solution outside of and = external to the use case.=20 >=20 > A simple and concise way of presenting the context of the use case = would make for a very short draft -- see the first two sentences of the = Abstract: >=20 > This document describes features and a use case of a path = monitoring > system. Segment based routing enables a scalable and simple method > to monitor data plane liveliness of the complete set of paths > belonging to a single domain. >=20 > However the use case is describing how segment based routing enables = this OAM method. I understand what you say but the when I read the document, I see it = otherwise. Here are few snippets. Not cherry picking as you put it, I could copy whole draft if you want = :D - In Sec 3.1 Once the MPLS paths (Node SIDs) and the required IP address information has been detected, the LER i to LER j can be monitored by the PMS. Monitoring doesn't require MPLS OAM functionality, it is purely based on forwarding. When the text assert that MPLS OAM is not required, that is where I see = as a problem as it is clearly comparing the the solution. Your intention = here may be that (putting words in your mouth) it is one of the methods = to do so, but I read the text differently. - In Sec 3.1 again Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability. Data plane failure detection by circulating monitoring packets can be executed at any time. The PMS further executes MPLS OAM functions everywhere in the MPLS domain. It does not require access to LSR/LER management interfaces to do so. MPLS traceroutes as specified above should be executed only during off peak times (and then with limited parallel MPLS ping/trace load). Here too, I see it applies more to a specific solution. I=92d rather see = the text eluding something like (may not be exact) =93Liveness detection = of the data plane in the SR could be performed between any segments = initiated from non LSR/LER environments" - Sec 7 While the PMS based use cases explained in Section 3 is sufficient to provide Continuity check between LER i and LER j, it may not help perform connectivity verification. So in some cases like data plane programming corruption, it is possible that a transit node between LER i and LER j erroneously remove the top segment ID and forward to PMS based on bottom segment ID leading to falsified path liveliness to PMS. I read the text (and subsequent text in the section) as describing how = the connectivity verification solution by PMS should be performed. =46rom your emails I understand the intention and goal. Edits to the = text and making it non-solution specific is what I feel is needed. cheers -sam >=20 >> To provide more reason for my argument, for ex: why should I care = RFC4379 solve a specific use case or not? Use case is valid but it could = be solved multiple ways. Similarly, I need not solve a use case with = PMS, rather I could do with NMS. I do hope you see my point. >>=20 >=20 > These are use cases that get enabled by Source Packet Routing in = Networks. In the context of OAM, new ways of doing network-wide path = monitoring are enabled. The point of the use case is how it can be done = in spring networks that it cannot in non-spring ones. >=20 >>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even more. >>>>>>=20 >>>>>>=20 >>>>>> Again, it is up to you authors what to retain in the document or = what to add. >>>>>> We could review accordingly. >>>>>> If there are solutions and proposals to existing solutions in = this ID, then it will lead into solutions discussions, which is what is = happening right now. >>>>>>=20 >>>>>=20 >>>>> What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is, >>>>> * is this a simple remote (proxy?) realization/use for oam in = spring networks? >>>>> * can this use case be generalized to the spring ipv6 dataplane? = [I think so] >>>>> * can this use case be used with S-BFD? >>>>>=20 >>>> In addition, this document should add more details about the = scenarios of IPv6 w.r.t SR, or add specific pointers for the same. >>>=20 >>> Certainly these scenarios need to also be documented. >> cool >=20 >>=20 >> thanks >=20 > Anytime. >=20 > Thanks, >=20 > Carlos. >=20 >=20 >> -sam >>>=20 >>>> Also consider the comments in my earlier emails. As far as S-BFD = goes, refer to sec 3.4 of S-BFD use case document. >>>>=20 >>>=20 >>> Yes, this citations should be good. >>>=20 >>> Thanks, >>>=20 >>> Carlos. >>>=20 >>>> -sam >>>>=20 >>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Carlos. >>>>>=20 >>>>>> cheers >>>>>> -sam >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Carlos. >>>>>>>=20 >>>>>>> On Jul 11, 2014, at 11:24 AM, Sam Aldrin = wrote: >>>>>>>=20 >>>>>>>> Hi Rudiger, >>>>>>>>=20 >>>>>>>> As I acknowledged in my earlier emails, the question is not = about valid use cases exist or not, rather it is about the document and = what the text says. Document is not clear on just use cases only because = it touches various solution aspects, which is unnecessary. For example, = use cases should not care what RFC4379 can or cannot, that discussion = should happen after the requirements which gets originated by these use = cases. >>>>>>>>=20 >>>>>>>> Once you cleanup the document and remove solution specific = parts, it should be ok. We could defer the discussion of what the = existing solutions could and could not do, for solution document and = continue discussions of those pieces, then. >>>>>>>>=20 >>>>>>>> cheers >>>>>>>> -sam >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Jul 11, 2014, at 12:15 AM, = wrote: >>>>>>>>=20 >>>>>>>>> Hi Nobo, hi Sam >>>>>>>>> =20 >>>>>>>>> the use case is to enable monitoring of an MPLS domain without = accessing the control plane. To do so, a PMS needs MPLS topology = awareness, which it gets by Segment Routing. The draft to some extent = explains how that is done, without going into too many details, I think. >>>>>>>>> =20 >>>>>>>>> Monitoring without control plane access is part of the use = case, not part of a solution discussion (to say it differently: using = the data plane for OAM purposes is not an option which may be removed). = As many SR based OAM features can be used without OAM specific protocols = or functions being added to Segment Routing, I think it=92s perfectly ok = to formulate the use case as is. The main requirement is: specify = Segment Routing. Then one may add OAM boxes which apply SR features. >>>>>>>>> =20 >>>>>>>>> RFC4379 could also monitor LSPs, but it requires using the = control plane and proxy-lsp-ping adds control plane based functionality = to RFC4379. It is an approach resulting in similar features, but it is = control plane based. This is a different use case. >>>>>>>>> =20 >>>>>>>>> If an operator needs to validate that a packet travels a = certain path or trace the path a lost packet has taken, then RFC4379 = functionality is needed. It=92s a difference whether RFC4379 is applied = only at off peak times or after a data plane only monitoring packet has = been lost along one path or whether that has to be done constantly. >>>>>>>>> =20 >>>>>>>>> Regards, >>>>>>>>> =20 >>>>>>>>> Ruediger >>>>>>>>> =20 >>>>>>>>> Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 >>>>>>>>> Gesendet: Donnerstag, 10. Juli 2014 21:46 >>>>>>>>> An: Sam Aldrin >>>>>>>>> Cc: Geib, R=FCdiger; spring; draft-geib-spring-oam-usecase >>>>>>>>> Betreff: RE: [spring] Questions >>>>>>>>> =20 >>>>>>>>> Hi Sam, >>>>>>>>> =20 >>>>>>>>> I just wanted to point out the key described behavior, wasn=92t = saying anything about whether this document should be a use-case = document or a solution document J >>>>>>>>> =20 >>>>>>>>> Thanks! >>>>>>>>> =20 >>>>>>>>> -Nobo >>>>>>>>> =20 >>>>>>>>> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 >>>>>>>>> Sent: Thursday, July 10, 2014 3:10 PM >>>>>>>>> To: Nobo Akiya (nobo) >>>>>>>>> Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase >>>>>>>>> Subject: Re: [spring] Questions >>>>>>>>> =20 >>>>>>>>> Hi Nobo, >>>>>>>>> =20 >>>>>>>>> Inline for my comments. >>>>>>>>> =20 >>>>>>>>> On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = wrote: >>>>>>>>> Hi Sam, >>>>>>>>> =20 >>>>>>>>> Just to point out one thing about this document =85 >>>>>>>>> =20 >>>>>>>>> The test packet generated from a PMS/NMS/EMS/network-device = can have the complete segment stack on how to traverse the network as = well as how to come back to self without any further signaling, OAM = state maintenance on network nodes nor OAM involvement by network nodes. >>>>>>>>> That is fine as a requirement/usecase and we should limit the = scope to that, than specifying how to solve it. >>>>>>>>> =20 >>>>>>>>> That makes this approach quite different from using proxy LSP = ping. >>>>>>>>> You are talking about solution or use case? :D >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> This certainly has some pros and cons but can be quite useful = as one of the OAMs (yes plural) used to monitor the network. >>>>>>>>> Certainly. But I am struggling between use case and solution = outlined in the document. Pick one :D >>>>>>>>> =20 >>>>>>>>> -sam=20 >>>>>>>>> =20 >>>>>>>>> Thanks! >>>>>>>>> =20 >>>>>>>>> -Nobo >>>>>>>>> =20 >>>>>>>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin >>>>>>>>> Sent: Thursday, July 10, 2014 2:13 PM >>>>>>>>> To: Ruediger.Geib@telekom.de >>>>>>>>> Cc: spring; draft-geib-spring-oam-usecase >>>>>>>>> Subject: Re: [spring] Questions >>>>>>>>> =20 >>>>>>>>> Hi Ruediger, >>>>>>>>> =20 >>>>>>>>> Thanks for the quick response. Please find my responses = inline. >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> On Thu, Jul 10, 2014 at 7:15 AM, = wrote: >>>>>>>>> Hi Sam, >>>>>>>>>=20 >>>>>>>>> my replies are marked [RG] and added to your text. >>>>>>>>>=20 >>>>>>>>> - Proxy-lsp-ping is MPLS only, while the PMS architecture is = intended for every SR data plane (MPLS + IPv6). We'll clarify that in = the draft. >>>>>>>>> - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), = while our use case can use any OAM (in particular, specific good uses = for BFD, and ICMPv6) >>>>>>>>>=20 >>>>>>>>> Based on that, it=B9s a solution with broader scope and better = fit for SPRING as a whole.=20 >>>>>>>>> %sam - I believe you say it is use case document below. Then = solution is too premature at this point of time, as we haven't = deliberated on the requirements either.=20 >>>>>>>>>=20 >>>>>>>>> As you write, SR based OAM partially offers similar functions = as proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Ruediger >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Sam Aldrin wrote: >>>>>>>>>=20 >>>>>>>>> I have few questions about this draft. >>>>>>>>>=20 >>>>>>>>> 1. The title is confusing to me. It says OAM use case = but in section #1 >>>>>>>>> it says the following >>>>>>>>>=20 >>>>>>>>> >>>>>>>>> This document describes a solution to this problem = statement and >>>>>>>>> illustrates it with use-cases. >>>>>>>>>=20 >>>>>>>>> The solution is described for a single IGP MPLS domain. >>>>>>>>>=20 >>>>>>>>> The solution applies to monitoring of LDP LSP's as well = as to >>>>>>>>> monitoring of Segment Routed LSP's. >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> In fact the draft is describing a solution to certain = scenarios and not just >>>>>>>>> providing use cases/scenarios. My understanding was, = use case draft should >>>>>>>>> document scenarios where it will drive new = requirements. Solutions could >>>>>>>>> be covered with existing toolset or defined newly, = depending on the GAP >>>>>>>>> analysis. But that should be separate as there could be = more than 1 solution, >>>>>>>>> where as this document could just focus on use cases = only. >>>>>>>>>=20 >>>>>>>>> If infact this is supposed to be a solution document, = then changing the title >>>>>>>>> would be more meaningful. That's my observation. >>>>>>>>>=20 >>>>>>>>> [RG] Thanks. It's a use case document. We'll review the text = of section 1. >>>>>>>>> %sam - OK. then I'd like to see any specific solution content = removed, that way we dont have to discuss what other solutions does = either or compare with :D >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> 2. w.r.t. Section number #2, the same problem is being = solved with >>>>>>>>> "draft-ietf-mpls-proxy-lsp-ping-02" . What is being = described in this >>>>>>>>> section could be done with the proxy ping(solution = wise) where, request could >>>>>>>>> be sent to monitor LER i and LER j segment, from a PMS. = Is my understanding >>>>>>>>> right? If not, how is it different here? >>>>>>>>>=20 >>>>>>>>> [RG] The PMS is able to set up packets which stay in data = plane and execute a desired >>>>>>>>> chain of MPLS LSPs. >>>>>>>>> %sam - Execute you mean traverse? or perform something else?=20= >>>>>>>>>=20 >>>>>>>>> [RG] Proxy-lsp says: This document defines protocol extensions = to MPLS ping [RFC4379] to >>>>>>>>> allow a third party to remotely cause an MPLS Echo Request = message to >>>>>>>>> be sent down a LSP or part of an LSP. >>>>>>>>> %sam - If it is proposing extensions, it has to be solution = document and cannot claim to be use case document. Also this document = is on information track. >>>>>>>>>=20 >>>>>>>>> [RG] I take it as saying that if you'd like to remotely = execute RFC4379 functionality on any LSP, you could either use the PMS = or proxy-ping. The PMS however simplifies and adds >>>>>>>>> functionality: >>>>>>>>> a) You don't need an additional protocol or functionality like = proxy-ping to check data >>>>>>>>> plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS implementation. >>>>>>>>> %sam - RFC4379 performs validation of dataplane and also find = out lot more errors. You need additional information to perform = validation checks. For liveness detection, BFD is preferred tool, = atleast in present deployments.So are you saying, PMS solution is = designed for liveness detection and not to perform validation of data = plane to control plane, etc? (I think you agree to this in the later = part of the doc also) >>>>>>>>> =20 >>>>>>>>> b) once PMS detected data plane liveliness and correctness of = MPLS topology by RFC4379, >>>>>>>>> it can continue to execute arbitrary LSP combinations and = the monitoring packets stay >>>>>>>>> in data plane. Please point me to the text in proxy-ping = offering this feature. >>>>>>>>> %sam - This you could perform even without proxy ping. The = function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls topology. >>>>>>>>> To answer your question, how you perform. >>>>>>>>> - Perform treetrace with rfc4379 to get topology info >>>>>>>>> - pick any arbitary LSP paths discovered along with its = multipath implementation. >>>>>>>>> - perform ping with right selectors for the path and use TTL = for limiting the hop [LER j]. >>>>>>>>> - if you want to perform from LER i to LER j as in your draft, = use proxy ping to start from LER i >>>>>>>>>=20 >>>>>>>>> 3. When the response is sent back to PMS which is not = part of MPLS or segment >>>>>>>>> domain, there is a serious security aspect, which = needs to considered. I believe >>>>>>>>> it applies to sending a request too. Will you be = documenting that aspect? >>>>>>>>>=20 >>>>>>>>> [RG] That's a valid point. The domain external system is one = option and the team will deal with the security aspects raised by this = option once we are in solution space. We will not analyse this in depth = for a use case document. >>>>>>>>> %sam - nod=20 >>>>>>>>>=20 >>>>>>>>> 4. Sec 3.2 to monitor bundle links, one could perform = that with RFC4379 ping >>>>>>>>> with multpath + proxy ping. Could you kindly = differentiate if there is something >>>>>>>>> new the solution brings here? >>>>>>>>>=20 >>>>>>>>> [RG] The SR OAM author team has provided text how to monitor a = bundled link in the use case draft. You are a co-author of proxy-lsp. I = couldn't find explicit text on how to detect and monitor a bundled link = in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor = a bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. >>>>>>>>> %sam - The same steps described above could be used if each = bundled link member is identified with a unique label. While performing = tree trace or ping with multipath, LER i will respond with DDMAP info = for each of the links and the multipath info for the same. >>>>>>>>> If you say that each link member has same label stack, then = you could use lsp selectors as defined in RFC4379, in this case it is = local host dest ip addr, to identify each link member. >>>>>>>>> Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. >>>>>>>>> Same applies in your case too. Cannot see how it is different. >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 5. sec #5, Is the requirement here only for PMS to = learn the topology, in the >>>>>>>>> case of mixed env? >>>>>>>>>=20 >>>>>>>>> [RG] MPLS topology awareness is the precondition to set up = packets with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. >>>>>>>>> %sam - So, you are saying that you still need to perform = RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack.=20 >>>>>>>>> And the proposed PMS solution (not use case) is that, it = performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology. >>>>>>>>> The case you are making is that no need of bells and whistles = of RFC4379. >>>>>>>>> =20 >>>>>>>>> Question I have for you is, if data plane packets are getting = dropped and PMS packets going through, for a given LSP or Segment, how = do you know there is a problem? if you know, how do you figure out where = it is? >>>>>>>>> At least with RFC4379 and/or proxy ping, you could validate = each hop because of the bells and whistles it carries along with the = packet. >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 6. In sec 3.1, >>>>>>>>> >>>>>>>>> Determining a path to be executed prior to a = measurement may also be >>>>>>>>> done by setting up a label including all node SIDs = along that path >>>>>>>>> (if LER1 has Node SID 40 in the example and it should = be passed >>>>>>>>> between LER i and LER j, the label stack is 20 - 40 - = 30 - 10). The >>>>>>>>> advantage of this method is, that it does not involve = MPLS OAM >>>>>>>>> functionality and it is independent of ECMP = functionalities. The >>>>>>>>> method still is able to monitor all link combinations = of all paths of >>>>>>>>> an MPLS domain. If correct forwarding along the = desired paths has to >>>>>>>>> be checked, RFC4739 functionality should be applied = also in this >>>>>>>>> case. >>>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> In the above you mention that it does not involve = MPLS OAM. But later you say, >>>>>>>>> RFC4379 functionality could be used. Could you = clarify how could you verify a >>>>>>>>> path, if MPLS validation is not done. More text will = help. Also, more >>>>>>>>> importantly, the text earlier to the above says, for = valid result, MPLS >>>>>>>>> OAM has to be performed for topology changes etc. If = so, it contradicts here. >>>>>>>>>=20 >>>>>>>>> [RG] The text should say that >>>>>>>>> - without MPLS OAM functions, the PMS executes a set of paths = only based on control plane information. >>>>>>>>> - if the operator wants to make sure that data plane = corresponds to control plane, RFC4739 functions should be applied. >>>>>>>>> If you understand this statement and the text in the draft = states something different, I'll try to reword it. >>>>>>>>> %sam - The problem I am having is, in the case of MPLS, for = OAM, you have to validate the lsp. >>>>>>>>> I definitely see a specific need for SPRING, but what I feel = is, the use case is too much catered to a specific envisioned solution. >>>>>>>>> Once you remove solution or suggested enhancements, hope it = should be clear on what is being solved and scope out clear requirements = for a solution. >>>>>>>>> For solution part, please publish a separate ID. >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> 7. Last but not the least, how different is PMS from = EMS and NMS? >>>>>>>>> Somehow I couldn't find the difference what PMS could = do and >>>>>>>>> NMS/EMS couldn't. >>>>>>>>>=20 >>>>>>>>> [RG] I've never heard of an EMS/NMS which is MPLS topology = aware and uses this topology awareness to create data plane packets = executing LSP combinations as desired by an operator. Had this feature = been commercially available, the company I work for wouldn't have been = developing a PMS. >>>>>>>>> %sam - There are tools which are part of NMS/OSS, which = performs MPLS topology specific operations for a given set of LSP's. = They perform Treetrace and perform ping with multipath. Also perform LSP = specific validation by crafting packets with data available with = treetrace and ping with multipath. You could automate the workflow = without the need for OSS/PMS, by using probe technology. Will not say = beyond that :D >>>>>>>>> =20 >>>>>>>>> cheers >>>>>>>>> -sam >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> spring mailing list >>>>>>>> spring@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >=20 --Apple-Mail=_26D53505-356B-4700-8A71-7FB30DBB2F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Carlos,

Inline for my reply.
On Jul 13, = 2014, at 1:35 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

Please find inline a quick follow-up.

On Jul 13, 2014, at 9:18 AM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Carlos,

comments inline.
On Jul 13, 2014, at 12:59 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

On Jul 11, 2014, at 6:25 PM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Carlos,

On Jul 11, 2014, at 9:29 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Hi, Sam,

On Jul 11, 2014, at 12:07 PM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Carlos,

On Jul 11, 2014, at 8:49 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> = wrote:

Sam,

Just to be clear: a use-case document is not a set of abstract = generic requirements and nothing else. Use case is not requirements to = then think of a solution -- that would be a requirements document.
Neither did I ask for requirements only nor to be abstract, rather to = document to capture use cases, if that is what the authors intent for = this document is.

This document describes the specific case of how to use a specific = technology (spring) to solve a particular problem. The Abstract is = pretty clear on that:

Abstract

   This document describes features and a use case of a = path monitoring
   system.  Segment based routing enables a scalable = and simple method
   to monitor data plane liveliness of the complete set = of paths
   belonging to a single domain.  [...]

This scenario cannot be decoupled from its actual use case.
Well then the introduction says the following
<snip>
   The solution is described for a single IGP MPLS =
domain.


The solution applies to monitoring of LDP LSP's as =
well as to
   monitoring of Segment Routed =
LSP's.
...
..
The proposed solution =
offers several benefits for network monitoring.
   A single centralized monitoring device is able to monitor the
   complete set of a domains forwarding =
paths.

<snip>

Thanks for pointing these out. I think you are cherry-picking and = extrapolating the word "solution" way further than intended, and adding = meaning to it as if it supports requirements.

%s/The solution/The use case/
s/The proposed solution/The presented use case/

You are trivializing what I was eluding to in my earlier emails.
If indeed you are not talking about solution, do you think sections = 4-7 talk about use cases?
When I read the document the way it is worded and understood was to = PMS solution (sec #2) trying to solve problem in a specific. If you = don't believe, do "%s/PMS/NMS/g" and see.

Don't misconstrue that I am saying there is no use case.


I did not imply that you said there is no use case. My point is = that the "solution" is part of the use case itself, and that a use case = is not a set of requirements -- this use case document explains how the = use case works (i.e., the case of the benefits for OAM of having Source Packet Routing in Networks). You were asking = about removing solutions from the use case -- I am reacting to that. = Otherwise, I might be misunderstanding your point.
I am only providing comment, whether to remove or not is upto you, the = authors.
If you want to keep solution, that is fine too, but that will only = delay the progression of the document, because, we will be discussing = which solution is better and which isn=92t for a given use case.
I could see why some of the existing solutions could do some of the = tasks, without the need of enhancement. As you could see from my earlier = arguments, I was commenting on the solution parts, not for use = case.
I prefer to see the use case be present in a simple and concise way = and solution be deferred to solution document. Again, your call :D


I wanted to make sure I understood your point, because you always = have insightful and contractive input and feedback.

My take: What you call "solution" in the paragraph above is = actually part of the use case itself. There is no solution outside of = and external to the use case. 

A simple and concise way of presenting the context of the use case = would make for a very short draft -- see the first two sentences of the = Abstract:

   This document describes features and a use case of a = path monitoring
   system.  Segment based routing enables a scalable = and simple method
   to monitor data plane liveliness of the complete set = of paths
   belonging to a single domain.

However the use case is describing how segment based routing = enables this OAM method.
I = understand what you say but the when I read the document, I see it = otherwise. Here are few snippets.
Not cherry picking as you = put it, I could copy whole draft if you want = :D

- In Sec 3.1
Once the MPLS paths (Node SIDs) and the required IP =
address
   information has been detected, the LER i to LER j can be monitored by
   the PMS.  Monitoring doesn't require MPLS OAM functionality, it is
   purely based on forwarding.

When the text = assert that MPLS OAM is not required, that is where I see as a problem = as it is clearly comparing the the solution. Your intention here may be = that (putting words in your mouth) it is one of the methods to do so, = but I read the text differently.

- In Sec 3.1 = again
Monitoring an MPLS domain by a PMS =
based on SR offers the option of
   monitoring complete MPLS domains with little effort and very
   excellent scalability.  Data plane failure detection by circulating
   monitoring packets can be executed at any time.  The PMS further
   executes MPLS OAM functions everywhere in the MPLS domain.  It does
   not require access to LSR/LER management interfaces to do so.  MPLS
   traceroutes as specified above should be executed only during off
   peak times (and then with limited parallel MPLS ping/trace =
load).

Here too, I see it applies more to = a specific solution. I=92d rather see the text eluding something like = (may not be exact) =93Liveness detection of the data plane in the SR = could be performed between any segments initiated from non LSR/LER = environments"

- Sec = 7

While the PMS based use cases =
explained in Section 3 is sufficient to
   provide Continuity check between LER i and LER j, it may not help
   perform connectivity verification.  So in some cases like data plane
   programming corruption, it is possible that a transit node between
   LER i and LER j erroneously remove the top segment ID and forward to
   PMS based on bottom segment ID leading to falsified path liveliness
   to PMS.

I read the text (and = subsequent text in the section) as describing how the connectivity = verification solution by PMS should be = performed.

=46rom your emails I understand the = intention and goal. Edits to the text and making it non-solution = specific is what I feel is = needed.

cheers
-sam



To provide more reason for my argument, for ex: why should I care = RFC4379 solve a specific use case or not? Use case is valid but it could = be solved multiple ways. Similarly, I need not solve a use case with = PMS, rather I could do with NMS. I do hope you see my point.


These are use cases that get enabled by Source Packet Routing in = Networks. In the context of OAM, new ways of doing network-wide path = monitoring are enabled. The point of the use case is how it can be done = in spring networks that it cannot in non-spring ones.






I agree that additional text on showing how proxy-lsp-ping could = support it can potentially be useful, but not with "remove all = solutions". Further, maybe the use case can be generalized even = more.


Again, it is up to you authors what to retain in the document or = what to add.
We could review accordingly.
If there are solutions and proposals to existing solutions in this = ID, then it will lead into solutions discussions, which is what is = happening right now.


What I think would be more useful would be to channel the review = cycles towards oam uses that get enabled by the spring architecture. = That is,
* is this a simple remote (proxy?) realization/use for oam in = spring networks?
* can this use case be generalized to the spring ipv6 dataplane? [I = think so]
* can this use case be used with S-BFD?

In addition, this document should add more details about the scenarios = of IPv6 w.r.t SR, or add specific pointers for the same.

Certainly these scenarios need to also be documented.
cool

thanks

Anytime.

Thanks,

Carlos.


-sam

Also consider the comments in my earlier emails. As far as S-BFD = goes, refer to sec 3.4 of S-BFD use case document.


Yes, this citations should be good.

Thanks,

Carlos.

-sam


Thanks,

Carlos.

cheers
-sam

Thanks,

Carlos.

On Jul 11, 2014, at 11:24 AM, Sam Aldrin <aldrin.ietf@gmail.com> = wrote:

Hi Rudiger,

As I acknowledged in my earlier emails, the question is not about = valid use cases exist or not, rather it is about the document and what = the text says. Document is not clear on just use cases only because it = touches various solution aspects, which is unnecessary. For example, use cases should not care what RFC4379 can or cannot, that = discussion should happen after the requirements which gets originated by = these use cases.

Once you cleanup the document and remove solution specific parts, = it should be ok. We could defer the discussion of what the existing = solutions could and could not do, for solution document and continue = discussions of those pieces, then.

cheers
-sam


On Jul 11, 2014, at 12:15 AM, <Ruediger.Geib@telekom.de> = <Ruediger.Geib@telekom.de> = wrote:

Hi Nobo, hi = Sam
 
the use case is to enable = monitoring of an MPLS domain without accessing the control plane. To do = so, a PMS needs MPLS topology awareness, which it gets by Segment Routing. The draft to some extent explains how that is done, = without going into too many details, I think.
 
Monitoring without control plane = access is part of the use case, not part of a solution discussion (to = say it differently: using the data plane for OAM purposes is not an option which may be removed). As many SR based OAM features = can be used without OAM specific protocols or functions being added to = Segment Routing, I think it=92s perfectly ok to formulate the use case = as is. The main requirement is: specify Segment Routing. Then one may add OAM boxes which apply SR = features.
 
RFC4379 could also monitor LSPs, = but it requires using the control plane and proxy-lsp-ping adds control = plane based functionality to RFC4379. It is an approach resulting in similar features, but it is control plane based. This is a = different use case.
 
If an operator needs to validate = that a packet travels a certain path or trace the path a lost packet has = taken, then RFC4379 functionality is needed. It=92s a difference whether RFC4379 is applied only at off peak times or after = a data plane only monitoring packet has been lost along one path or = whether that has to be done constantly.
 
Regards,
 
Ruediger
 
Von: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Gesendet: Donnerstag, 10. Juli 2014 = 21:46
An: Sam = Aldrin
Cc: Geib, = R=FCdiger; spring; draft-geib-spring-oam-usecase
Betreff: RE: = [spring] Questions
 
Hi Sam,
 
I just wanted to point out the key = described behavior, wasn=92t saying anything about whether this document = should be a use-case document or a solution document J
 
Thanks!
 
-Nobo
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Thursday, = July 10, 2014 3:10 PM
To: Nobo Akiya = (nobo)
Cc: Ruediger.Geib@telekom.de; spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Nobo,
 
Inline for my comments.
 
On Thu, Jul 10, 2014 at 11:59 AM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:
Hi Sam,
 
Just to point out one thing about = this document =85
 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
That is fine as a requirement/usecase and we should = limit the scope to that, than specifying how to solve = it.
 
That makes this approach quite = different from using proxy LSP ping.
You are talking about solution or use case? = :D
 
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
Certainly. But I am struggling between use case and = solution outlined in the document. Pick one :D
 
-sam 
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, = July 10, 2014 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: = [spring] Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi Sam,

my replies are marked [RG] and added to your text.

- Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the = draft.
- Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=B9s a solution with broader scope and better fit for = SPRING as a whole. 
%sam - I believe you say it is use case document = below. Then solution is too premature at this point of time, as we = haven't deliberated on the requirements = either. 

As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin wrote:

      I have few questions about this draft.

      1. The title is confusing to me. It says OAM use = case but in section #1
      it says the following

      <snip>
       This document describes a solution to this = problem statement and
       illustrates it with use-cases.

       The solution is described for a single IGP = MPLS domain.

       The solution applies to monitoring of LDP = LSP's as well as to
       monitoring of Segment Routed LSP's.
      <end snip>

       In fact the draft is describing a solution to = certain scenarios and not just
       providing use cases/scenarios. My = understanding was, use case draft should
       document scenarios where it will drive new = requirements. Solutions could
       be covered with existing toolset or defined = newly, depending on the GAP
       analysis. But that should be separate as = there could be more than 1 solution,
       where as this document could just focus on = use cases only.

       If infact this is supposed to be a solution = document, then changing the title
       would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review = the text of section 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with :D
 


       2. w.r.t. Section number #2, the same problem = is being solved with
       "draft-ietf-mpls-proxy-lsp-ping-02" . What is = being described in this
       section could be done with the proxy = ping(solution wise) where, request could
       be sent to monitor LER i and LER j segment, = from a PMS. Is my understanding
       right? If not, how is it different = here?

[RG] The PMS is able to set up packets which stay = in data plane and execute a desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform = something else? 

[RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to
   allow a third party to remotely cause an MPLS Echo Request = message to
   be sent down a LSP or part of an = LSP.
%sam - If it is proposing extensions,  it has = to be solution document  and cannot claim to be use case document. = Also this document is on information track.

[RG] I take it as saying that if you'd like to remotely execute RFC4379 = functionality on any LSP, you could either use the PMS or proxy-ping. = The PMS however simplifies and adds
functionality:
a) You don't need an additional protocol or functionality like = proxy-ping to check data
   plane liveliness, RFC4379 is fine. Deutsche Telekom = operates a PMS implementation.
%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to = perform validation checks. For liveness detection, BFD is preferred = tool, atleast in present deployments.So are you saying, PMS solution is designed for liveness detection and not to perform = validation of data plane to control plane, etc? (I think you agree to = this in the later part of the doc also)
 
b) once PMS detected data plane liveliness and = correctness of MPLS topology by RFC4379,
   it can continue to execute arbitrary LSP combinations and = the monitoring packets stay
   in data plane. Please point me to the text in proxy-ping = offering this feature.
%sam - This you could perform even without proxy = ping. The function you are describing is, how you use lsp ping rather = than what lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with = its multipath implementation.
- perform ping with right selectors for the path = and use TTL for limiting the hop [LER j].
- if you want to perform from LER i to LER j as in = your draft, use proxy ping to start from LER i


        3. When the response is sent back to PMS = which is not part of MPLS or segment
        domain, there is a serious security aspect, = which needs to considered. I believe
        it applies to sending a request too. Will = you be documenting that aspect?

[RG] That's a valid point. The domain external = system is one option and the team will deal with the security aspects = raised by this option once we are in solution space. We will not analyse = this in depth for a use case document.
%sam - nod 


        4. Sec 3.2 to monitor bundle links, one = could perform that with RFC4379 ping
        with multpath + proxy ping. Could you kindly = differentiate if there is something
        new the solution brings = here?

[RG] The SR OAM author team has provided text how = to monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a bundled link (sorry if this is = obvious and I missed it). If there are differences to the SR OAM = approach, we'll discuss them.
%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the same.
If you say that each link member has same label = stack, then you could use lsp selectors as defined in RFC4379, in this = case it is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled = link as one interface but cannot discern its link members, then you = could only validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is the requirement here = only for PMS to learn the topology, in the
            case of mixed = env?

[RG] MPLS topology awareness is the precondition to = set up packets with label stacks executing a desired chain of LSPs. If = suitable Label/FEC/node relation is known to the PMS, that LSP can be = executed from that node on by a PMS monitoring packet.
%sam - So, you are saying that you still need to = perform RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is = that, it performs on demand per segment, which Proxy ping also does, = albeit only for MPLS topology.
The case you are making is that no need of bells = and whistles of RFC4379.
 
Question I have for you is, if data plane packets = are getting dropped and PMS packets going through, for a given LSP or = Segment, how do you know there is a problem? if you know, how do you = figure out where it is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



         6. In sec 3.1,
         <snip>
         Determining a path to be executed = prior to a measurement may also be
         done by setting up a label including = all node SIDs along that path
         (if LER1 has Node SID 40 in the = example and it should be passed
         between LER i and LER j, the label = stack is 20 - 40 - 30 - 10).  The
         advantage of this method is, that it = does not involve MPLS OAM
         functionality and it is independent of = ECMP functionalities.  The
         method still is able to monitor all = link combinations of all paths of
         an MPLS domain.  If correct = forwarding along the desired paths has to
         be checked, RFC4739 functionality = should be applied also in this
         case.

         <end snip>

         In the above you mention that it does = not involve MPLS OAM. But later you say,
         RFC4379 functionality could be used. = Could you clarify how could you verify a
         path, if MPLS validation is not done. = More text will help. Also, more
         importantly, the text earlier to the = above says, for valid result, MPLS
         OAM has to be performed for topology = changes etc. If so, it contradicts here.

[RG] The text should say that
- without MPLS OAM functions, the PMS executes a set of paths only based = on control plane information.
- if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied.
If you understand this statement and the text in the draft states = something different, I'll try to reword it.
%sam - The problem I am having is, in the case of = MPLS, for OAM, you have to validate the lsp.
I definitely see a specific need for SPRING, but = what I feel is, the use case is too much catered to a specific = envisioned solution.
Once you remove solution or suggested enhancements, = hope it should be clear on what is being solved and scope out clear = requirements for a solution.
For solution part, please publish a separate = ID.
 


         7. Last but not the least, how = different is PMS from EMS and NMS?
         Somehow I couldn't find the difference = what PMS could do and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS = topology aware and uses this topology awareness to create data plane = packets executing LSP combinations as desired by an operator. Had this = feature been commercially available, the company I work for wouldn't have been developing a PMS.
%sam - There are tools which are part of NMS/OSS, = which performs MPLS topology specific operations  for a given set = of LSP's. They perform Treetrace and perform ping with multipath. Also = perform LSP specific validation by crafting packets with data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that :D
 
cheers
-sam

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




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


= --Apple-Mail=_26D53505-356B-4700-8A71-7FB30DBB2F37-- From nobody Mon Jul 14 09:25:36 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C271A0AC4 for ; Mon, 14 Jul 2014 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8kUX2SmZdhi for ; Mon, 14 Jul 2014 09:25:24 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148C91A0ADA for ; Mon, 14 Jul 2014 09:25:24 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so5503889pde.10 for ; Mon, 14 Jul 2014 09:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PsLdZmXpqdeRINJBd85J++6LqU9r8w4SYrax4biBxdg=; b=mXB/YG4pBaXS+8Of9nc0Qb87VQb2Qk5Q5339v1tbxG4XwFi2XoE0J0eD7gI/3Be6y9 XoQIBni5dksRfJcOQDlEZWEH7aqzxYJyn52VawkbRXI+qvecv9CEwcweYV+HVaMhlVGr YVHjjg+2Hi2cnupIKzNPEBGE1oGS9aK5tHolgQsC93lL0dEBoWExr8wWQbx69zb2fi7Y R03iVVAyRQQIbaBjXRfO1K+To0r0ZmhFJ3RbirnD5SHxVUtRkkdAKvDYl4Dx0MSSkMBa 1lcse3sj5kAGNsL1q530v1NXOILBkX1DM2sFEzXxdyss51X6x2pqBok5tSI4E62DpSX/ V/Dw== X-Received: by 10.70.38.203 with SMTP id i11mr727232pdk.162.1405355123749; Mon, 14 Jul 2014 09:25:23 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id dn10sm15069557pdb.95.2014.07.14.09.25.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 09:25:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5476A096-BDF0-4A2F-B334-97F41CF79FF7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 14 Jul 2014 09:25:20 -0700 Message-Id: References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/SekP-Evg2eRcebmDxTSI8gBLi5Q Cc: "Ruediger.Geib@telekom.de" , spring , draft-geib-spring-oam-usecase , Qin Wu Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:25:27 -0000 --Apple-Mail=_5476A096-BDF0-4A2F-B334-97F41CF79FF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nobo, On Jul 14, 2014, at 5:39 AM, Nobo Akiya (nobo) wrote: > Hi Qin, et al, > =20 > Each network node will still have some states (i.e. = node/adjacency/service segments). > =20 > I see the technique described draft-geib-spring-oam-usecase as a way = to monitor the network, but not a way to validate the segments. In = particular the following aspects cannot be validated by the technique = described draft-geib-spring-oam-usecase. > =20 > 1. Using a segment or combination of segments result in a packet = to reach an expected network node. > 2. Using an adjacency segment results in a packet to traverse = over an expected adjacency. > 3. Using a service segment results in a packet to hit an expected = service. > =20 > This is why I previously mentioned that the technique is useful as one = of the OAMs used to monitor the network. Without going too much into it, the question is not about the need for a = technique and this use case document should do that exactly. But what I would like to see the scope/text not deliberate on the = specifics of the solution, which I think was affirmed by you and others. If you read the document as is, it proposes a solution(Introduction) and = using that filter, I see the document more of a solution than just use = case.=20 I do hope we are in agreement, cleaning up the doc will remove the = confusion. We could take solution specific discussions to different ID=E2=80=99s. -sam > =20 > In other words, we would still want things in addition to validate the = states on each network node so that, when ingresses steer packets using = combinations segments (that makes use of those states), then expected = and actual paths aligns. > =20 > I intentionally didn=E2=80=99t answer your question on the usefulness = of Proxy LSP Ping n Segment Routing, but I wanted to highlight what are = the additional points we would want to cover from OAM perspective. > =20 > Thanks! > =20 > -Nobo > = =20 > From: Qin Wu [mailto:bill.wu@huawei.com]=20 > Sent: Monday, July 14, 2014 5:08 AM > To: Nobo Akiya (nobo); Sam Aldrin; Ruediger.Geib@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: RE: [spring] Questions > =20 > Very good point, since segment routing doesn=E2=80=99t require each = network node in the path to maintain state and only ingress node = maintains the state while > Proxy-lsp-ping require each network node in the return path to = maintain the state. > Why apply Proxy-lsp-ping to spring OAM? > =20 > Regards! > -Qin > =E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Nobo Akiya (nobo) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5= 3:00 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de > =E6=8A=84=E9=80=81: spring; draft-geib-spring-oam-usecase > =E4=B8=BB=E9=A2=98: Re: [spring] Questions > =20 > Hi Sam, > =20 > Just to point out one thing about this document =E2=80=A6 > =20 > The test packet generated from a PMS/NMS/EMS/network-device can have = the complete segment stack on how to traverse the network as well as how = to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. > =20 > That makes this approach quite different from using proxy LSP ping. > =20 > This certainly has some pros and cons but can be quite useful as one = of the OAMs (yes plural) used to monitor the network. > =20 > Thanks! > =20 > -Nobo > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 10, 2014 2:13 PM > To: Ruediger.Geib@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > =20 > Hi Ruediger, > =20 > Thanks for the quick response. Please find my responses inline. > =20 >=20 > On Thu, Jul 10, 2014 at 7:15 AM, wrote: > Hi Sam, >=20 > my replies are marked [RG] and added to your text. >=20 > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6) >=20 > Based on that, it=C2=B9s a solution with broader scope and better fit = for SPRING as a whole.=20 > %sam - I believe you say it is use case document below. Then solution = is too premature at this point of time, as we haven't deliberated on the = requirements either.=20 >=20 > As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >=20 > Regards, >=20 > Ruediger >=20 >=20 > Sam Aldrin wrote: >=20 > I have few questions about this draft. >=20 > 1. The title is confusing to me. It says OAM use case but in = section #1 > it says the following >=20 > > This document describes a solution to this problem statement = and > illustrates it with use-cases. >=20 > The solution is described for a single IGP MPLS domain. >=20 > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > >=20 > In fact the draft is describing a solution to certain scenarios = and not just > providing use cases/scenarios. My understanding was, use case = draft should > document scenarios where it will drive new requirements. = Solutions could > be covered with existing toolset or defined newly, depending on = the GAP > analysis. But that should be separate as there could be more = than 1 solution, > where as this document could just focus on use cases only. >=20 > If infact this is supposed to be a solution document, then = changing the title > would be more meaningful. That's my observation. >=20 > [RG] Thanks. It's a use case document. We'll review the text of = section 1. > %sam - OK. then I'd like to see any specific solution content removed, = that way we dont have to discuss what other solutions does either or = compare with :D > =20 >=20 > 2. w.r.t. Section number #2, the same problem is being solved = with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described = in this > section could be done with the proxy ping(solution wise) where, = request could > be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding > right? If not, how is it different here? >=20 > [RG] The PMS is able to set up packets which stay in data plane and = execute a desired > chain of MPLS LSPs. > %sam - Execute you mean traverse? or perform something else?=20 >=20 > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message = to > be sent down a LSP or part of an LSP. > %sam - If it is proposing extensions, it has to be solution document = and cannot claim to be use case document. Also this document is on = information track. >=20 > [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like = proxy-ping to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation. > %sam - RFC4379 performs validation of dataplane and also find out lot = more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) > =20 > b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the = monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering = this feature. > %sam - This you could perform even without proxy ping. The function = you are describing is, how you use lsp ping rather than what lsp ping = does. Again I am not talking about non-mpls topology. > To answer your question, how you perform. > - Perform treetrace with rfc4379 to get topology info > - pick any arbitary LSP paths discovered along with its multipath = implementation. > - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. > - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >=20 > 3. When the response is sent back to PMS which is not part of = MPLS or segment > domain, there is a serious security aspect, which needs to = considered. I believe > it applies to sending a request too. Will you be documenting = that aspect? >=20 > [RG] That's a valid point. The domain external system is one option = and the team will deal with the security aspects raised by this option = once we are in solution space. We will not analyse this in depth for a = use case document. > %sam - nod=20 >=20 > 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if = there is something > new the solution brings here? >=20 > [RG] The SR OAM author team has provided text how to monitor a bundled = link in the use case draft. You are a co-author of proxy-lsp. I couldn't = find explicit text on how to detect and monitor a bundled link in = draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a = bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. > %sam - The same steps described above could be used if each bundled = link member is identified with a unique label. While performing tree = trace or ping with multipath, LER i will respond with DDMAP info for = each of the links and the multipath info for the same. > If you say that each link member has same label stack, then you could = use lsp selectors as defined in RFC4379, in this case it is local host = dest ip addr, to identify each link member. > Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. > Same applies in your case too. Cannot see how it is different. > =20 >=20 >=20 > 5. sec #5, Is the requirement here only for PMS to learn the = topology, in the > case of mixed env? >=20 > [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. > %sam - So, you are saying that you still need to perform RFC4379 trace = or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 > And the proposed PMS solution (not use case) is that, it performs on = demand per segment, which Proxy ping also does, albeit only for MPLS = topology. > The case you are making is that no need of bells and whistles of = RFC4379. > =20 > Question I have for you is, if data plane packets are getting dropped = and PMS packets going through, for a given LSP or Segment, how do you = know there is a problem? if you know, how do you figure out where it is? > At least with RFC4379 and/or proxy ping, you could validate each hop = because of the bells and whistles it carries along with the packet. > =20 >=20 >=20 > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may = also be > done by setting up a label including all node SIDs along that = path > (if LER1 has Node SID 40 in the example and it should be = passed > between LER i and LER j, the label stack is 20 - 40 - 30 - = 10). The > advantage of this method is, that it does not involve MPLS = OAM > functionality and it is independent of ECMP functionalities. = The > method still is able to monitor all link combinations of all = paths of > an MPLS domain. If correct forwarding along the desired = paths has to > be checked, RFC4739 functionality should be applied also in = this > case. >=20 > >=20 > In the above you mention that it does not involve MPLS OAM. = But later you say, > RFC4379 functionality could be used. Could you clarify how = could you verify a > path, if MPLS validation is not done. More text will help. = Also, more > importantly, the text earlier to the above says, for valid = result, MPLS > OAM has to be performed for topology changes etc. If so, it = contradicts here. >=20 > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. > - if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states = something different, I'll try to reword it. > %sam - The problem I am having is, in the case of MPLS, for OAM, you = have to validate the lsp. > I definitely see a specific need for SPRING, but what I feel is, the = use case is too much catered to a specific envisioned solution. > Once you remove solution or suggested enhancements, hope it should be = clear on what is being solved and scope out clear requirements for a = solution. > For solution part, please publish a separate ID. > =20 >=20 > 7. Last but not the least, how different is PMS from EMS and = NMS? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. >=20 > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and = uses this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. > %sam - There are tools which are part of NMS/OSS, which performs MPLS = topology specific operations for a given set of LSP's. They perform = Treetrace and perform ping with multipath. Also perform LSP specific = validation by crafting packets with data available with treetrace and = ping with multipath. You could automate the workflow without the need = for OSS/PMS, by using probe technology. Will not say beyond that :D > =20 > cheers > -sam --Apple-Mail=_5476A096-BDF0-4A2F-B334-97F41CF79FF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Nobo,

On Jul 14, 2014, at 5:39 AM, Nobo Akiya (nobo) = <nobo@cisco.com> = wrote:

Hi Qin, et al,
 
Each network node will = still have some states (i.e. node/adjacency/service = segments).
 
I see the technique described = draft-geib-spring-oam-usecase as a way to monitor the network, but not a = way to validate the segments. In particular the following aspects cannot = be validated by the technique described = draft-geib-spring-oam-usecase.
 
1.      Using a segment or combination of segments result in = a packet to reach an expected network node.
2.      Using an adjacency segment results in a packet to = traverse over an expected adjacency.
3.      Using a service segment results in a packet to hit an = expected service.
 
This is why I previously mentioned that the technique = is useful as one of the OAMs used to monitor the = network.
Without going too much = into it, the question is not about the need for a technique and this use = case document should do that exactly.
But what I would like to = see the scope/text not deliberate on the specifics of the solution, = which I think was affirmed by you and = others.

If you read the document as is, it = proposes a solution(Introduction) and using that filter, I see the = document more of a solution than just use case. 
I do = hope we are in agreement, cleaning up the doc will remove the = confusion.

We could take solution specific = discussions to different = ID=E2=80=99s.

-sam
 
In other words, we would still want things in = addition to validate the states on each network node so that, when = ingresses steer packets using combinations segments (that makes use of = those states), then expected and actual paths = aligns.
 
I intentionally didn=E2=80=99t answer your question = on the usefulness of Proxy LSP Ping n Segment Routing, but I wanted to = highlight what are the additional points we would want to cover from OAM = perspective.
 
Thanks!
 
-Nobo
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;  
From: Qin Wu [mailto:bill.wu@huawei.com] 
Sent: Monday, July 14, 2014 5:08 = AM
To: Nobo = Akiya (nobo); Sam Aldrin; Ruediger.Geib@telekom.de
<= b>Cc: spring; = draft-geib-spring-oam-usecase
Subject: RE: [spring] = Questions
 
Very good point, since segment = routing doesn=E2=80=99t require each network node in the path to = maintain state and only ingress node maintains the state = while
Proxy-lsp-ping require each = network node in the return path to maintain the = state.
Why apply Proxy-lsp-ping to spring = OAM?
 
Regards!
-Qin
=E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Nobo = Akiya (nobo)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5 3:00
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de
=E6=8A=84=E9=80=81: spring; = draft-geib-spring-oam-usecase
=E4=B8=BB=E9=A2=98: Re: [spring] = Questions
 
Hi = Sam,
 
Just to point out one thing about this document = =E2=80=A6
 
The test packet generated from a = PMS/NMS/EMS/network-device can have the complete segment stack on how to = traverse the network as well as how to come back to self without any = further signaling, OAM state maintenance on network nodes nor OAM = involvement by network nodes.
 
That makes this approach = quite different from using proxy LSP ping.
 
This certainly has some = pros and cons but can be quite useful as one of the OAMs (yes plural) = used to monitor the network.
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, July 10, 2014 = 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: [spring] = Questions
 
Hi Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> = wrote:
Hi = Sam,

my replies are marked [RG] and added to your text.

- = Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for = every SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- = Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=C2=B9s a solution with broader scope = and better fit for SPRING as a = whole. 
%sam - I believe you say it is use case document below. = Then solution is too premature at this point of time, as we haven't = deliberated on the requirements = either. 

As you write, SR based = OAM partially offers similar functions as proxy-lsp. Without requiring = the additional messages and LER/LSR processing introduced by = proxy-lsp. 

Regards,

Ruediger



    =   Sam Aldrin wrote:

      I have few = questions about this draft.

      1. The title is = confusing to me. It says OAM use case but in section #1
    =   it says the following

      = <snip>
       This document describes a = solution to this problem statement and
      =  illustrates it with use-cases.

      =  The solution is described for a single IGP MPLS = domain.

       The solution applies to = monitoring of LDP LSP's as well as to
      =  monitoring of Segment Routed LSP's.
      = <end snip>

       In fact the draft is = describing a solution to certain scenarios and not just
    =    providing use cases/scenarios. My understanding was, use = case draft should
       document scenarios where = it will drive new requirements. Solutions could
      =  be covered with existing toolset or defined newly, depending on = the GAP
       analysis. But that should be = separate as there could be more than 1 solution,
      =  where as this document could just focus on use cases = only.

       If infact this is supposed to be = a solution document, then changing the title
      =  would be more meaningful. That's my = observation.

[RG] Thanks. It's a use case document. We'll review the = text of section 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with = :D
 


       2. w.r.t. Section number = #2, the same problem is being solved with
      =  "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in = this
       section could be done with the proxy = ping(solution wise) where, request could
      =  be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding
       right? If not, how is it = different here?

[RG] The PMS is able to set up packets which stay in data = plane and execute a desired
     chain of MPLS = LSPs.
%sam - Execute you mean traverse? or perform something = else? 

[RG] Proxy-lsp says: = This document defines protocol extensions to MPLS ping [RFC4379] = to
   allow a third party to remotely cause an MPLS Echo = Request message to
   be sent down a LSP or part of an = LSP.
%sam - If it is proposing extensions,  it has to be = solution document  and cannot claim to be use case document. Also = this document is on information = track.

[RG] I take it as = saying that if you'd like to remotely execute RFC4379 functionality on = any LSP, you could either use the PMS or proxy-ping. The PMS however = simplifies and adds
functionality:
a) You don't need an additional = protocol or functionality like proxy-ping to check data
  =  plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation.
%sam - RFC4379 performs validation of = dataplane and also find out lot more errors. You need additional = information to perform validation checks. For liveness detection, BFD is = preferred tool, atleast in present deployments.So are you saying, PMS = solution is designed for liveness detection and not to perform = validation of data plane to control plane, etc? (I think you agree to = this in the later part of the doc = also)
 
b) once PMS detected data = plane liveliness and correctness of MPLS topology by RFC4379,
  =  it can continue to execute arbitrary LSP combinations and the = monitoring packets stay
   in data plane. Please point me = to the text in proxy-ping offering this = feature.
%sam - This you could perform even without proxy ping. The = function you are describing is, how you use lsp ping rather than what = lsp ping does. Again I am not talking about non-mpls = topology.
To answer your question, how you = perform.
- Perform treetrace with rfc4379 to get topology = info
- pick any arbitary LSP paths discovered along with its = multipath implementation.
- perform ping with right selectors for the = path and use TTL for limiting the hop [LER = j].
- if you want to perform from LER i to LER j as in your = draft, use proxy ping to start from LER = i


        3. When the response is = sent back to PMS which is not part of MPLS or segment
    =     domain, there is a serious security aspect, which needs to = considered. I believe
        it applies to = sending a request too. Will you be documenting that = aspect?

[RG] That's a valid point. The domain external system is = one option and the team will deal with the security aspects raised by = this option once we are in solution space. We will not analyse this in = depth for a use case = document.
%sam - nod 


        4. Sec 3.2 to monitor = bundle links, one could perform that with RFC4379 ping
    =     with multpath + proxy ping. Could you kindly differentiate = if there is something
        new the solution = brings here?

[RG] The SR OAM author team has provided text how to = monitor a bundled link in the use case draft. You are a co-author of = proxy-lsp. I couldn't find explicit text on how to detect and monitor a = bundled link in draft-proxy-lsp. Please describe how proxy-lsp can be = used to monitor a bundled link (sorry if this is obvious and I missed = it). If there are differences to the SR OAM approach, we'll discuss = them.
%sam - The same steps described above could be used if = each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the = same.
If you say that each link member has same label stack, = then you could use lsp selectors as defined in RFC4379, in this case it = is local host dest ip addr, to identify each link = member.
Now if the MPLS forwarding layer sees the bundled link as = one interface but cannot discern its link members, then you could only = validate the interface and not its individual = members.
Same applies in your case too. Cannot see how it is = different.
 



         5. sec #5, Is = the requirement here only for PMS to learn the topology, in = the
            case of mixed = env?

[RG] MPLS = topology awareness is the precondition to set up packets with label = stacks executing a desired chain of LSPs. If suitable Label/FEC/node = relation is known to the PMS, that LSP can be executed from that node on = by a PMS monitoring = packet.
%sam - So, you are saying that you still need to perform = RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is that, it = performs on demand per segment, which Proxy ping also does, albeit only = for MPLS topology.
The case you are making is that no need of bells and = whistles of RFC4379.
 
Question I have for you is, if data plane = packets are getting dropped and PMS packets going through, for a given = LSP or Segment, how do you know there is a problem? if you know, how do = you figure out where it is?
At least with RFC4379 and/or proxy ping, you = could validate each hop because of the bells and whistles it carries = along with the packet.
 



         6. In sec = 3.1,
         <snip>
    =      Determining a path to be executed prior to a = measurement may also be
         done by = setting up a label including all node SIDs along that path
  =        (if LER1 has Node SID 40 in the example and = it should be passed
         between LER i = and LER j, the label stack is 20 - 40 - 30 - 10).  The
  =        advantage of this method is, that it does not = involve MPLS OAM
         functionality and = it is independent of ECMP functionalities.  The
    =      method still is able to monitor all link = combinations of all paths of
         an = MPLS domain.  If correct forwarding along the desired paths has = to
         be checked, RFC4739 = functionality should be applied also in this
      =    case.

         <end = snip>

         In the above you = mention that it does not involve MPLS OAM. But later you say,
  =        RFC4379 functionality could be used. Could = you clarify how could you verify a
        =  path, if MPLS validation is not done. More text will help. Also, = more
         importantly, the text earlier = to the above says, for valid result, MPLS
        =  OAM has to be performed for topology changes etc. If so, it = contradicts here.

[RG] The text should say that
- without MPLS OAM = functions, the PMS executes a set of paths only based on control plane = information.
- if the operator wants to make sure that data plane = corresponds to control plane, RFC4739 functions should be applied.
If = you understand this statement and the text in the draft states something = different, I'll try to reword = it.
%sam - The problem I am having is, in the case of MPLS, = for OAM, you have to validate the = lsp.
I definitely see a specific need for SPRING, but what I = feel is, the use case is too much catered to a specific envisioned = solution.
Once you remove solution or suggested enhancements, hope = it should be clear on what is being solved and scope out clear = requirements for a solution.
For solution part, please publish a separate = ID.
 


         7. Last but not the = least, how different is PMS from EMS and NMS?
      =    Somehow I couldn't find the difference what PMS could do = and
         NMS/EMS = couldn't.

[RG] I've never heard of an EMS/NMS which is MPLS topology = aware and uses this topology awareness to create data plane packets = executing LSP combinations as desired by an operator. Had this feature = been commercially available, the company I work for wouldn't have been = developing a PMS.
%sam - There are tools which are part of = NMS/OSS, which performs MPLS topology specific operations  for a = given set of LSP's. They perform Treetrace and perform ping with = multipath. Also perform LSP specific validation by crafting packets with = data available with treetrace and ping with multipath. You could = automate the workflow without the need for OSS/PMS, by using probe = technology. Will not say beyond that = :D
 
cheers
-sam
<= /div>

= --Apple-Mail=_5476A096-BDF0-4A2F-B334-97F41CF79FF7-- From nobody Mon Jul 14 19:46:38 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B151B27F6 for ; Mon, 14 Jul 2014 19:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIHcwbRv3lOz for ; Mon, 14 Jul 2014 19:46:32 -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 88C351A026C for ; Mon, 14 Jul 2014 19:46:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA82714; Tue, 15 Jul 2014 02:46:29 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 03:46:27 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 10:46:24 +0800 From: Qin Wu To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7JhndME/roR0Kh13/N0Tpo0QAT5ZsQAA/kkXD//77CAIAADOQA//naTZCADDD5AP/+u3BQ Date: Tue, 15 Jul 2014 02:46:23 +0000 Message-ID: References: <43C21A33-ED76-4335-9568-62B5088E22ED@gmail.com> In-Reply-To: <43C21A33-ED76-4335-9568-62B5088E22ED@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84582F10nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ciV5aK4Vzev42OWhfVYIK816nJw Cc: "Nobo Akiya \(nobo\)" , draft-geib-spring-oam-usecase , spring , "Ruediger.Geib@telekom.de" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 02:46:36 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84582F10nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQrlj5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggU2FtIEFsZHJpbg0K5Y+R6YCB5pe26Ze0OiAyMDE05bm0N+aciDE05pelIDIzOjE4DQrmlLbk u7bkuro6IFFpbiBXdQ0K5oqE6YCBOiBOb2JvIEFraXlhIChub2JvKTsgc3ByaW5nOyBkcmFmdC1n ZWliLXNwcmluZy1vYW0tdXNlY2FzZTsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlDQrkuLvpopg6 IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnMNCg0KDQpPbiBKdWwgMTQsIDIwMTQsIGF0IDI6MDcgQU0s IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PiB3 cm90ZToNCg0KDQpWZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQgcm91dGluZyBkb2VzbuKA mXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcGF0aCB0byBtYWludGFpbiBzdGF0 ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0ZSB3aGlsZQ0KUHJveHkt bHNwLXBpbmcgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcmV0dXJuIHBhdGggdG8g bWFpbnRhaW4gdGhlIHN0YXRlLg0KDQpXcm9uZyENCk5vIHN0YXRlIGlzIG1haW50YWluZWQgZXhj ZXB0IGluIHRoZSBpbml0aWF0b3IuDQoNCltRaW5dOiBJIGFtIGEgbGl0dGxlIGJpdCBjb25mdXNl ZCB3aGVuIHlvdSBzYXkgbm8gc3RhdGUgaXMgbWFpbnRhaW5lZCBpbiBvdGhlciBuZXR3b3JrIG5v ZGUuDQpEb2VzIFByb3h5LWxzcC1waW5nIHJlcXVpcmUgdGhlIHBhdGggdG8gYmUgc2V0dXAgYmVm b3JlIGluaXRpYXRpbmcgcHJveHkgTFNQIHBpbmcgbWVzc2FnZT8NCkhvdyBkb2VzIHRoZSBpbml0 aWF0b3Iga25vdyB0aGUgdXBzdHJlYW0gbmVpZ2hib3IncyB1cHN0cmVhbSBuZWlnaGJvcj8NClNl Y3Rpb24gMiBvZiAgZHJhZnQtaWV0Zi1tcGxzLXByb3h5LWxzcC1waW5nLTAyIHNhaWQ6DQrigJwN ClRoZSBpbml0aWF0b3IgcmVxdWVzdHMgUHJveHkgaW5mb3JtYXRpb24gc28gdGhhdCBpdCBjYW4g bGVhcm4gYWRkaXRpb25hbA0KaW5mb3JtYXRpb24gaXQgbmVlZHMgdG8gdXNlIHRvIGZvcm0gYSBz dWJzZXF1ZW50IE1QTFMgUHJveHkgUGluZw0KcmVxdWVzdC7igJ0NCkhvdyBkb2VzICBwcm94eSBM U1AgaGF2ZSBwcm94eSBpbmZvcm1hdGlvbj8gRG9lcyBpdCByZXF1aXJlIHBhdGggc2V0dXAgaW4g YWR2YW5jZT8NClBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcuDQoNCi1zYW0NCg0KV2h5 IGFwcGx5IFByb3h5LWxzcC1waW5nIHRvIHNwcmluZyBPQU0/DQoNClJlZ2FyZHMhDQotUWluDQrl j5Hku7bkuro6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6Pooagg Tm9ibyBBa2l5YSAobm9ibykNCuWPkemAgeaXtumXtDogMjAxNOW5tDfmnIgxMeaXpSAzOjAwDQrm lLbku7bkuro6IFNhbSBBbGRyaW47IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVl ZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0K5oqE6YCBOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5n LW9hbS11c2VjYXNlDQrkuLvpopg6IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnMNCg0KSGkgU2FtLA0K DQpKdXN0IHRvIHBvaW50IG91dCBvbmUgdGhpbmcgYWJvdXQgdGhpcyBkb2N1bWVudCDigKYNCg0K VGhlIHRlc3QgcGFja2V0IGdlbmVyYXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1kZXZp Y2UgY2FuIGhhdmUgdGhlIGNvbXBsZXRlIHNlZ21lbnQgc3RhY2sgb24gaG93IHRvIHRyYXZlcnNl IHRoZSBuZXR3b3JrIGFzIHdlbGwgYXMgaG93IHRvIGNvbWUgYmFjayB0byBzZWxmIHdpdGhvdXQg YW55IGZ1cnRoZXIgc2lnbmFsaW5nLCBPQU0gc3RhdGUgbWFpbnRlbmFuY2Ugb24gbmV0d29yayBu b2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuDQoNClRoYXQgbWFrZXMg dGhpcyBhcHByb2FjaCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB1c2luZyBwcm94eSBMU1AgcGluZy4N Cg0KVGhpcyBjZXJ0YWlubHkgaGFzIHNvbWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRl IHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9BTXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0 aGUgbmV0d29yay4NCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NClNlbnQ6IFRo dXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE0NClRvOiBSdWVkaWdlci5HZWliQHRlbGVrb20u ZGU8bWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4NCkNjOiBzcHJpbmc7IGRyYWZ0LWdl aWItc3ByaW5nLW9hbS11c2VjYXNlDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQoN CkhpIFJ1ZWRpZ2VyLA0KDQpUaGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZp bmQgbXkgcmVzcG9uc2VzIGlubGluZS4NCg0KT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBB TSwgPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29t LmRlPj4gd3JvdGU6DQpIaSBTYW0sDQoNCm15IHJlcGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBh ZGRlZCB0byB5b3VyIHRleHQuDQoNCi0gUHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3aGls ZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBpcyBpbnRlbmRlZCBmb3IgZXZlcnkgU1IgZGF0YSBwbGFu ZSAoTVBMUyArIElQdjYpLiBXZSdsbCBjbGFyaWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Lg0KLSBQcm94 eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdo aWxlIG91ciB1c2UgY2FzZSBjYW4gdXNlIGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmlj IGdvb2QgdXNlcyBmb3IgQkZELCBhbmQgSUNNUHY2KQ0KDQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBh IHNvbHV0aW9uIHdpdGggYnJvYWRlciBzY29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFz IGEgd2hvbGUuDQolc2FtIC0gSSBiZWxpZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1l bnQgYmVsb3cuIFRoZW4gc29sdXRpb24gaXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9m IHRpbWUsIGFzIHdlIGhhdmVuJ3QgZGVsaWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBlaXRo ZXIuDQoNCkFzIHlvdSB3cml0ZSwgU1IgYmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxh ciBmdW5jdGlvbnMgYXMgcHJveHktbHNwLiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25h bCBtZXNzYWdlcyBhbmQgTEVSL0xTUiBwcm9jZXNzaW5nIGludHJvZHVjZWQgYnkgcHJveHktbHNw Lg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQoNCiAgICAgIFNhbSBBbGRyaW4gd3JvdGU6DQoN CiAgICAgIEkgaGF2ZSBmZXcgcXVlc3Rpb25zIGFib3V0IHRoaXMgZHJhZnQuDQoNCiAgICAgIDEu IFRoZSB0aXRsZSBpcyBjb25mdXNpbmcgdG8gbWUuIEl0IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBp biBzZWN0aW9uICMxDQogICAgICBpdCBzYXlzIHRoZSBmb2xsb3dpbmcNCg0KICAgICAgPHNuaXA+ DQogICAgICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2Js ZW0gc3RhdGVtZW50IGFuZA0KICAgICAgIGlsbHVzdHJhdGVzIGl0IHdpdGggdXNlLWNhc2VzLg0K DQogICAgICAgVGhlIHNvbHV0aW9uIGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1QTFMg ZG9tYWluLg0KDQogICAgICAgVGhlIHNvbHV0aW9uIGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBM RFAgTFNQJ3MgYXMgd2VsbCBhcyB0bw0KICAgICAgIG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0 ZWQgTFNQJ3MuDQogICAgICA8ZW5kIHNuaXA+DQoNCiAgICAgICBJbiBmYWN0IHRoZSBkcmFmdCBp cyBkZXNjcmliaW5nIGEgc29sdXRpb24gdG8gY2VydGFpbiBzY2VuYXJpb3MgYW5kIG5vdCBqdXN0 DQogICAgICAgcHJvdmlkaW5nIHVzZSBjYXNlcy9zY2VuYXJpb3MuIE15IHVuZGVyc3RhbmRpbmcg d2FzLCB1c2UgY2FzZSBkcmFmdCBzaG91bGQNCiAgICAgICBkb2N1bWVudCBzY2VuYXJpb3Mgd2hl cmUgaXQgd2lsbCBkcml2ZSBuZXcgcmVxdWlyZW1lbnRzLiBTb2x1dGlvbnMgY291bGQNCiAgICAg ICBiZSBjb3ZlcmVkIHdpdGggZXhpc3RpbmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBkZXBl bmRpbmcgb24gdGhlIEdBUA0KICAgICAgIGFuYWx5c2lzLiBCdXQgdGhhdCBzaG91bGQgYmUgc2Vw YXJhdGUgYXMgdGhlcmUgY291bGQgYmUgbW9yZSB0aGFuIDEgc29sdXRpb24sDQogICAgICAgd2hl cmUgYXMgdGhpcyBkb2N1bWVudCBjb3VsZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNlcyBvbmx5Lg0K DQogICAgICAgSWYgaW5mYWN0IHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1 bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUgdGl0bGUNCiAgICAgICB3b3VsZCBiZSBtb3JlIG1lYW5p bmdmdWwuIFRoYXQncyBteSBvYnNlcnZhdGlvbi4NCltSR10gVGhhbmtzLiBJdCdzIGEgdXNlIGNh c2UgZG9jdW1lbnQuIFdlJ2xsIHJldmlldyB0aGUgdGV4dCBvZiBzZWN0aW9uIDEuDQolc2FtIC0g T0suIHRoZW4gSSdkIGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJl bW92ZWQsIHRoYXQgd2F5IHdlIGRvbnQgaGF2ZSB0byBkaXNjdXNzIHdoYXQgb3RoZXIgc29sdXRp b25zIGRvZXMgZWl0aGVyIG9yIGNvbXBhcmUgd2l0aCA6RA0KDQoNCiAgICAgICAyLiB3LnIudC4g U2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVkIHdpdGgN CiAgICAgICAiZHJhZnQtaWV0Zi1tcGxzLXByb3h5LWxzcC1waW5nLTAyIiAuIFdoYXQgaXMgYmVp bmcgZGVzY3JpYmVkIGluIHRoaXMNCiAgICAgICBzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0 aGUgcHJveHkgcGluZyhzb2x1dGlvbiB3aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZA0KICAgICAg IGJlIHNlbnQgdG8gbW9uaXRvciBMRVIgaSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4g SXMgbXkgdW5kZXJzdGFuZGluZw0KICAgICAgIHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZm ZXJlbnQgaGVyZT8NCltSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNo IHN0YXkgaW4gZGF0YSBwbGFuZSBhbmQgZXhlY3V0ZSBhIGRlc2lyZWQNCiAgICAgY2hhaW4gb2Yg TVBMUyBMU1BzLg0KJXNhbSAtIEV4ZWN1dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZvcm0g c29tZXRoaW5nIGVsc2U/DQoNCltSR10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBwcm90b2NvbCBleHRlbnNpb25zIHRvIE1QTFMgcGluZyBbUkZDNDM3OV0gdG8NCiAgIGFs bG93IGEgdGhpcmQgcGFydHkgdG8gcmVtb3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3Qg bWVzc2FnZSB0bw0KICAgYmUgc2VudCBkb3duIGEgTFNQIG9yIHBhcnQgb2YgYW4gTFNQLg0KJXNh bSAtIElmIGl0IGlzIHByb3Bvc2luZyBleHRlbnNpb25zLCAgaXQgaGFzIHRvIGJlIHNvbHV0aW9u IGRvY3VtZW50ICBhbmQgY2Fubm90IGNsYWltIHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNv IHRoaXMgZG9jdW1lbnQgaXMgb24gaW5mb3JtYXRpb24gdHJhY2suDQoNCltSR10gSSB0YWtlIGl0 IGFzIHNheWluZyB0aGF0IGlmIHlvdSdkIGxpa2UgdG8gcmVtb3RlbHkgZXhlY3V0ZSBSRkM0Mzc5 IGZ1bmN0aW9uYWxpdHkgb24gYW55IExTUCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBv ciBwcm94eS1waW5nLiBUaGUgUE1TIGhvd2V2ZXIgc2ltcGxpZmllcyBhbmQgYWRkcw0KZnVuY3Rp b25hbGl0eToNCmEpIFlvdSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVu Y3Rpb25hbGl0eSBsaWtlIHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YQ0KICAgcGxhbmUgbGl2ZWxp bmVzcywgUkZDNDM3OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGlt cGxlbWVudGF0aW9uLg0KJXNhbSAtIFJGQzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRh cGxhbmUgYW5kIGFsc28gZmluZCBvdXQgbG90IG1vcmUgZXJyb3JzLiBZb3UgbmVlZCBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBjaGVja3MuIEZvciBsaXZlbmVz cyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVmZXJyZWQgdG9vbCwgYXRsZWFzdCBpbiBwcmVzZW50IGRl cGxveW1lbnRzLlNvIGFyZSB5b3Ugc2F5aW5nLCBQTVMgc29sdXRpb24gaXMgZGVzaWduZWQgZm9y IGxpdmVuZXNzIGRldGVjdGlvbiBhbmQgbm90IHRvIHBlcmZvcm0gdmFsaWRhdGlvbiBvZiBkYXRh IHBsYW5lIHRvIGNvbnRyb2wgcGxhbmUsIGV0Yz8gKEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMg aW4gdGhlIGxhdGVyIHBhcnQgb2YgdGhlIGRvYyBhbHNvKQ0KDQpiKSBvbmNlIFBNUyBkZXRlY3Rl ZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9wb2xvZ3kg YnkgUkZDNDM3OSwNCiAgIGl0IGNhbiBjb250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1Ag Y29tYmluYXRpb25zIGFuZCB0aGUgbW9uaXRvcmluZyBwYWNrZXRzIHN0YXkNCiAgIGluIGRhdGEg cGxhbmUuIFBsZWFzZSBwb2ludCBtZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5n IHRoaXMgZmVhdHVyZS4NCiVzYW0gLSBUaGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91 dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rpb24geW91IGFyZSBkZXNjcmliaW5nIGlzLCBob3cgeW91 IHVzZSBsc3AgcGluZyByYXRoZXIgdGhhbiB3aGF0IGxzcCBwaW5nIGRvZXMuIEFnYWluIEkgYW0g bm90IHRhbGtpbmcgYWJvdXQgbm9uLW1wbHMgdG9wb2xvZ3kuDQpUbyBhbnN3ZXIgeW91ciBxdWVz dGlvbiwgaG93IHlvdSBwZXJmb3JtLg0KLSBQZXJmb3JtIHRyZWV0cmFjZSB3aXRoIHJmYzQzNzkg dG8gZ2V0IHRvcG9sb2d5IGluZm8NCi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2Nv dmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLg0KLSBwZXJmb3Jt IHBpbmcgd2l0aCByaWdodCBzZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBs aW1pdGluZyB0aGUgaG9wIFtMRVIgal0uDQotIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBM RVIgaSB0byBMRVIgaiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2UgcHJveHkgcGluZyB0byBzdGFydCBm cm9tIExFUiBpDQoNCiAgICAgICAgMy4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRv IFBNUyB3aGljaCBpcyBub3QgcGFydCBvZiBNUExTIG9yIHNlZ21lbnQNCiAgICAgICAgZG9tYWlu LCB0aGVyZSBpcyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byBjb25z aWRlcmVkLiBJIGJlbGlldmUNCiAgICAgICAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVz dCB0b28uIFdpbGwgeW91IGJlIGRvY3VtZW50aW5nIHRoYXQgYXNwZWN0Pw0KW1JHXSBUaGF0J3Mg YSB2YWxpZCBwb2ludC4gVGhlIGRvbWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbiBh bmQgdGhlIHRlYW0gd2lsbCBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5 IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJlIGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBh bmFseXNlIHRoaXMgaW4gZGVwdGggZm9yIGEgdXNlIGNhc2UgZG9jdW1lbnQuDQolc2FtIC0gbm9k DQoNCiAgICAgICAgNC4gU2VjIDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxk IHBlcmZvcm0gdGhhdCB3aXRoIFJGQzQzNzkgcGluZw0KICAgICAgICB3aXRoIG11bHRwYXRoICsg cHJveHkgcGluZy4gQ291bGQgeW91IGtpbmRseSBkaWZmZXJlbnRpYXRlIGlmIHRoZXJlIGlzIHNv bWV0aGluZw0KICAgICAgICBuZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KW1JHXSBUaGUg U1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBwcm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVu ZGxlZCBsaW5rIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBw cm94eS1sc3AuIEkgY291bGRuJ3QgZmluZCBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBkZXRlY3Qg YW5kIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gZHJhZnQtcHJveHktbHNwLiBQbGVhc2UgZGVz Y3JpYmUgaG93IHByb3h5LWxzcCBjYW4gYmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5r IChzb3JyeSBpZiB0aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJl IGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBPQU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS4N CiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmliZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBl YWNoIGJ1bmRsZWQgbGluayBtZW1iZXIgaXMgaWRlbnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVs LiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgdHJhY2Ugb3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVS IGkgd2lsbCByZXNwb25kIHdpdGggRERNQVAgaW5mbyBmb3IgZWFjaCBvZiB0aGUgbGlua3MgYW5k IHRoZSBtdWx0aXBhdGggaW5mbyBmb3IgdGhlIHNhbWUuDQpJZiB5b3Ugc2F5IHRoYXQgZWFjaCBs aW5rIG1lbWJlciBoYXMgc2FtZSBsYWJlbCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBz ZWxlY3RvcnMgYXMgZGVmaW5lZCBpbiBSRkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwg aG9zdCBkZXN0IGlwIGFkZHIsIHRvIGlkZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQpOb3cgaWYg dGhlIE1QTFMgZm9yd2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGlu dGVyZmFjZSBidXQgY2Fubm90IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291 bGQgb25seSB2YWxpZGF0ZSB0aGUgaW50ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVt YmVycy4NClNhbWUgYXBwbGllcyBpbiB5b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBp cyBkaWZmZXJlbnQuDQoNCg0KDQogICAgICAgICA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVu dCBoZXJlIG9ubHkgZm9yIFBNUyB0byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluIHRoZQ0KICAgICAg ICAgICAgY2FzZSBvZiBtaXhlZCBlbnY/DQpbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlz IHRoZSBwcmVjb25kaXRpb24gdG8gc2V0IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBzdGFja3MgZXhl Y3V0aW5nIGEgZGVzaXJlZCBjaGFpbiBvZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJlbC9GRUMvbm9k ZSByZWxhdGlvbiBpcyBrbm93biB0byB0aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQg ZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuDQolc2FtIC0gU28s IHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91IHN0aWxsIG5lZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRy YWNlIG9yIHRyZWV0cmFjZSB0byBnZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRl bnNpb25zIGJlaW5nIHByb3Bvc2VkIGluIFNQUklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90 aGVyIHRoYW4gbGFiZWwgc3RhY2suDQpBbmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90 IHVzZSBjYXNlKSBpcyB0aGF0LCBpdCBwZXJmb3JtcyBvbiBkZW1hbmQgcGVyIHNlZ21lbnQsIHdo aWNoIFByb3h5IHBpbmcgYWxzbyBkb2VzLCBhbGJlaXQgb25seSBmb3IgTVBMUyB0b3BvbG9neS4N ClRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGlzIHRoYXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hp c3RsZXMgb2YgUkZDNDM3OS4NCg0KUXVlc3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEg cGxhbmUgcGFja2V0cyBhcmUgZ2V0dGluZyBkcm9wcGVkIGFuZCBQTVMgcGFja2V0cyBnb2luZyB0 aHJvdWdoLCBmb3IgYSBnaXZlbiBMU1Agb3IgU2VnbWVudCwgaG93IGRvIHlvdSBrbm93IHRoZXJl IGlzIGEgcHJvYmxlbT8gaWYgeW91IGtub3csIGhvdyBkbyB5b3UgZmlndXJlIG91dCB3aGVyZSBp dCBpcz8NCkF0IGxlYXN0IHdpdGggUkZDNDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxk IHZhbGlkYXRlIGVhY2ggaG9wIGJlY2F1c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBj YXJyaWVzIGFsb25nIHdpdGggdGhlIHBhY2tldC4NCg0KDQoNCiAgICAgICAgIDYuIEluIHNlYyAz LjEsDQogICAgICAgICA8c25pcD4NCiAgICAgICAgIERldGVybWluaW5nIGEgcGF0aCB0byBiZSBl eGVjdXRlZCBwcmlvciB0byBhIG1lYXN1cmVtZW50IG1heSBhbHNvIGJlDQogICAgICAgICBkb25l IGJ5IHNldHRpbmcgdXAgYSBsYWJlbCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0 IHBhdGgNCiAgICAgICAgIChpZiBMRVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBh bmQgaXQgc2hvdWxkIGJlIHBhc3NlZA0KICAgICAgICAgYmV0d2VlbiBMRVIgaSBhbmQgTEVSIGos IHRoZSBsYWJlbCBzdGFjayBpcyAyMCAtIDQwIC0gMzAgLSAxMCkuICBUaGUNCiAgICAgICAgIGFk dmFudGFnZSBvZiB0aGlzIG1ldGhvZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMg T0FNDQogICAgICAgICBmdW5jdGlvbmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01Q IGZ1bmN0aW9uYWxpdGllcy4gIFRoZQ0KICAgICAgICAgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8g bW9uaXRvciBhbGwgbGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9mDQogICAgICAgICBh biBNUExTIGRvbWFpbi4gIElmIGNvcnJlY3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJlZCBw YXRocyBoYXMgdG8NCiAgICAgICAgIGJlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBz aG91bGQgYmUgYXBwbGllZCBhbHNvIGluIHRoaXMNCiAgICAgICAgIGNhc2UuDQoNCiAgICAgICAg IDxlbmQgc25pcD4NCg0KICAgICAgICAgSW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQg ZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksDQogICAgICAgICBS RkM0Mzc5IGZ1bmN0aW9uYWxpdHkgY291bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93 IGNvdWxkIHlvdSB2ZXJpZnkgYQ0KICAgICAgICAgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlz IG5vdCBkb25lLiBNb3JlIHRleHQgd2lsbCBoZWxwLiBBbHNvLCBtb3JlDQogICAgICAgICBpbXBv cnRhbnRseSwgdGhlIHRleHQgZWFybGllciB0byB0aGUgYWJvdmUgc2F5cywgZm9yIHZhbGlkIHJl c3VsdCwgTVBMUw0KICAgICAgICAgT0FNIGhhcyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5 IGNoYW5nZXMgZXRjLiBJZiBzbywgaXQgY29udHJhZGljdHMgaGVyZS4NCltSR10gVGhlIHRleHQg c2hvdWxkIHNheSB0aGF0DQotIHdpdGhvdXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4 ZWN1dGVzIGEgc2V0IG9mIHBhdGhzIG9ubHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1h dGlvbi4NCi0gaWYgdGhlIG9wZXJhdG9yIHdhbnRzIHRvIG1ha2Ugc3VyZSB0aGF0IGRhdGEgcGxh bmUgY29ycmVzcG9uZHMgdG8gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxk IGJlIGFwcGxpZWQuDQpJZiB5b3UgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQgdGhlIHRl eHQgaW4gdGhlIGRyYWZ0IHN0YXRlcyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byBy ZXdvcmQgaXQuDQolc2FtIC0gVGhlIHByb2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNl IG9mIE1QTFMsIGZvciBPQU0sIHlvdSBoYXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQpJIGRlZmlu aXRlbHkgc2VlIGEgc3BlY2lmaWMgbmVlZCBmb3IgU1BSSU5HLCBidXQgd2hhdCBJIGZlZWwgaXMs IHRoZSB1c2UgY2FzZSBpcyB0b28gbXVjaCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMgZW52aXNpb25l ZCBzb2x1dGlvbi4NCk9uY2UgeW91IHJlbW92ZSBzb2x1dGlvbiBvciBzdWdnZXN0ZWQgZW5oYW5j ZW1lbnRzLCBob3BlIGl0IHNob3VsZCBiZSBjbGVhciBvbiB3aGF0IGlzIGJlaW5nIHNvbHZlZCBh bmQgc2NvcGUgb3V0IGNsZWFyIHJlcXVpcmVtZW50cyBmb3IgYSBzb2x1dGlvbi4NCkZvciBzb2x1 dGlvbiBwYXJ0LCBwbGVhc2UgcHVibGlzaCBhIHNlcGFyYXRlIElELg0KDQoNCiAgICAgICAgIDcu IExhc3QgYnV0IG5vdCB0aGUgbGVhc3QsIGhvdyBkaWZmZXJlbnQgaXMgUE1TIGZyb20gRU1TIGFu ZCBOTVM/DQogICAgICAgICBTb21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3 aGF0IFBNUyBjb3VsZCBkbyBhbmQNCiAgICAgICAgIE5NUy9FTVMgY291bGRuJ3QuDQpbUkddIEkn dmUgbmV2ZXIgaGVhcmQgb2YgYW4gRU1TL05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJl IGFuZCB1c2VzIHRoaXMgdG9wb2xvZ3kgYXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBh Y2tldHMgZXhlY3V0aW5nIExTUCBjb21iaW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRv ci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVuIGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21w YW55IEkgd29yayBmb3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQolc2Ft IC0gVGhlcmUgYXJlIHRvb2xzIHdoaWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZv cm1zIE1QTFMgdG9wb2xvZ3kgc3BlY2lmaWMgb3BlcmF0aW9ucyAgZm9yIGEgZ2l2ZW4gc2V0IG9m IExTUCdzLiBUaGV5IHBlcmZvcm0gVHJlZXRyYWNlIGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0 aXBhdGguIEFsc28gcGVyZm9ybSBMU1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieSBjcmFmdGluZyBw YWNrZXRzIHdpdGggZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0aCBt dWx0aXBhdGguIFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUgbmVl ZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcgcHJvYmUgdGVjaG5vbG9neS4gV2lsbCBub3Qgc2F5IGJl eW9uZCB0aGF0IDpEDQoNCmNoZWVycw0KLXNhbQ0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA84582F10nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo 5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWls eTrlrovkvZM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5TYW0gQWxkcmluPGJyPg0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4xNDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDIzOjE4PGJyPg0KPC9zcGFuPjxiPuaU tuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IFFpbiBXdTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBOb2JvIEFraXlhIChub2JvKTsgc3ByaW5nOyBkcmFmdC1n ZWliLXNwcmluZy1vYW0tdXNlY2FzZTsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gSnVsIDE0LCAyMDE0 LCBhdCAyOjA3IEFNLCBRaW4gV3UgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5j b20iPmJpbGwud3VAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5WZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQgcm91dGluZyBkb2VzbuKAmXQg cmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBpbiB0aGUgcGF0aCB0byBtYWludGFpbiBzdGF0ZSBh bmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0ZQ0KIHdoaWxlPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByb3h5LWxzcC1waW5nIHJlcXVpcmUgZWFjaCBu ZXR3b3JrIG5vZGUgaW4gdGhlIHJldHVybiBwYXRoIHRvIG1haW50YWluIHRoZSBzdGF0ZS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldyb25nISZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5ObyBzdGF0ZSBpcyBtYWludGFpbmVkIGV4Y2VwdCBpbiB0aGUgaW5pdGlhdG9yLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTogSSBhbSBhIGxpdHRsZSBiaXQgY29u ZnVzZWQgd2hlbiB5b3Ugc2F5IG5vIHN0YXRlIGlzIG1haW50YWluZWQgaW4gb3RoZXIgbmV0d29y ayBub2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG9lcyBQ cm94eS1sc3AtcGluZyByZXF1aXJlIHRoZSBwYXRoIHRvIGJlIHNldHVwIGJlZm9yZSBpbml0aWF0 aW5nIHByb3h5IExTUCBwaW5nIG1lc3NhZ2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ib3cgZG9lcyB0aGUgaW5pdGlhdG9yIGtub3cgdGhlIHVwc3RyZWFtIG5l aWdoYm9yJ3MgdXBzdHJlYW0gbmVpZ2hib3I/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5TZWN0aW9uIDIgb2YmbmJzcDsgZHJhZnQtaWV0Zi1tcGxzLXByb3h5LWxz cC1waW5nLTAyIHNhaWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIGluaXRpYXRvciByZXF1ZXN0cyBQcm94eSBpbmZvcm1hdGlvbiBzbyB0 aGF0IGl0IGNhbiBsZWFybiBhZGRpdGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmluZm9ybWF0aW9uIGl0IG5lZWRzIHRv IHVzZSB0byBmb3JtIGEgc3Vic2VxdWVudCBNUExTIFByb3h5IFBpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVxdWVzdC48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvdyBk b2VzJm5ic3A7IHByb3h5IExTUCBoYXZlIHByb3h5IGluZm9ybWF0aW9uPyBEb2VzIGl0IHJlcXVp cmUgcGF0aCBzZXR1cCBpbiBhZHZhbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tc2FtPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldoeSBhcHBseSBQcm94eS1sc3AtcGluZyB0byBzcHJpbmcgT0FN Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+LVFpbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPnNwcmluZyBbPGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ihqDxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Ob2Jv DQogQWtpeWEgKG5vYm8pPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxzcGFuIGxhbmc9 IkVOLVVTIj4xMTwvc3Bhbj7ml6U8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ MzowMDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlNhbSBBbGRyaW47DQo8YSBo cmVmPSJtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlIj5SdWVkaWdlci5HZWliQHRlbGVr b20uZGU8L2E+PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+c3ByaW5nOyBkcmFmdC1n ZWliLXNwcmluZy1vYW0tdXNlY2FzZTxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlJl OiBbc3ByaW5nXSBRdWVzdGlvbnM8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgU2FtLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SnVzdCB0byBwb2ludCBvdXQgb25lIHRo aW5nIGFib3V0IHRoaXMgZG9jdW1lbnQg4oCmPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgdGVz dCBwYWNrZXQgZ2VuZXJhdGVkIGZyb20gYSBQTVMvTk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4g aGF2ZSB0aGUgY29tcGxldGUgc2VnbWVudCBzdGFjayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5l dHdvcmsgYXMgd2VsbCBhcyBob3cgdG8NCiBjb21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBm dXJ0aGVyIHNpZ25hbGluZywgT0FNIHN0YXRlIG1haW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMg bm9yIE9BTSBpbnZvbHZlbWVudCBieSBuZXR3b3JrIG5vZGVzLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhhdCBtYWtlcyB0aGlzIGFwcHJvYWNoIHF1aXRlIGRpZmZlcmVudCBmcm9tIHVzaW5nIHBy b3h5IExTUCBwaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBjZXJ0YWlubHkgaGFzIHNv bWUgcHJvcyBhbmQgY29ucyBidXQgY2FuIGJlIHF1aXRlIHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9B TXMgKHllcyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1Ob2JvPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zcHJpbmcNCiBbPGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5TYW0gQWxk cmluPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE08YnI+DQo8Yj5Ubzo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20uZGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvc3Bhbj48L2E+PGJyPg0KPGI+Q2M6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5zcHJpbmc7 IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc3ByaW5nXSBR dWVzdGlvbnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhp IFJ1ZWRpZ2VyLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5U aGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZS4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2VzIGlu bGluZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5PbiBUaHUsIEp1bCAxMCwgMjAxNCBhdCA3OjE1IEFNLCAmbHQ7PGEgaHJlZj0ibWFp bHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvc3Bhbj48L2E+Jmd0OyB3 cm90ZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5IaSBTYW0sPGJyPg0KPGJyPg0KbXkgcmVwbGllcyBhcmUgbWFya2VkIFtS R10gYW5kIGFkZGVkIHRvIHlvdXIgdGV4dC48YnI+DQo8YnI+DQotIFByb3h5LWxzcC1waW5nIGlz IE1QTFMgb25seSwgd2hpbGUgdGhlIFBNUyBhcmNoaXRlY3R1cmUgaXMgaW50ZW5kZWQgZm9yIGV2 ZXJ5IFNSIGRhdGEgcGxhbmUgKE1QTFMgJiM0MzsgSVB2NikuIFdlJ2xsIGNsYXJpZnkgdGhhdCBp biB0aGUgZHJhZnQuPGJyPg0KLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBMU1AgUGluZyAo UkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2UgY2FzZSBjYW4gdXNlIGFueSBPQU0g KGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBmb3IgQkZELCBhbmQgSUNNUHY2KTxi cj4NCjxicj4NCkJhc2VkIG9uIHRoYXQsIGl0wrlzIGEgc29sdXRpb24gd2l0aCBicm9hZGVyIHNj b3BlIGFuZCBiZXR0ZXIgZml0IGZvciBTUFJJTkcgYXMgYSB3aG9sZS4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+JXNhbSAtIEkgYmVsaWV2ZSB5b3Ugc2F5IGl0IGlzIHVzZSBjYXNlIGRvY3VtZW50IGJl bG93LiBUaGVuIHNvbHV0aW9uIGlzIHRvbyBwcmVtYXR1cmUgYXQgdGhpcyBwb2ludCBvZiB0aW1l LCBhcyB3ZSBoYXZlbid0IGRlbGliZXJhdGVkIG9uIHRoZSByZXF1aXJlbWVudHMgZWl0aGVyLiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48YnI+DQpBcyB5b3Ugd3JpdGUsIFNSIGJhc2VkIE9BTSBwYXJ0aWFsbHkg b2ZmZXJzIHNpbWlsYXIgZnVuY3Rpb25zIGFzIHByb3h5LWxzcC4gV2l0aG91dCByZXF1aXJpbmcg dGhlIGFkZGl0aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9MU1IgcHJvY2Vzc2luZyBpbnRyb2R1Y2Vk IGJ5IHByb3h5LWxzcC4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NClJlZ2FyZHMsPGJyPg0K PGJyPg0KUnVlZGlnZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNhbSBBbGRyaW4gd3JvdGU6PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBoYXZlIGZldyBxdWVzdGlvbnMgYWJvdXQgdGhpcyBkcmFm dC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBUaGUgdGl0bGUgaXMgY29uZnVz aW5nIHRvIG1lLiBJdCBzYXlzIE9BTSB1c2UgY2FzZSBidXQgaW4gc2VjdGlvbiAjMTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGl0IHNheXMgdGhlIGZvbGxvd2luZzxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDtzbmlwJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIHN0 YXRlbWVudCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbGx1c3RyYXRlcyBp dCB3aXRoIHVzZS1jYXNlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGUgc29sdXRpb24gaXMgZGVzY3JpYmVkIGZvciBhIHNpbmdsZSBJR1AgTVBMUyBkb21haW4uPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNvbHV0aW9uIGFwcGxpZXMg dG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bzxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO21vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2VuZCBzbmlwJmd0Ozxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0luIGZhY3QgdGhlIGRyYWZ0IGlzIGRlc2NyaWJpbmcgYSBzb2x1 dGlvbiB0byBjZXJ0YWluIHNjZW5hcmlvcyBhbmQgbm90IGp1c3Q8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtwcm92aWRpbmcgdXNlIGNhc2VzL3NjZW5hcmlvcy4gTXkgdW5kZXJzdGFu ZGluZyB3YXMsIHVzZSBjYXNlIGRyYWZ0IHNob3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RvY3VtZW50IHNjZW5hcmlvcyB3aGVyZSBpdCB3aWxsIGRyaXZlIG5ldyByZXF1aXJl bWVudHMuIFNvbHV0aW9ucyBjb3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jl IGNvdmVyZWQgd2l0aCBleGlzdGluZyB0b29sc2V0IG9yIGRlZmluZWQgbmV3bHksIGRlcGVuZGlu ZyBvbiB0aGUgR0FQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5hbHlzaXMuIEJ1 dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0ZSBhcyB0aGVyZSBjb3VsZCBiZSBtb3JlIHRoYW4gMSBz b2x1dGlvbiw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZSBhcyB0aGlzIGRv Y3VtZW50IGNvdWxkIGp1c3QgZm9jdXMgb24gdXNlIGNhc2VzIG9ubHkuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgaW5mYWN0IHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUg YSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUgdGl0bGU8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBteSBv YnNlcnZhdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5bUkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50 LiBXZSdsbCByZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4lc2FtIC0gT0suIHRoZW4gSSdkIGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBz b2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIHRoYXQgd2F5IHdlIGRvbnQgaGF2ZSB0byBkaXNjdXNz IHdoYXQgb3RoZXIgc29sdXRpb25zIGRvZXMgZWl0aGVyIG9yIGNvbXBhcmUgd2l0aCA6RDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIHcuci50LiBTZWN0aW9u IG51bWJlciAjMiwgdGhlIHNhbWUgcHJvYmxlbSBpcyBiZWluZyBzb2x2ZWQgd2l0aDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2RyYWZ0LWlldGYtbXBscy1wcm94eS1sc3At cGluZy0wMiZxdW90OyAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGluIHRoaXM8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWN0aW9uIGNvdWxkIGJlIGRvbmUgd2l0aCB0aGUgcHJv eHkgcGluZyhzb2x1dGlvbiB3aXNlKSB3aGVyZSwgcmVxdWVzdCBjb3VsZDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2JlIHNlbnQgdG8gbW9uaXRvciBMRVIgaSBhbmQgTEVSIGogc2Vn bWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgdW5kZXJzdGFuZGluZzxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3JpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBkaWZmZXJlbnQgaGVyZT88L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5bUkddIFRoZSBQTVMgaXMgYWJsZSB0byBzZXQgdXAgcGFja2V0cyB3aGljaCBzdGF5IGlu IGRhdGEgcGxhbmUgYW5kIGV4ZWN1dGUgYSBkZXNpcmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDtjaGFpbiBvZiBNUExTIExTUHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiVzYW0g LSBFeGVjdXRlIHlvdSBtZWFuIHRyYXZlcnNlPyBvciBwZXJmb3JtIHNvbWV0aGluZyBlbHNlPyZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48YnI+DQpbUkddIFByb3h5LWxzcCBzYXlzOiBUaGlzIGRvY3VtZW50IGRl ZmluZXMgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBNUExTIHBpbmcgW1JGQzQzNzldIHRvPGJyPg0K Jm5ic3A7ICZuYnNwO2FsbG93IGEgdGhpcmQgcGFydHkgdG8gcmVtb3RlbHkgY2F1c2UgYW4gTVBM UyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bzxicj4NCiZuYnNwOyAmbmJzcDtiZSBzZW50IGRvd24g YSBMU1Agb3IgcGFydCBvZiBhbiBMU1AuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiVz YW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9ucywgJm5ic3A7aXQgaGFzIHRvIGJlIHNv bHV0aW9uIGRvY3VtZW50ICZuYnNwO2FuZCBjYW5ub3QgY2xhaW0gdG8gYmUgdXNlIGNhc2UgZG9j dW1lbnQuIEFsc28gdGhpcyBkb2N1bWVudCBpcyBvbiBpbmZvcm1hdGlvbiB0cmFjay48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PGJyPg0KW1JHXSBJIHRha2UgaXQgYXMgc2F5aW5nIHRoYXQgaWYgeW91J2QgbGlrZSB0byBy ZW1vdGVseSBleGVjdXRlIFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBvbiBhbnkgTFNQLCB5b3UgY291 bGQgZWl0aGVyIHVzZSB0aGUgUE1TIG9yIHByb3h5LXBpbmcuIFRoZSBQTVMgaG93ZXZlciBzaW1w bGlmaWVzIGFuZCBhZGRzPGJyPg0KZnVuY3Rpb25hbGl0eTo8YnI+DQphKSBZb3UgZG9uJ3QgbmVl ZCBhbiBhZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlrZSBwcm94eS1waW5n IHRvIGNoZWNrIGRhdGE8YnI+DQombmJzcDsgJm5ic3A7cGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3 OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TIGltcGxlbWVudGF0aW9u Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4lc2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2 YWxpZGF0aW9uIG9mIGRhdGFwbGFuZSBhbmQgYWxzbyBmaW5kIG91dCBsb3QgbW9yZSBlcnJvcnMu IFlvdSBuZWVkIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNo ZWNrcy4gRm9yIGxpdmVuZXNzIGRldGVjdGlvbiwgQkZEDQogaXMgcHJlZmVycmVkIHRvb2wsIGF0 bGVhc3QgaW4gcHJlc2VudCBkZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1TIHNvbHV0 aW9uIGlzIGRlc2lnbmVkIGZvciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5vdCB0byBwZXJmb3Jt IHZhbGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBldGM/IChJIHRoaW5r IHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxzbyk8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Yikgb25jZSBQTVMgZGV0ZWN0ZWQg ZGF0YSBwbGFuZSBsaXZlbGluZXNzIGFuZCBjb3JyZWN0bmVzcyBvZiBNUExTIHRvcG9sb2d5IGJ5 IFJGQzQzNzksPGJyPg0KJm5ic3A7ICZuYnNwO2l0IGNhbiBjb250aW51ZSB0byBleGVjdXRlIGFy Yml0cmFyeSBMU1AgY29tYmluYXRpb25zIGFuZCB0aGUgbW9uaXRvcmluZyBwYWNrZXRzIHN0YXk8 YnI+DQombmJzcDsgJm5ic3A7aW4gZGF0YSBwbGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0 ZXh0IGluIHByb3h5LXBpbmcgb2ZmZXJpbmcgdGhpcyBmZWF0dXJlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4lc2FtIC0gVGhpcyB5b3UgY291bGQgcGVyZm9ybSBldmVuIHdpdGhvdXQg cHJveHkgcGluZy4gVGhlIGZ1bmN0aW9uIHlvdSBhcmUgZGVzY3JpYmluZyBpcywgaG93IHlvdSB1 c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBsc3AgcGluZyBkb2VzLiBBZ2FpbiBJIGFtIG5v dCB0YWxraW5nIGFib3V0DQogbm9uLW1wbHMgdG9wb2xvZ3kuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4tIFBlcmZvcm0gdHJlZXRyYWNlIHdpdGggcmZjNDM3OSB0byBnZXQgdG9wb2xv Z3kgaW5mbzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0gcGljayBhbnkgYXJiaXRhcnkgTFNQIHBh dGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlwYXRoIGltcGxlbWVudGF0aW9uLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0gcGVyZm9ybSBwaW5nIHdpdGggcmlnaHQgc2VsZWN0b3Jz IGZvciB0aGUgcGF0aCBhbmQgdXNlIFRUTCBmb3IgbGltaXRpbmcgdGhlIGhvcCBbTEVSIGpdLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0gaWYgeW91IHdhbnQgdG8gcGVyZm9ybSBmcm9tIExFUiBp IHRvIExFUiBqIGFzIGluIHlvdXIgZHJhZnQsIHVzZSBwcm94eSBwaW5nIHRvIHN0YXJ0IGZyb20g TEVSIGk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMy4gV2hlbiB0aGUgcmVzcG9uc2UgaXMgc2VudCBiYWNrIHRv IFBNUyB3aGljaCBpcyBub3QgcGFydCBvZiBNUExTIG9yIHNlZ21lbnQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZG9tYWluLCB0aGVyZSBpcyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNw ZWN0LCB3aGljaCBuZWVkcyB0byBjb25zaWRlcmVkLiBJIGJlbGlldmU8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdp bGwgeW91IGJlIGRvY3VtZW50aW5nIHRoYXQgYXNwZWN0Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPltSR10gVGhhdCdzIGEg dmFsaWQgcG9pbnQuIFRoZSBkb21haW4gZXh0ZXJuYWwgc3lzdGVtIGlzIG9uZSBvcHRpb24gYW5k IHRoZSB0ZWFtIHdpbGwgZGVhbCB3aXRoIHRoZSBzZWN1cml0eSBhc3BlY3RzIHJhaXNlZCBieSB0 aGlzIG9wdGlvbiBvbmNlIHdlIGFyZSBpbiBzb2x1dGlvbiBzcGFjZS4gV2UNCiB3aWxsIG5vdCBh bmFseXNlIHRoaXMgaW4gZGVwdGggZm9yIGEgdXNlIGNhc2UgZG9jdW1lbnQuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiVzYW0gLSBub2QmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNC4gU2Vj IDMuMiB0byBtb25pdG9yIGJ1bmRsZSBsaW5rcywgb25lIGNvdWxkIHBlcmZvcm0gdGhhdCB3aXRo IFJGQzQzNzkgcGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIG11bHRw YXRoICYjNDM7IHByb3h5IHBpbmcuIENvdWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0 aGVyZSBpcyBzb21ldGhpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV3IHRo ZSBzb2x1dGlvbiBicmluZ3MgaGVyZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5bUkddIFRoZSBTUiBPQU0gYXV0aG9yIHRl YW0gaGFzIHByb3ZpZGVkIHRleHQgaG93IHRvIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gdGhl IHVzZSBjYXNlIGRyYWZ0LiBZb3UgYXJlIGEgY28tYXV0aG9yIG9mIHByb3h5LWxzcC4gSSBjb3Vs ZG4ndCBmaW5kIGV4cGxpY2l0IHRleHQgb24gaG93IHRvDQogZGV0ZWN0IGFuZCBtb25pdG9yIGEg YnVuZGxlZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhvdyBwcm94 eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkgaWYgdGhp cyBpcyBvYnZpb3VzIGFuZCBJIG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyB0 byB0aGUgU1IgT0FNIGFwcHJvYWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmliZWQgYWJvdmUgY291 bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIgaXMgaWRlbnRpZmllZCB3aXRo IGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgdHJhY2Ugb3IgcGluZyB3aXRo IG11bHRpcGF0aCwgTEVSDQogaSB3aWxsIHJlc3BvbmQgd2l0aCBERE1BUCBpbmZvIGZvciBlYWNo IG9mIHRoZSBsaW5rcyBhbmQgdGhlIG11bHRpcGF0aCBpbmZvIGZvciB0aGUgc2FtZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5JZiB5b3Ugc2F5IHRoYXQgZWFjaCBsaW5rIG1lbWJlciBoYXMgc2Ft ZSBsYWJlbCBzdGFjaywgdGhlbiB5b3UgY291bGQgdXNlIGxzcCBzZWxlY3RvcnMgYXMgZGVmaW5l ZCBpbiBSRkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdCBkZXN0IGlwIGFkZHIs IHRvIGlkZW50aWZ5IGVhY2gNCiBsaW5rIG1lbWJlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5O b3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMg b25lIGludGVyZmFjZSBidXQgY2Fubm90IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5 b3UgY291bGQgb25seSB2YWxpZGF0ZSB0aGUgaW50ZXJmYWNlIGFuZCBub3QgaXRzIGluZGl2aWR1 YWwNCiBtZW1iZXJzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNhbWUgYXBwbGllcyBpbiB5b3Vy IGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzUuIHNlYyAjNSwgSXMg dGhlIHJlcXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRoZSB0b3BvbG9neSwg aW4gdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2Fz ZSBvZiBtaXhlZCBlbnY/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+W1JHXSBNUExTIHRvcG9sb2d5IGF3YXJlbmVzcyBpcyB0 aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1cCBwYWNrZXRzIHdpdGggbGFiZWwgc3RhY2tzIGV4ZWN1 dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQcy4gSWYgc3VpdGFibGUgTGFiZWwvRkVDL25vZGUg cmVsYXRpb24gaXMga25vd24gdG8gdGhlDQogUE1TLCB0aGF0IExTUCBjYW4gYmUgZXhlY3V0ZWQg ZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiVzYW0gLSBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCB5b3Ugc3Rp bGwgbmVlZCB0byBwZXJmb3JtIFJGQzQzNzkgdHJhY2Ugb3IgdHJlZXRyYWNlIHRvIGdldCB0b3Bv bG9neS4gSSBkbyBub3QgdGhpbmsgSUdQIGV4dGVuc2lvbnMgYmVpbmcgcHJvcG9zZWQgaW4gU1BS SU5HIGV4cG9ydCBhbnkgb2YgdGhlDQogaW5mbyBvdGhlciB0aGFuIGxhYmVsIHN0YWNrLiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFuZCB0aGUgcHJvcG9zZWQgUE1TIHNvbHV0aW9uIChu b3QgdXNlIGNhc2UpIGlzIHRoYXQsIGl0IHBlcmZvcm1zIG9uIGRlbWFuZCBwZXIgc2VnbWVudCwg d2hpY2ggUHJveHkgcGluZyBhbHNvIGRvZXMsIGFsYmVpdCBvbmx5IGZvciBNUExTIHRvcG9sb2d5 Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGlzIHRoYXQg bm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5RdWVzdGlvbiBJIGhhdmUgZm9y IHlvdSBpcywgaWYgZGF0YSBwbGFuZSBwYWNrZXRzIGFyZSBnZXR0aW5nIGRyb3BwZWQgYW5kIFBN UyBwYWNrZXRzIGdvaW5nIHRocm91Z2gsIGZvciBhIGdpdmVuIExTUCBvciBTZWdtZW50LCBob3cg ZG8geW91IGtub3cgdGhlcmUgaXMgYSBwcm9ibGVtPyBpZiB5b3UNCiBrbm93LCBob3cgZG8geW91 IGZpZ3VyZSBvdXQgd2hlcmUgaXQgaXM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXQgbGVhc3Qg d2l0aCBSRkM0Mzc5IGFuZC9vciBwcm94eSBwaW5nLCB5b3UgY291bGQgdmFsaWRhdGUgZWFjaCBo b3AgYmVjYXVzZSBvZiB0aGUgYmVsbHMgYW5kIHdoaXN0bGVzIGl0IGNhcnJpZXMgYWxvbmcgd2l0 aCB0aGUgcGFja2V0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs2LiBJbiBzZWMgMy4xLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7c25pcCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7RGV0ZXJtaW5pbmcgYSBwYXRoIHRvIGJlIGV4ZWN1dGVkIHByaW9yIHRvIGEgbWVhc3Vy ZW1lbnQgbWF5IGFsc28gYmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZG9uZSBieSBzZXR0aW5nIHVwIGEgbGFiZWwgaW5jbHVkaW5nIGFsbCBub2RlIFNJRHMgYWxvbmcg dGhhdCBwYXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhpZiBMRVIx IGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxkIGJlIHBhc3NlZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZXR3ZWVuIExFUiBpIGFuZCBM RVIgaiwgdGhlIGxhYmVsIHN0YWNrIGlzIDIwIC0gNDAgLSAzMCAtIDEwKS4gJm5ic3A7VGhlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FkdmFudGFnZSBvZiB0aGlzIG1l dGhvZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Z1bmN0aW9uYWxpdHkgYW5kIGl0IGlzIGluZGVwZW5k ZW50IG9mIEVDTVAgZnVuY3Rpb25hbGl0aWVzLiAmbmJzcDtUaGU8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBhbGwg bGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2FuIE1QTFMgZG9tYWluLiAmbmJzcDtJZiBjb3JyZWN0IGZvcndhcmRp bmcgYWxvbmcgdGhlIGRlc2lyZWQgcGF0aHMgaGFzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2JlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQg YmUgYXBwbGllZCBhbHNvIGluIHRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Y2FzZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmx0O2VuZCBzbmlwJmd0Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtJbiB0aGUgYWJvdmUgeW91IG1lbnRpb24gdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1Q TFMgT0FNLiBCdXQgbGF0ZXIgeW91IHNheSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7UkZDNDM3OSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlIHVzZWQuIENvdWxkIHlvdSBj bGFyaWZ5IGhvdyBjb3VsZCB5b3UgdmVyaWZ5IGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBNb3JlIHRl eHQgd2lsbCBoZWxwLiBBbHNvLCBtb3JlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2ltcG9ydGFudGx5LCB0aGUgdGV4dCBlYXJsaWVyIHRvIHRoZSBhYm92ZSBzYXlzLCBm b3IgdmFsaWQgcmVzdWx0LCBNUExTPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO09BTSBoYXMgdG8gYmUgcGVyZm9ybWVkIGZvciB0b3BvbG9neSBjaGFuZ2VzIGV0Yy4gSWYg c28sIGl0IGNvbnRyYWRpY3RzIGhlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+W1JHXSBUaGUgdGV4dCBzaG91bGQgc2F5 IHRoYXQ8YnI+DQotIHdpdGhvdXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVz IGEgc2V0IG9mIHBhdGhzIG9ubHkgYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi48 YnI+DQotIGlmIHRoZSBvcGVyYXRvciB3YW50cyB0byBtYWtlIHN1cmUgdGhhdCBkYXRhIHBsYW5l IGNvcnJlc3BvbmRzIHRvIGNvbnRyb2wgcGxhbmUsIFJGQzQ3MzkgZnVuY3Rpb25zIHNob3VsZCBi ZSBhcHBsaWVkLjxicj4NCklmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUg dGV4dCBpbiB0aGUgZHJhZnQgc3RhdGVzIHNvbWV0aGluZyBkaWZmZXJlbnQsIEknbGwgdHJ5IHRv IHJld29yZCBpdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+JXNhbSAtIFRoZSBwcm9i bGVtIEkgYW0gaGF2aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FNLCB5b3UgaGF2 ZSB0byB2YWxpZGF0ZSB0aGUgbHNwLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgZGVmaW5pdGVs eSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVlbCBpcywgdGhl IHVzZSBjYXNlIGlzIHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZpc2lvbmVkIHNv bHV0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9uY2UgeW91IHJlbW92ZSBzb2x1dGlvbiBv ciBzdWdnZXN0ZWQgZW5oYW5jZW1lbnRzLCBob3BlIGl0IHNob3VsZCBiZSBjbGVhciBvbiB3aGF0 IGlzIGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJlcXVpcmVtZW50cyBmb3IgYSBz b2x1dGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3Igc29sdXRpb24gcGFydCwgcGxlYXNl IHB1Ymxpc2ggYSBzZXBhcmF0ZSBJRC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Ny4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZlcmVu dCBpcyBQTVMgZnJvbSBFTVMgYW5kIE5NUz88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7U29tZWhvdyBJIGNvdWxkbid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ugd2hhdCBQTVMg Y291bGQgZG8gYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05NUy9F TVMgY291bGRuJ3QuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+W1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9OTVMg d2hpY2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJl bmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmluYXRp b25zIGFzIGRlc2lyZWQgYnkgYW4NCiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVuIGNv bW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29yayBmb3Igd291bGRuJ3QgaGF2 ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiVz YW0gLSBUaGVyZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hpY2ggcGVy Zm9ybXMgTVBMUyB0b3BvbG9neSBzcGVjaWZpYyBvcGVyYXRpb25zICZuYnNwO2ZvciBhIGdpdmVu IHNldCBvZiBMU1Ancy4gVGhleSBwZXJmb3JtIFRyZWV0cmFjZSBhbmQgcGVyZm9ybSBwaW5nIHdp dGgNCiBtdWx0aXBhdGguIEFsc28gcGVyZm9ybSBMU1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieSBj cmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJhY2UgYW5kIHBp bmcgd2l0aCBtdWx0aXBhdGguIFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91 dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcgcHJvYmUgdGVjaG5vbG9neS4gV2lsbCBu b3Qgc2F5IGJleW9uZCB0aGF0IDpEPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Y2hlZXJzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LXNhbTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA84582F10nkgeml501mbschi_-- From nobody Mon Jul 14 20:10:51 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EA21B27CB for ; Mon, 14 Jul 2014 20:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFQlDH_QvPfa for ; Mon, 14 Jul 2014 20:10:42 -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 3E5751B27C9 for ; Mon, 14 Jul 2014 20:10:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKA84542; Tue, 15 Jul 2014 03:10:39 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 04:10:38 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 11:10:34 +0800 From: Qin Wu To: "Nobo Akiya (nobo)" , Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7JhndME/roR0Kh13/N0Tpo0QAT5ZsQAA/kkXD//77CAIAADOQA//naTZCADASwAP/+iK+g Date: Tue, 15 Jul 2014 03:10:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84582F37nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/vBeHM_5dApCEcxHThiCkP-JaodU Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 03:10:47 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84582F37nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIE5vYm86DQpJIGFncmVlIHRoZSBhc3BlY3RzIHRoYXQgYXJlIG1pc3NpbmcgaW4gZHJhZnQt Z2VpYi1zcHJpbmctb2FtLXVzZWNhc2UuDQoNClNwcmluZyBwcm9ibGVtIHN0YXRlbWVudCBzYXlz IHRoZSBTUFJJTkcgYXJjaGl0ZWN0dXJlIHdpbGwgYWRkcmVzcyB1c2UgY2FzZXMgd2hlcmUgcmVt b3ZhbCBvZiBzaWduYWxpbmcgYW5kIHBhdGggc3RhdGUgaW4NCiAgIHRoZSBjb3JlIGlzIGEgcmVx dWlyZW1lbnQuDQoNCk5vdyB5b3Ugc2FpZCBlYWNoIG5ldHdvcmsgbm9kZSBzdGlsbCBoYXMgc3Rh dGVzIHJlbGF0ZWQgdG8gdmFyaW91cyBzZWdtZW50IHR5cGVzLg0KQXJlIHlvdSBzYXlpbmcgTm9u LVNSIG5vZGUgaW4gdGhlIFNSIGRvbWFpbiBzaG91bGQgbm90IG1haW50YWluIGFueSBwYXRoIHN0 YXRlIG9yIHNlZ21lbnQgcm91dGluZyByZWxhdGVkIHN0YXRlIGJ1dCBTUiBlbmFibGVkIG5vZGUN CkluIHRoZSBTUiBkb21haW4gTVVTVCBoYXZlIHNlZ21lbnQgcm91dGluZyByZWxhdGVkIHN0YXRl PyBMZXQgbWUga25vdyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQoNClJlZ2FyZHMh DQotUWluDQrlj5Hku7bkuro6IE5vYm8gQWtpeWEgKG5vYm8pIFttYWlsdG86bm9ib0BjaXNjby5j b21dDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQ35pyIMTTml6UgMjA6MzkNCuaUtuS7tuS6ujogUWlu IFd1OyBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUNCuaKhOmAgTogc3ByaW5n OyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0K5Li76aKYOiBSRTogW3NwcmluZ10gUXVl c3Rpb25zDQoNCkhpIFFpbiwgZXQgYWwsDQoNCkVhY2ggbmV0d29yayBub2RlIHdpbGwgc3RpbGwg aGF2ZSBzb21lIHN0YXRlcyAoaS5lLiBub2RlL2FkamFjZW5jeS9zZXJ2aWNlIHNlZ21lbnRzKS4N Cg0KSSBzZWUgdGhlIHRlY2huaXF1ZSBkZXNjcmliZWQgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVz ZWNhc2UgYXMgYSB3YXkgdG8gbW9uaXRvciB0aGUgbmV0d29yaywgYnV0IG5vdCBhIHdheSB0byB2 YWxpZGF0ZSB0aGUgc2VnbWVudHMuIEluIHBhcnRpY3VsYXIgdGhlIGZvbGxvd2luZyBhc3BlY3Rz IGNhbm5vdCBiZSB2YWxpZGF0ZWQgYnkgdGhlIHRlY2huaXF1ZSBkZXNjcmliZWQgZHJhZnQtZ2Vp Yi1zcHJpbmctb2FtLXVzZWNhc2UuDQoNCg0KMS4gICAgICAgVXNpbmcgYSBzZWdtZW50IG9yIGNv bWJpbmF0aW9uIG9mIHNlZ21lbnRzIHJlc3VsdCBpbiBhIHBhY2tldCB0byByZWFjaCBhbiBleHBl Y3RlZCBuZXR3b3JrIG5vZGUuDQoNCjIuICAgICAgIFVzaW5nIGFuIGFkamFjZW5jeSBzZWdtZW50 IHJlc3VsdHMgaW4gYSBwYWNrZXQgdG8gdHJhdmVyc2Ugb3ZlciBhbiBleHBlY3RlZCBhZGphY2Vu Y3kuDQoNCjMuICAgICAgIFVzaW5nIGEgc2VydmljZSBzZWdtZW50IHJlc3VsdHMgaW4gYSBwYWNr ZXQgdG8gaGl0IGFuIGV4cGVjdGVkIHNlcnZpY2UuDQoNClRoaXMgaXMgd2h5IEkgcHJldmlvdXNs eSBtZW50aW9uZWQgdGhhdCB0aGUgdGVjaG5pcXVlIGlzIHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9B TXMgdXNlZCB0byBtb25pdG9yIHRoZSBuZXR3b3JrLg0KDQpJbiBvdGhlciB3b3Jkcywgd2Ugd291 bGQgc3RpbGwgd2FudCB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdmFsaWRhdGUgdGhlIHN0YXRlcyBv biBlYWNoIG5ldHdvcmsgbm9kZSBzbyB0aGF0LCB3aGVuIGluZ3Jlc3NlcyBzdGVlciBwYWNrZXRz IHVzaW5nIGNvbWJpbmF0aW9ucyBzZWdtZW50cyAodGhhdCBtYWtlcyB1c2Ugb2YgdGhvc2Ugc3Rh dGVzKSwgdGhlbiBleHBlY3RlZCBhbmQgYWN0dWFsIHBhdGhzIGFsaWducy4NCg0KSSBpbnRlbnRp b25hbGx5IGRpZG7igJl0IGFuc3dlciB5b3VyIHF1ZXN0aW9uIG9uIHRoZSB1c2VmdWxuZXNzIG9m IFByb3h5IExTUCBQaW5nIG4gU2VnbWVudCBSb3V0aW5nLCBidXQgSSB3YW50ZWQgdG8gaGlnaGxp Z2h0IHdoYXQgYXJlIHRoZSBhZGRpdGlvbmFsIHBvaW50cyB3ZSB3b3VsZCB3YW50IHRvIGNvdmVy IGZyb20gT0FNIHBlcnNwZWN0aXZlLg0KDQpUaGFua3MhDQoNCi1Ob2JvDQoNCkZyb206IFFpbiBX dSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAx NCA1OjA4IEFNDQpUbzogTm9ibyBBa2l5YSAobm9ibyk7IFNhbSBBbGRyaW47IFJ1ZWRpZ2VyLkdl aWJAdGVsZWtvbS5kZTxtYWlsdG86UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPg0KQ2M6IHNwcmlu ZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNClN1YmplY3Q6IFJFOiBbc3ByaW5nXSBR dWVzdGlvbnMNCg0KVmVyeSBnb29kIHBvaW50LCBzaW5jZSBzZWdtZW50IHJvdXRpbmcgZG9lc27i gJl0IHJlcXVpcmUgZWFjaCBuZXR3b3JrIG5vZGUgaW4gdGhlIHBhdGggdG8gbWFpbnRhaW4gc3Rh dGUgYW5kIG9ubHkgaW5ncmVzcyBub2RlIG1haW50YWlucyB0aGUgc3RhdGUgd2hpbGUNClByb3h5 LWxzcC1waW5nIHJlcXVpcmUgZWFjaCBuZXR3b3JrIG5vZGUgaW4gdGhlIHJldHVybiBwYXRoIHRv IG1haW50YWluIHRoZSBzdGF0ZS4NCldoeSBhcHBseSBQcm94eS1sc3AtcGluZyB0byBzcHJpbmcg T0FNPw0KDQpSZWdhcmRzIQ0KLVFpbg0K5Y+R5Lu25Lq6OiBzcHJpbmcgW21haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE5vYm8gQWtpeWEgKG5vYm8pDQrlj5HpgIHml7bpl7Q6 IDIwMTTlubQ35pyIMTHml6UgMzowMA0K5pS25Lu25Lq6OiBTYW0gQWxkcmluOyBSdWVkaWdlci5H ZWliQHRlbGVrb20uZGU8bWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4NCuaKhOmAgTog c3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0K5Li76aKYOiBSZTogW3Nwcmlu Z10gUXVlc3Rpb25zDQoNCkhpIFNhbSwNCg0KSnVzdCB0byBwb2ludCBvdXQgb25lIHRoaW5nIGFi b3V0IHRoaXMgZG9jdW1lbnQg4oCmDQoNClRoZSB0ZXN0IHBhY2tldCBnZW5lcmF0ZWQgZnJvbSBh IFBNUy9OTVMvRU1TL25ldHdvcmstZGV2aWNlIGNhbiBoYXZlIHRoZSBjb21wbGV0ZSBzZWdtZW50 IHN0YWNrIG9uIGhvdyB0byB0cmF2ZXJzZSB0aGUgbmV0d29yayBhcyB3ZWxsIGFzIGhvdyB0byBj b21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBmdXJ0aGVyIHNpZ25hbGluZywgT0FNIHN0YXRl IG1haW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMgbm9yIE9BTSBpbnZvbHZlbWVudCBieSBuZXR3 b3JrIG5vZGVzLg0KDQpUaGF0IG1ha2VzIHRoaXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZy b20gdXNpbmcgcHJveHkgTFNQIHBpbmcuDQoNClRoaXMgY2VydGFpbmx5IGhhcyBzb21lIHByb3Mg YW5kIGNvbnMgYnV0IGNhbiBiZSBxdWl0ZSB1c2VmdWwgYXMgb25lIG9mIHRoZSBPQU1zICh5ZXMg cGx1cmFsKSB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQoNClRoYW5rcyENCg0KLU5vYm8N Cg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBTYW0gQWxkcmluDQpTZW50OiBUaHVyc2RheSwgSnVseSAxMCwgMjAxNCAyOjEzIFBNDQpU bzogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdlci5HZWliQHRlbGVrb20u ZGU+DQpDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KU3ViamVjdDog UmU6IFtzcHJpbmddIFF1ZXN0aW9ucw0KDQpIaSBSdWVkaWdlciwNCg0KVGhhbmtzIGZvciB0aGUg cXVpY2sgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxpbmUuDQoNCk9uIFRo dSwgSnVsIDEwLCAyMDE0IGF0IDc6MTUgQU0sIDxSdWVkaWdlci5HZWliQHRlbGVrb20uZGU8bWFp bHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4+IHdyb3RlOg0KSGkgU2FtLA0KDQpteSByZXBs aWVzIGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRkZWQgdG8geW91ciB0ZXh0Lg0KDQotIFByb3h5LWxz cC1waW5nIGlzIE1QTFMgb25seSwgd2hpbGUgdGhlIFBNUyBhcmNoaXRlY3R1cmUgaXMgaW50ZW5k ZWQgZm9yIGV2ZXJ5IFNSIGRhdGEgcGxhbmUgKE1QTFMgKyBJUHY2KS4gV2UnbGwgY2xhcmlmeSB0 aGF0IGluIHRoZSBkcmFmdC4NCi0gUHJveHktbHNwLXBpbmcgaXMgZm9yIE1QTFMgTFNQIFBpbmcg KFJGQyA0Mzc5IC8gUkZDIDY0MjQpLCB3aGlsZSBvdXIgdXNlIGNhc2UgY2FuIHVzZSBhbnkgT0FN IChpbiBwYXJ0aWN1bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9yIEJGRCwgYW5kIElDTVB2NikN Cg0KQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3aXRoIGJyb2FkZXIgc2NvcGUgYW5k IGJldHRlciBmaXQgZm9yIFNQUklORyBhcyBhIHdob2xlLg0KJXNhbSAtIEkgYmVsaWV2ZSB5b3Ug c2F5IGl0IGlzIHVzZSBjYXNlIGRvY3VtZW50IGJlbG93LiBUaGVuIHNvbHV0aW9uIGlzIHRvbyBw cmVtYXR1cmUgYXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyB3ZSBoYXZlbid0IGRlbGliZXJhdGVk IG9uIHRoZSByZXF1aXJlbWVudHMgZWl0aGVyLg0KDQpBcyB5b3Ugd3JpdGUsIFNSIGJhc2VkIE9B TSBwYXJ0aWFsbHkgb2ZmZXJzIHNpbWlsYXIgZnVuY3Rpb25zIGFzIHByb3h5LWxzcC4gV2l0aG91 dCByZXF1aXJpbmcgdGhlIGFkZGl0aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9MU1IgcHJvY2Vzc2lu ZyBpbnRyb2R1Y2VkIGJ5IHByb3h5LWxzcC4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0KDQog ICAgICBTYW0gQWxkcmluIHdyb3RlOg0KDQogICAgICBJIGhhdmUgZmV3IHF1ZXN0aW9ucyBhYm91 dCB0aGlzIGRyYWZ0Lg0KDQogICAgICAxLiBUaGUgdGl0bGUgaXMgY29uZnVzaW5nIHRvIG1lLiBJ dCBzYXlzIE9BTSB1c2UgY2FzZSBidXQgaW4gc2VjdGlvbiAjMQ0KICAgICAgaXQgc2F5cyB0aGUg Zm9sbG93aW5nDQoNCiAgICAgIDxzbmlwPg0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGEgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIHN0YXRlbWVudCBhbmQNCiAgICAgICBpbGx1c3Ry YXRlcyBpdCB3aXRoIHVzZS1jYXNlcy4NCg0KICAgICAgIFRoZSBzb2x1dGlvbiBpcyBkZXNjcmli ZWQgZm9yIGEgc2luZ2xlIElHUCBNUExTIGRvbWFpbi4NCg0KICAgICAgIFRoZSBzb2x1dGlvbiBh cHBsaWVzIHRvIG1vbml0b3Jpbmcgb2YgTERQIExTUCdzIGFzIHdlbGwgYXMgdG8NCiAgICAgICBt b25pdG9yaW5nIG9mIFNlZ21lbnQgUm91dGVkIExTUCdzLg0KICAgICAgPGVuZCBzbmlwPg0KDQog ICAgICAgSW4gZmFjdCB0aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNvbHV0aW9uIHRvIGNlcnRh aW4gc2NlbmFyaW9zIGFuZCBub3QganVzdA0KICAgICAgIHByb3ZpZGluZyB1c2UgY2FzZXMvc2Nl bmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNhc2UgZHJhZnQgc2hvdWxkDQogICAg ICAgZG9jdW1lbnQgc2NlbmFyaW9zIHdoZXJlIGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVpcmVtZW50 cy4gU29sdXRpb25zIGNvdWxkDQogICAgICAgYmUgY292ZXJlZCB3aXRoIGV4aXN0aW5nIHRvb2xz ZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5nIG9uIHRoZSBHQVANCiAgICAgICBhbmFseXNp cy4gQnV0IHRoYXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhh biAxIHNvbHV0aW9uLA0KICAgICAgIHdoZXJlIGFzIHRoaXMgZG9jdW1lbnQgY291bGQganVzdCBm b2N1cyBvbiB1c2UgY2FzZXMgb25seS4NCg0KICAgICAgIElmIGluZmFjdCB0aGlzIGlzIHN1cHBv c2VkIHRvIGJlIGEgc29sdXRpb24gZG9jdW1lbnQsIHRoZW4gY2hhbmdpbmcgdGhlIHRpdGxlDQog ICAgICAgd291bGQgYmUgbW9yZSBtZWFuaW5nZnVsLiBUaGF0J3MgbXkgb2JzZXJ2YXRpb24uDQpb UkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZpZXcgdGhlIHRl eHQgb2Ygc2VjdGlvbiAxLg0KJXNhbSAtIE9LLiB0aGVuIEknZCBsaWtlIHRvIHNlZSBhbnkgc3Bl Y2lmaWMgc29sdXRpb24gY29udGVudCByZW1vdmVkLCB0aGF0IHdheSB3ZSBkb250IGhhdmUgdG8g ZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2VzIGVpdGhlciBvciBjb21wYXJlIHdpdGgg OkQNCg0KDQogICAgICAgMi4gdy5yLnQuIFNlY3Rpb24gbnVtYmVyICMyLCB0aGUgc2FtZSBwcm9i bGVtIGlzIGJlaW5nIHNvbHZlZCB3aXRoDQogICAgICAgImRyYWZ0LWlldGYtbXBscy1wcm94eS1s c3AtcGluZy0wMiIgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBpbiB0aGlzDQogICAgICAgc2Vj dGlvbiBjb3VsZCBiZSBkb25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRpb24gd2lzZSkgd2hl cmUsIHJlcXVlc3QgY291bGQNCiAgICAgICBiZSBzZW50IHRvIG1vbml0b3IgTEVSIGkgYW5kIExF UiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3RhbmRpbmcNCiAgICAgICByaWdo dD8gSWYgbm90LCBob3cgaXMgaXQgZGlmZmVyZW50IGhlcmU/DQpbUkddIFRoZSBQTVMgaXMgYWJs ZSB0byBzZXQgdXAgcGFja2V0cyB3aGljaCBzdGF5IGluIGRhdGEgcGxhbmUgYW5kIGV4ZWN1dGUg YSBkZXNpcmVkDQogICAgIGNoYWluIG9mIE1QTFMgTFNQcy4NCiVzYW0gLSBFeGVjdXRlIHlvdSBt ZWFuIHRyYXZlcnNlPyBvciBwZXJmb3JtIHNvbWV0aGluZyBlbHNlPw0KDQpbUkddIFByb3h5LWxz cCBzYXlzOiBUaGlzIGRvY3VtZW50IGRlZmluZXMgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBNUExT IHBpbmcgW1JGQzQzNzldIHRvDQogICBhbGxvdyBhIHRoaXJkIHBhcnR5IHRvIHJlbW90ZWx5IGNh dXNlIGFuIE1QTFMgRWNobyBSZXF1ZXN0IG1lc3NhZ2UgdG8NCiAgIGJlIHNlbnQgZG93biBhIExT UCBvciBwYXJ0IG9mIGFuIExTUC4NCiVzYW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9u cywgIGl0IGhhcyB0byBiZSBzb2x1dGlvbiBkb2N1bWVudCAgYW5kIGNhbm5vdCBjbGFpbSB0byBi ZSB1c2UgY2FzZSBkb2N1bWVudC4gQWxzbyB0aGlzIGRvY3VtZW50IGlzIG9uIGluZm9ybWF0aW9u IHRyYWNrLg0KDQpbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5b3UnZCBsaWtlIHRv IHJlbW90ZWx5IGV4ZWN1dGUgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IG9uIGFueSBMU1AsIHlvdSBj b3VsZCBlaXRoZXIgdXNlIHRoZSBQTVMgb3IgcHJveHktcGluZy4gVGhlIFBNUyBob3dldmVyIHNp bXBsaWZpZXMgYW5kIGFkZHMNCmZ1bmN0aW9uYWxpdHk6DQphKSBZb3UgZG9uJ3QgbmVlZCBhbiBh ZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlrZSBwcm94eS1waW5nIHRvIGNo ZWNrIGRhdGENCiAgIHBsYW5lIGxpdmVsaW5lc3MsIFJGQzQzNzkgaXMgZmluZS4gRGV1dHNjaGUg VGVsZWtvbSBvcGVyYXRlcyBhIFBNUyBpbXBsZW1lbnRhdGlvbi4NCiVzYW0gLSBSRkM0Mzc5IHBl cmZvcm1zIHZhbGlkYXRpb24gb2YgZGF0YXBsYW5lIGFuZCBhbHNvIGZpbmQgb3V0IGxvdCBtb3Jl IGVycm9ycy4gWW91IG5lZWQgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBwZXJmb3JtIHZhbGlk YXRpb24gY2hlY2tzLiBGb3IgbGl2ZW5lc3MgZGV0ZWN0aW9uLCBCRkQgaXMgcHJlZmVycmVkIHRv b2wsIGF0bGVhc3QgaW4gcHJlc2VudCBkZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1T IHNvbHV0aW9uIGlzIGRlc2lnbmVkIGZvciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5vdCB0byBw ZXJmb3JtIHZhbGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBldGM/IChJ IHRoaW5rIHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBkb2MgYWxz bykNCg0KYikgb25jZSBQTVMgZGV0ZWN0ZWQgZGF0YSBwbGFuZSBsaXZlbGluZXNzIGFuZCBjb3Jy ZWN0bmVzcyBvZiBNUExTIHRvcG9sb2d5IGJ5IFJGQzQzNzksDQogICBpdCBjYW4gY29udGludWUg dG8gZXhlY3V0ZSBhcmJpdHJhcnkgTFNQIGNvbWJpbmF0aW9ucyBhbmQgdGhlIG1vbml0b3Jpbmcg cGFja2V0cyBzdGF5DQogICBpbiBkYXRhIHBsYW5lLiBQbGVhc2UgcG9pbnQgbWUgdG8gdGhlIHRl eHQgaW4gcHJveHktcGluZyBvZmZlcmluZyB0aGlzIGZlYXR1cmUuDQolc2FtIC0gVGhpcyB5b3Ug Y291bGQgcGVyZm9ybSBldmVuIHdpdGhvdXQgcHJveHkgcGluZy4gVGhlIGZ1bmN0aW9uIHlvdSBh cmUgZGVzY3JpYmluZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBs c3AgcGluZyBkb2VzLiBBZ2FpbiBJIGFtIG5vdCB0YWxraW5nIGFib3V0IG5vbi1tcGxzIHRvcG9s b2d5Lg0KVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS4NCi0gUGVyZm9y bSB0cmVldHJhY2Ugd2l0aCByZmM0Mzc5IHRvIGdldCB0b3BvbG9neSBpbmZvDQotIHBpY2sgYW55 IGFyYml0YXJ5IExTUCBwYXRocyBkaXNjb3ZlcmVkIGFsb25nIHdpdGggaXRzIG11bHRpcGF0aCBp bXBsZW1lbnRhdGlvbi4NCi0gcGVyZm9ybSBwaW5nIHdpdGggcmlnaHQgc2VsZWN0b3JzIGZvciB0 aGUgcGF0aCBhbmQgdXNlIFRUTCBmb3IgbGltaXRpbmcgdGhlIGhvcCBbTEVSIGpdLg0KLSBpZiB5 b3Ugd2FudCB0byBwZXJmb3JtIGZyb20gTEVSIGkgdG8gTEVSIGogYXMgaW4geW91ciBkcmFmdCwg dXNlIHByb3h5IHBpbmcgdG8gc3RhcnQgZnJvbSBMRVIgaQ0KDQogICAgICAgIDMuIFdoZW4gdGhl IHJlc3BvbnNlIGlzIHNlbnQgYmFjayB0byBQTVMgd2hpY2ggaXMgbm90IHBhcnQgb2YgTVBMUyBv ciBzZWdtZW50DQogICAgICAgIGRvbWFpbiwgdGhlcmUgaXMgYSBzZXJpb3VzIHNlY3VyaXR5IGFz cGVjdCwgd2hpY2ggbmVlZHMgdG8gY29uc2lkZXJlZC4gSSBiZWxpZXZlDQogICAgICAgIGl0IGFw cGxpZXMgdG8gc2VuZGluZyBhIHJlcXVlc3QgdG9vLiBXaWxsIHlvdSBiZSBkb2N1bWVudGluZyB0 aGF0IGFzcGVjdD8NCltSR10gVGhhdCdzIGEgdmFsaWQgcG9pbnQuIFRoZSBkb21haW4gZXh0ZXJu YWwgc3lzdGVtIGlzIG9uZSBvcHRpb24gYW5kIHRoZSB0ZWFtIHdpbGwgZGVhbCB3aXRoIHRoZSBz ZWN1cml0eSBhc3BlY3RzIHJhaXNlZCBieSB0aGlzIG9wdGlvbiBvbmNlIHdlIGFyZSBpbiBzb2x1 dGlvbiBzcGFjZS4gV2Ugd2lsbCBub3QgYW5hbHlzZSB0aGlzIGluIGRlcHRoIGZvciBhIHVzZSBj YXNlIGRvY3VtZW50Lg0KJXNhbSAtIG5vZA0KDQogICAgICAgIDQuIFNlYyAzLjIgdG8gbW9uaXRv ciBidW5kbGUgbGlua3MsIG9uZSBjb3VsZCBwZXJmb3JtIHRoYXQgd2l0aCBSRkM0Mzc5IHBpbmcN CiAgICAgICAgd2l0aCBtdWx0cGF0aCArIHByb3h5IHBpbmcuIENvdWxkIHlvdSBraW5kbHkgZGlm ZmVyZW50aWF0ZSBpZiB0aGVyZSBpcyBzb21ldGhpbmcNCiAgICAgICAgbmV3IHRoZSBzb2x1dGlv biBicmluZ3MgaGVyZT8NCltSR10gVGhlIFNSIE9BTSBhdXRob3IgdGVhbSBoYXMgcHJvdmlkZWQg dGV4dCBob3cgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbiB0aGUgdXNlIGNhc2UgZHJhZnQu IFlvdSBhcmUgYSBjby1hdXRob3Igb2YgcHJveHktbHNwLiBJIGNvdWxkbid0IGZpbmQgZXhwbGlj aXQgdGV4dCBvbiBob3cgdG8gZGV0ZWN0IGFuZCBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIGRy YWZ0LXByb3h5LWxzcC4gUGxlYXNlIGRlc2NyaWJlIGhvdyBwcm94eS1sc3AgY2FuIGJlIHVzZWQg dG8gbW9uaXRvciBhIGJ1bmRsZWQgbGluayAoc29ycnkgaWYgdGhpcyBpcyBvYnZpb3VzIGFuZCBJ IG1pc3NlZCBpdCkuIElmIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyB0byB0aGUgU1IgT0FNIGFwcHJv YWNoLCB3ZSdsbCBkaXNjdXNzIHRoZW0uDQolc2FtIC0gVGhlIHNhbWUgc3RlcHMgZGVzY3JpYmVk IGFib3ZlIGNvdWxkIGJlIHVzZWQgaWYgZWFjaCBidW5kbGVkIGxpbmsgbWVtYmVyIGlzIGlkZW50 aWZpZWQgd2l0aCBhIHVuaXF1ZSBsYWJlbC4gV2hpbGUgcGVyZm9ybWluZyB0cmVlIHRyYWNlIG9y IHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRoIERETUFQIGluZm8g Zm9yIGVhY2ggb2YgdGhlIGxpbmtzIGFuZCB0aGUgbXVsdGlwYXRoIGluZm8gZm9yIHRoZSBzYW1l Lg0KSWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUgbGFiZWwgc3RhY2ss IHRoZW4geW91IGNvdWxkIHVzZSBsc3Agc2VsZWN0b3JzIGFzIGRlZmluZWQgaW4gUkZDNDM3OSwg aW4gdGhpcyBjYXNlIGl0IGlzIGxvY2FsIGhvc3QgZGVzdCBpcCBhZGRyLCB0byBpZGVudGlmeSBl YWNoIGxpbmsgbWVtYmVyLg0KTm93IGlmIHRoZSBNUExTIGZvcndhcmRpbmcgbGF5ZXIgc2VlcyB0 aGUgYnVuZGxlZCBsaW5rIGFzIG9uZSBpbnRlcmZhY2UgYnV0IGNhbm5vdCBkaXNjZXJuIGl0cyBs aW5rIG1lbWJlcnMsIHRoZW4geW91IGNvdWxkIG9ubHkgdmFsaWRhdGUgdGhlIGludGVyZmFjZSBh bmQgbm90IGl0cyBpbmRpdmlkdWFsIG1lbWJlcnMuDQpTYW1lIGFwcGxpZXMgaW4geW91ciBjYXNl IHRvby4gQ2Fubm90IHNlZSBob3cgaXQgaXMgZGlmZmVyZW50Lg0KDQoNCg0KICAgICAgICAgNS4g c2VjICM1LCBJcyB0aGUgcmVxdWlyZW1lbnQgaGVyZSBvbmx5IGZvciBQTVMgdG8gbGVhcm4gdGhl IHRvcG9sb2d5LCBpbiB0aGUNCiAgICAgICAgICAgIGNhc2Ugb2YgbWl4ZWQgZW52Pw0KW1JHXSBN UExTIHRvcG9sb2d5IGF3YXJlbmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1cCBwYWNr ZXRzIHdpdGggbGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQcy4g SWYgc3VpdGFibGUgTGFiZWwvRkVDL25vZGUgcmVsYXRpb24gaXMga25vd24gdG8gdGhlIFBNUywg dGhhdCBMU1AgY2FuIGJlIGV4ZWN1dGVkIGZyb20gdGhhdCBub2RlIG9uIGJ5IGEgUE1TIG1vbml0 b3JpbmcgcGFja2V0Lg0KJXNhbSAtIFNvLCB5b3UgYXJlIHNheWluZyB0aGF0IHlvdSBzdGlsbCBu ZWVkIHRvIHBlcmZvcm0gUkZDNDM3OSB0cmFjZSBvciB0cmVldHJhY2UgdG8gZ2V0IHRvcG9sb2d5 LiBJIGRvIG5vdCB0aGluayBJR1AgZXh0ZW5zaW9ucyBiZWluZyBwcm9wb3NlZCBpbiBTUFJJTkcg ZXhwb3J0IGFueSBvZiB0aGUgaW5mbyBvdGhlciB0aGFuIGxhYmVsIHN0YWNrLg0KQW5kIHRoZSBw cm9wb3NlZCBQTVMgc29sdXRpb24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwgaXQgcGVyZm9ybXMg b24gZGVtYW5kIHBlciBzZWdtZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28gZG9lcywgYWxiZWl0 IG9ubHkgZm9yIE1QTFMgdG9wb2xvZ3kuDQpUaGUgY2FzZSB5b3UgYXJlIG1ha2luZyBpcyB0aGF0 IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9mIFJGQzQzNzkuDQoNClF1ZXN0aW9uIEkg aGF2ZSBmb3IgeW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMgYXJlIGdldHRpbmcgZHJvcHBl ZCBhbmQgUE1TIHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4gTFNQIG9yIFNlZ21l bnQsIGhvdyBkbyB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cg ZG8geW91IGZpZ3VyZSBvdXQgd2hlcmUgaXQgaXM/DQpBdCBsZWFzdCB3aXRoIFJGQzQzNzkgYW5k L29yIHByb3h5IHBpbmcsIHlvdSBjb3VsZCB2YWxpZGF0ZSBlYWNoIGhvcCBiZWNhdXNlIG9mIHRo ZSBiZWxscyBhbmQgd2hpc3RsZXMgaXQgY2FycmllcyBhbG9uZyB3aXRoIHRoZSBwYWNrZXQuDQoN Cg0KDQogICAgICAgICA2LiBJbiBzZWMgMy4xLA0KICAgICAgICAgPHNuaXA+DQogICAgICAgICBE ZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8gYSBtZWFzdXJlbWVudCBt YXkgYWxzbyBiZQ0KICAgICAgICAgZG9uZSBieSBzZXR0aW5nIHVwIGEgbGFiZWwgaW5jbHVkaW5n IGFsbCBub2RlIFNJRHMgYWxvbmcgdGhhdCBwYXRoDQogICAgICAgICAoaWYgTEVSMSBoYXMgTm9k ZSBTSUQgNDAgaW4gdGhlIGV4YW1wbGUgYW5kIGl0IHNob3VsZCBiZSBwYXNzZWQNCiAgICAgICAg IGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLCB0aGUgbGFiZWwgc3RhY2sgaXMgMjAgLSA0MCAtIDMw IC0gMTApLiAgVGhlDQogICAgICAgICBhZHZhbnRhZ2Ugb2YgdGhpcyBtZXRob2QgaXMsIHRoYXQg aXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTQ0KICAgICAgICAgZnVuY3Rpb25hbGl0eSBhbmQg aXQgaXMgaW5kZXBlbmRlbnQgb2YgRUNNUCBmdW5jdGlvbmFsaXRpZXMuICBUaGUNCiAgICAgICAg IG1ldGhvZCBzdGlsbCBpcyBhYmxlIHRvIG1vbml0b3IgYWxsIGxpbmsgY29tYmluYXRpb25zIG9m IGFsbCBwYXRocyBvZg0KICAgICAgICAgYW4gTVBMUyBkb21haW4uICBJZiBjb3JyZWN0IGZvcndh cmRpbmcgYWxvbmcgdGhlIGRlc2lyZWQgcGF0aHMgaGFzIHRvDQogICAgICAgICBiZSBjaGVja2Vk LCBSRkM0NzM5IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGFwcGxpZWQgYWxzbyBpbiB0aGlzDQog ICAgICAgICBjYXNlLg0KDQogICAgICAgICA8ZW5kIHNuaXA+DQoNCiAgICAgICAgIEluIHRoZSBh Ym92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMgbm90IGludm9sdmUgTVBMUyBPQU0uIEJ1dCBs YXRlciB5b3Ugc2F5LA0KICAgICAgICAgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IGNvdWxkIGJlIHVz ZWQuIENvdWxkIHlvdSBjbGFyaWZ5IGhvdyBjb3VsZCB5b3UgdmVyaWZ5IGENCiAgICAgICAgIHBh dGgsIGlmIE1QTFMgdmFsaWRhdGlvbiBpcyBub3QgZG9uZS4gTW9yZSB0ZXh0IHdpbGwgaGVscC4g QWxzbywgbW9yZQ0KICAgICAgICAgaW1wb3J0YW50bHksIHRoZSB0ZXh0IGVhcmxpZXIgdG8gdGhl IGFib3ZlIHNheXMsIGZvciB2YWxpZCByZXN1bHQsIE1QTFMNCiAgICAgICAgIE9BTSBoYXMgdG8g YmUgcGVyZm9ybWVkIGZvciB0b3BvbG9neSBjaGFuZ2VzIGV0Yy4gSWYgc28sIGl0IGNvbnRyYWRp Y3RzIGhlcmUuDQpbUkddIFRoZSB0ZXh0IHNob3VsZCBzYXkgdGhhdA0KLSB3aXRob3V0IE1QTFMg T0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVjdXRlcyBhIHNldCBvZiBwYXRocyBvbmx5IGJhc2Vk IG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24uDQotIGlmIHRoZSBvcGVyYXRvciB3YW50cyB0 byBtYWtlIHN1cmUgdGhhdCBkYXRhIHBsYW5lIGNvcnJlc3BvbmRzIHRvIGNvbnRyb2wgcGxhbmUs IFJGQzQ3MzkgZnVuY3Rpb25zIHNob3VsZCBiZSBhcHBsaWVkLg0KSWYgeW91IHVuZGVyc3RhbmQg dGhpcyBzdGF0ZW1lbnQgYW5kIHRoZSB0ZXh0IGluIHRoZSBkcmFmdCBzdGF0ZXMgc29tZXRoaW5n IGRpZmZlcmVudCwgSSdsbCB0cnkgdG8gcmV3b3JkIGl0Lg0KJXNhbSAtIFRoZSBwcm9ibGVtIEkg YW0gaGF2aW5nIGlzLCBpbiB0aGUgY2FzZSBvZiBNUExTLCBmb3IgT0FNLCB5b3UgaGF2ZSB0byB2 YWxpZGF0ZSB0aGUgbHNwLg0KSSBkZWZpbml0ZWx5IHNlZSBhIHNwZWNpZmljIG5lZWQgZm9yIFNQ UklORywgYnV0IHdoYXQgSSBmZWVsIGlzLCB0aGUgdXNlIGNhc2UgaXMgdG9vIG11Y2ggY2F0ZXJl ZCB0byBhIHNwZWNpZmljIGVudmlzaW9uZWQgc29sdXRpb24uDQpPbmNlIHlvdSByZW1vdmUgc29s dXRpb24gb3Igc3VnZ2VzdGVkIGVuaGFuY2VtZW50cywgaG9wZSBpdCBzaG91bGQgYmUgY2xlYXIg b24gd2hhdCBpcyBiZWluZyBzb2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMg Zm9yIGEgc29sdXRpb24uDQpGb3Igc29sdXRpb24gcGFydCwgcGxlYXNlIHB1Ymxpc2ggYSBzZXBh cmF0ZSBJRC4NCg0KDQogICAgICAgICA3LiBMYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCBob3cgZGlm ZmVyZW50IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPw0KICAgICAgICAgU29tZWhvdyBJIGNvdWxk bid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ugd2hhdCBQTVMgY291bGQgZG8gYW5kDQogICAgICAgICBO TVMvRU1TIGNvdWxkbid0Lg0KW1JHXSBJJ3ZlIG5ldmVyIGhlYXJkIG9mIGFuIEVNUy9OTVMgd2hp Y2ggaXMgTVBMUyB0b3BvbG9neSBhd2FyZSBhbmQgdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVz cyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZyBMU1AgY29tYmluYXRpb25z IGFzIGRlc2lyZWQgYnkgYW4gb3BlcmF0b3IuIEhhZCB0aGlzIGZlYXR1cmUgYmVlbiBjb21tZXJj aWFsbHkgYXZhaWxhYmxlLCB0aGUgY29tcGFueSBJIHdvcmsgZm9yIHdvdWxkbid0IGhhdmUgYmVl biBkZXZlbG9waW5nIGEgUE1TLg0KJXNhbSAtIFRoZXJlIGFyZSB0b29scyB3aGljaCBhcmUgcGFy dCBvZiBOTVMvT1NTLCB3aGljaCBwZXJmb3JtcyBNUExTIHRvcG9sb2d5IHNwZWNpZmljIG9wZXJh dGlvbnMgIGZvciBhIGdpdmVuIHNldCBvZiBMU1Ancy4gVGhleSBwZXJmb3JtIFRyZWV0cmFjZSBh bmQgcGVyZm9ybSBwaW5nIHdpdGggbXVsdGlwYXRoLiBBbHNvIHBlcmZvcm0gTFNQIHNwZWNpZmlj IHZhbGlkYXRpb24gYnkgY3JhZnRpbmcgcGFja2V0cyB3aXRoIGRhdGEgYXZhaWxhYmxlIHdpdGgg dHJlZXRyYWNlIGFuZCBwaW5nIHdpdGggbXVsdGlwYXRoLiBZb3UgY291bGQgYXV0b21hdGUgdGhl IHdvcmtmbG93IHdpdGhvdXQgdGhlIG5lZWQgZm9yIE9TUy9QTVMsIGJ5IHVzaW5nIHByb2JlIHRl Y2hub2xvZ3kuIFdpbGwgbm90IHNheSBiZXlvbmQgdGhhdCA6RA0KDQpjaGVlcnMNCi1zYW0NCg0K DQo= --_000_B8F9A780D330094D99AF023C5877DABA84582F37nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOah huaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 5om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLkJhbGxvb25UZXh0LCBs aS5CYWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1p bHk65a6L5L2TO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NjE1NTA4Mjk7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjYwNTE0ODIwIDI2OTAyNTI5NSAyNjkwMjUz MDUgMjY5MDI1MzA3IDI2OTAyNTI5NSAyNjkwMjUzMDUgMjY5MDI1MzA3IDI2OTAyNTI5NSAyNjkw MjUzMDUgMjY5MDI1MzA3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLCBOb2JvOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGUgYXNwZWN0cyB0aGF0IGFyZSBt aXNzaW5nIGluDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5kcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ U3ByaW5nIHByb2JsZW0gc3RhdGVtZW50IHNheXMgdGhlIFNQUklORyBhcmNoaXRlY3R1cmUgd2ls bCBhZGRyZXNzIHVzZSBjYXNlcyB3aGVyZSByZW1vdmFsIG9mIHNpZ25hbGluZyBhbmQgcGF0aCBz dGF0ZSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdGhlIGNvcmUgaXMgYSBy ZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93IHlvdSBzYWlkIGVhY2ggbmV0d29yayBub2Rl IHN0aWxsIGhhcyBzdGF0ZXMgcmVsYXRlZCB0byB2YXJpb3VzIHNlZ21lbnQgdHlwZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUgeW91IHNheWluZyBOb24t U1Igbm9kZSBpbiB0aGUgU1IgZG9tYWluIHNob3VsZCBub3QgbWFpbnRhaW4gYW55IHBhdGggc3Rh dGUgb3Igc2VnbWVudCByb3V0aW5nIHJlbGF0ZWQgc3RhdGUgYnV0IFNSIGVuYWJsZWQgbm9kZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIFNSIGRvbWFp biBNVVNUIGhhdmUgc2VnbWVudCByb3V0aW5nIHJlbGF0ZWQgc3RhdGU/IExldCBtZSBrbm93IGlm IG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPi1RaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPiBOb2JvIEFraXlhIChub2JvKSBbbWFpbHRvOm5vYm9AY2lz Y28uY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk65a6L5L2TIj4gMjAxNDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43PC9zcGFuPuaciDxz cGFuIGxhbmc9IkVOLVVTIj4xNDwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMjA6Mzk8 YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gUWluIFd1OyBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVr b20uZGU8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2Fz ZTxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBSRTogW3NwcmluZ10gUXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBRaW4sIGV0IGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5F YWNoIG5ldHdvcmsgbm9kZSB3aWxsIHN0aWxsIGhhdmUgc29tZSBzdGF0ZXMgKGkuZS4gbm9kZS9h ZGphY2VuY3kvc2VydmljZSBzZWdtZW50cykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgc2VlIHRoZSB0ZWNobmlxdWUgZGVzY3JpYmVkIGRyYWZ0LWdlaWItc3ByaW5nLW9h bS11c2VjYXNlIGFzIGEgd2F5IHRvIG1vbml0b3IgdGhlIG5ldHdvcmssIGJ1dCBub3QgYSB3YXkg dG8gdmFsaWRhdGUgdGhlIHNlZ21lbnRzLiBJbiBwYXJ0aWN1bGFyDQogdGhlIGZvbGxvd2luZyBh c3BlY3RzIGNhbm5vdCBiZSB2YWxpZGF0ZWQgYnkgdGhlIHRlY2huaXF1ZSBkZXNjcmliZWQgZHJh ZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VXNpbmcgYSBzZWdtZW50IG9yIGNvbWJpbmF0aW9uIG9mIHNlZ21lbnRzIHJl c3VsdCBpbiBhIHBhY2tldCB0byByZWFjaCBhbiBleHBlY3RlZCBuZXR3b3JrIG5vZGUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVzaW5nIGFuIGFkamFj ZW5jeSBzZWdtZW50IHJlc3VsdHMgaW4gYSBwYWNrZXQgdG8gdHJhdmVyc2Ugb3ZlciBhbiBleHBl Y3RlZCBhZGphY2VuY3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlVzaW5nIGEgc2VydmljZSBzZWdtZW50IHJlc3VsdHMgaW4gYSBwYWNrZXQgdG8gaGl0 IGFuIGV4cGVjdGVkIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgd2h5IEkgcHJldmlvdXNseSBtZW50aW9uZWQgdGhhdCB0aGUgdGVjaG5pcXVlIGlz IHVzZWZ1bCBhcyBvbmUgb2YgdGhlIE9BTXMgdXNlZCB0byBtb25pdG9yIHRoZSBuZXR3b3JrLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBvdGhlciB3b3Jkcywgd2Ugd291 bGQgc3RpbGwgd2FudCB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdmFsaWRhdGUgdGhlIHN0YXRlcyBv biBlYWNoIG5ldHdvcmsgbm9kZSBzbyB0aGF0LCB3aGVuIGluZ3Jlc3NlcyBzdGVlciBwYWNrZXRz IHVzaW5nDQogY29tYmluYXRpb25zIHNlZ21lbnRzICh0aGF0IG1ha2VzIHVzZSBvZiB0aG9zZSBz dGF0ZXMpLCB0aGVuIGV4cGVjdGVkIGFuZCBhY3R1YWwgcGF0aHMgYWxpZ25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGludGVudGlvbmFsbHkgZGlkbuKAmXQgYW5zd2Vy IHlvdXIgcXVlc3Rpb24gb24gdGhlIHVzZWZ1bG5lc3Mgb2YgUHJveHkgTFNQIFBpbmcgbiBTZWdt ZW50IFJvdXRpbmcsIGJ1dCBJIHdhbnRlZCB0byBoaWdobGlnaHQgd2hhdCBhcmUgdGhlIGFkZGl0 aW9uYWwNCiBwb2ludHMgd2Ugd291bGQgd2FudCB0byBjb3ZlciBmcm9tIE9BTSBwZXJzcGVjdGl2 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tTm9ibzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFpbiBXdSBbPGEgaHJlZj0ibWFpbHRvOmJpbGwu d3VAaHVhd2VpLmNvbSI+bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDU6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IE5v Ym8gQWtpeWEgKG5vYm8pOyBTYW0gQWxkcmluOyA8YSBocmVmPSJtYWlsdG86UnVlZGlnZXIuR2Vp YkB0ZWxla29tLmRlIj4NClJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvYT48YnI+DQo8Yj5DYzo8 L2I+IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2U8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5WZXJ5IGdvb2QgcG9p bnQsIHNpbmNlIHNlZ21lbnQgcm91dGluZyBkb2VzbuKAmXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsg bm9kZSBpbiB0aGUgcGF0aCB0byBtYWludGFpbiBzdGF0ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUg bWFpbnRhaW5zIHRoZSBzdGF0ZQ0KIHdoaWxlIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UHJveHktbHNwLXBpbmcgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZSBp biB0aGUgcmV0dXJuIHBhdGggdG8gbWFpbnRhaW4gdGhlIHN0YXRlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2h5IGFwcGx5IFByb3h5LWxzcC1waW5nIHRvIHNw cmluZyBPQU0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kyI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gc3By aW5nIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5Ob2Jv IEFraXlhIChub2JvKTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OuWui+S9kyI+IDIwMTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Nzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuaciDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4xMTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuaX pTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TIj4NCiAzOjAwPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5pS25Lu25Lq6PC9zcGFuPjwvYj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj4gU2FtIEFsZHJpbjsNCjxhIGhyZWY9Im1haWx0bzpSdWVkaWdl ci5HZWliQHRlbGVrb20uZGUiPlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTwvYT48YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7m ioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTrlrovkvZMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPiBzcHJpbmc7IGRyYWZ0 LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj4gUmU6IFtzcHJpbmddIFF1ZXN0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBTYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkp1c3QgdG8gcG9p bnQgb3V0IG9uZSB0aGluZyBhYm91dCB0aGlzIGRvY3VtZW50IOKApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGUgdGVzdCBwYWNrZXQgZ2VuZXJhdGVkIGZyb20gYSBQTVMv Tk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4gaGF2ZSB0aGUgY29tcGxldGUgc2VnbWVudCBzdGFj ayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdvcmsgYXMgd2VsbCBhcyBob3cgdG8NCiBjb21l IGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBmdXJ0aGVyIHNpZ25hbGluZywgT0FNIHN0YXRlIG1h aW50ZW5hbmNlIG9uIG5ldHdvcmsgbm9kZXMgbm9yIE9BTSBpbnZvbHZlbWVudCBieSBuZXR3b3Jr IG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0IG1ha2VzIHRo aXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkgTFNQIHBpbmcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgY2VydGFpbmx5IGhhcyBzb21l IHByb3MgYW5kIGNvbnMgYnV0IGNhbiBiZSBxdWl0ZSB1c2VmdWwgYXMgb25lIG9mIHRoZSBPQU1z ICh5ZXMgcGx1cmFsKSB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc3ByaW5nIFs8YSBocmVm PSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlNhbSBBbGRyaW48YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEp1bHkgMTAsIDIwMTQgMjoxMyBQTTxicj4NCjxiPlRvOjwvYj4gPGEg aHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSI+UnVlZGlnZXIuR2VpYkB0ZWxl a29tLmRlPC9hPjxicj4NCjxiPkNjOjwvYj4gc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0t dXNlY2FzZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gUXVlc3Rpb25zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkhpIFJ1ZWRpZ2VyLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoYW5rcyBmb3IgdGhlIHF1aWNrIHJl c3BvbnNlLiBQbGVhc2UgZmluZCBteSByZXNwb25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+T24g VGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpSdWVkaWdl ci5HZWliQHRlbGVrb20uZGUiIHRhcmdldD0iX2JsYW5rIj5SdWVkaWdlci5HZWliQHRlbGVrb20u ZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SGkgU2FtLDxicj4NCjxicj4NCm15IHJlcGxpZXMgYXJl IG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuPGJyPg0KPGJyPg0KLSBQcm94eS1s c3AtcGluZyBpcyBNUExTIG9ubHksIHdoaWxlIHRoZSBQTVMgYXJjaGl0ZWN0dXJlIGlzIGludGVu ZGVkIGZvciBldmVyeSBTUiBkYXRhIHBsYW5lIChNUExTICYjNDM7IElQdjYpLiBXZSdsbCBjbGFy aWZ5IHRoYXQgaW4gdGhlIGRyYWZ0Ljxicj4NCi0gUHJveHktbHNwLXBpbmcgaXMgZm9yIE1QTFMg TFNQIFBpbmcgKFJGQyA0Mzc5IC8gUkZDIDY0MjQpLCB3aGlsZSBvdXIgdXNlIGNhc2UgY2FuIHVz ZSBhbnkgT0FNIChpbiBwYXJ0aWN1bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9yIEJGRCwgYW5k IElDTVB2Nik8YnI+DQo8YnI+DQpCYXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGgg YnJvYWRlciBzY29wZSBhbmQgYmV0dGVyIGZpdCBmb3IgU1BSSU5HIGFzIGEgd2hvbGUuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj4lc2FtIC0gSSBiZWxpZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9j dW1lbnQgYmVsb3cuIFRoZW4gc29sdXRpb24gaXMgdG9vIHByZW1hdHVyZSBhdCB0aGlzIHBvaW50 IG9mIHRpbWUsIGFzIHdlIGhhdmVuJ3QgZGVsaWJlcmF0ZWQgb24gdGhlIHJlcXVpcmVtZW50cyBl aXRoZXIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQpBcyB5b3Ugd3JpdGUsIFNSIGJhc2VkIE9BTSBwYXJ0 aWFsbHkgb2ZmZXJzIHNpbWlsYXIgZnVuY3Rpb25zIGFzIHByb3h5LWxzcC4gV2l0aG91dCByZXF1 aXJpbmcgdGhlIGFkZGl0aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9MU1IgcHJvY2Vzc2luZyBpbnRy b2R1Y2VkIGJ5IHByb3h5LWxzcC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQpSZWdhcmRzLDxi cj4NCjxicj4NClJ1ZWRpZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNhbSBBbGRyaW4gd3JvdGU6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBoYXZlIGZldyBxdWVzdGlvbnMgYWJvdXQg dGhpcyBkcmFmdC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBUaGUgdGl0bGUg aXMgY29uZnVzaW5nIHRvIG1lLiBJdCBzYXlzIE9BTSB1c2UgY2FzZSBidXQgaW4gc2VjdGlvbiAj MTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGl0IHNheXMgdGhlIGZvbGxvd2luZzxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtzbmlwJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gdG8gdGhpcyBw cm9ibGVtIHN0YXRlbWVudCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbGx1 c3RyYXRlcyBpdCB3aXRoIHVzZS1jYXNlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtUaGUgc29sdXRpb24gaXMgZGVzY3JpYmVkIGZvciBhIHNpbmdsZSBJR1AgTVBMUyBk b21haW4uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHNvbHV0aW9u IGFwcGxpZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQ J3MuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2VuZCBzbmlwJmd0Ozxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luIGZhY3QgdGhlIGRyYWZ0IGlzIGRlc2NyaWJp bmcgYSBzb2x1dGlvbiB0byBjZXJ0YWluIHNjZW5hcmlvcyBhbmQgbm90IGp1c3Q8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwcm92aWRpbmcgdXNlIGNhc2VzL3NjZW5hcmlvcy4gTXkg dW5kZXJzdGFuZGluZyB3YXMsIHVzZSBjYXNlIGRyYWZ0IHNob3VsZDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50IHNjZW5hcmlvcyB3aGVyZSBpdCB3aWxsIGRyaXZlIG5l dyByZXF1aXJlbWVudHMuIFNvbHV0aW9ucyBjb3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2JlIGNvdmVyZWQgd2l0aCBleGlzdGluZyB0b29sc2V0IG9yIGRlZmluZWQgbmV3bHks IGRlcGVuZGluZyBvbiB0aGUgR0FQPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5h bHlzaXMuIEJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0ZSBhcyB0aGVyZSBjb3VsZCBiZSBtb3Jl IHRoYW4gMSBzb2x1dGlvbiw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZSBh cyB0aGlzIGRvY3VtZW50IGNvdWxkIGp1c3QgZm9jdXMgb24gdXNlIGNhc2VzIG9ubHkuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgaW5mYWN0IHRoaXMgaXMgc3VwcG9z ZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUgdGl0bGU8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRo YXQncyBteSBvYnNlcnZhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bUkddIFRoYW5rcy4gSXQncyBhIHVz ZSBjYXNlIGRvY3VtZW50LiBXZSdsbCByZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+JXNhbSAtIE9LLiB0aGVuIEknZCBsaWtlIHRvIHNlZSBh bnkgc3BlY2lmaWMgc29sdXRpb24gY29udGVudCByZW1vdmVkLCB0aGF0IHdheSB3ZSBkb250IGhh dmUgdG8gZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2VzIGVpdGhlciBvciBjb21wYXJl IHdpdGggOkQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsy LiB3LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29s dmVkIHdpdGg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtkcmFmdC1pZXRm LW1wbHMtcHJveHktbHNwLXBpbmctMDImcXVvdDsgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBp biB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VjdGlvbiBjb3VsZCBiZSBk b25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRpb24gd2lzZSkgd2hlcmUsIHJlcXVlc3QgY291 bGQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBzZW50IHRvIG1vbml0b3IgTEVS IGkgYW5kIExFUiBqIHNlZ21lbnQsIGZyb20gYSBQTVMuIElzIG15IHVuZGVyc3RhbmRpbmc8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyaWdodD8gSWYgbm90LCBob3cgaXMgaXQgZGlm ZmVyZW50IGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+W1JHXSBUaGUgUE1TIGlzIGFibGUgdG8gc2V0IHVw IHBhY2tldHMgd2hpY2ggc3RheSBpbiBkYXRhIHBsYW5lIGFuZCBleGVjdXRlIGEgZGVzaXJlZDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhaW4gb2YgTVBMUyBMU1BzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+JXNhbSAtIEV4ZWN1dGUgeW91IG1lYW4gdHJhdmVyc2U/IG9yIHBlcmZv cm0gc29tZXRoaW5nIGVsc2U/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQpbUkddIFByb3h5LWxzcCBzYXlz OiBUaGlzIGRvY3VtZW50IGRlZmluZXMgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBNUExTIHBpbmcg W1JGQzQzNzldIHRvPGJyPg0KJm5ic3A7ICZuYnNwO2FsbG93IGEgdGhpcmQgcGFydHkgdG8gcmVt b3RlbHkgY2F1c2UgYW4gTVBMUyBFY2hvIFJlcXVlc3QgbWVzc2FnZSB0bzxicj4NCiZuYnNwOyAm bmJzcDtiZSBzZW50IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBMU1AuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj4lc2FtIC0gSWYgaXQgaXMgcHJvcG9zaW5nIGV4dGVuc2lvbnMsICZuYnNw O2l0IGhhcyB0byBiZSBzb2x1dGlvbiBkb2N1bWVudCAmbmJzcDthbmQgY2Fubm90IGNsYWltIHRv IGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24gaW5mb3JtYXRp b24gdHJhY2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj48YnI+DQpbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5 b3UnZCBsaWtlIHRvIHJlbW90ZWx5IGV4ZWN1dGUgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IG9uIGFu eSBMU1AsIHlvdSBjb3VsZCBlaXRoZXIgdXNlIHRoZSBQTVMgb3IgcHJveHktcGluZy4gVGhlIFBN UyBob3dldmVyIHNpbXBsaWZpZXMgYW5kIGFkZHM8YnI+DQpmdW5jdGlvbmFsaXR5Ojxicj4NCmEp IFlvdSBkb24ndCBuZWVkIGFuIGFkZGl0aW9uYWwgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBs aWtlIHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDtwbGFuZSBsaXZl bGluZXNzLCBSRkM0Mzc5IGlzIGZpbmUuIERldXRzY2hlIFRlbGVrb20gb3BlcmF0ZXMgYSBQTVMg aW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gUkZDNDM3 OSBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIGRhdGFwbGFuZSBhbmQgYWxzbyBmaW5kIG91dCBsb3Qg bW9yZSBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2 YWxpZGF0aW9uIGNoZWNrcy4gRm9yIGxpdmVuZXNzIGRldGVjdGlvbiwgQkZEIGlzIHByZWZlcnJl ZCB0b29sLCBhdGxlYXN0IGluIHByZXNlbnQgZGVwbG95bWVudHMuU28NCiBhcmUgeW91IHNheWlu ZywgUE1TIHNvbHV0aW9uIGlzIGRlc2lnbmVkIGZvciBsaXZlbmVzcyBkZXRlY3Rpb24gYW5kIG5v dCB0byBwZXJmb3JtIHZhbGlkYXRpb24gb2YgZGF0YSBwbGFuZSB0byBjb250cm9sIHBsYW5lLCBl dGM/IChJIHRoaW5rIHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mIHRoZSBk b2MgYWxzbyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5iKSBvbmNlIFBNUyBk ZXRlY3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMgdG9w b2xvZ3kgYnkgUkZDNDM3OSw8YnI+DQombmJzcDsgJm5ic3A7aXQgY2FuIGNvbnRpbnVlIHRvIGV4 ZWN1dGUgYXJiaXRyYXJ5IExTUCBjb21iaW5hdGlvbnMgYW5kIHRoZSBtb25pdG9yaW5nIHBhY2tl dHMgc3RheTxicj4NCiZuYnNwOyAmbmJzcDtpbiBkYXRhIHBsYW5lLiBQbGVhc2UgcG9pbnQgbWUg dG8gdGhlIHRleHQgaW4gcHJveHktcGluZyBvZmZlcmluZyB0aGlzIGZlYXR1cmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gVGhpcyB5b3UgY291bGQgcGVyZm9ybSBldmVuIHdp dGhvdXQgcHJveHkgcGluZy4gVGhlIGZ1bmN0aW9uIHlvdSBhcmUgZGVzY3JpYmluZyBpcywgaG93 IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBsc3AgcGluZyBkb2VzLiBBZ2FpbiBJ IGFtIG5vdCB0YWxraW5nIGFib3V0IG5vbi1tcGxzIHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj5UbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj4tIFBlcmZvcm0gdHJlZXRyYWNlIHdpdGggcmZjNDM3OSB0byBnZXQgdG9wb2xv Z3kgaW5mbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4tIHBpY2sgYW55IGFyYml0YXJ5IExTUCBwYXRo cyBkaXNjb3ZlcmVkIGFsb25nIHdpdGggaXRzIG11bHRpcGF0aCBpbXBsZW1lbnRhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+LSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBzZWxlY3RvcnMgZm9y IHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUgaG9wIFtMRVIgal0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiPi0gaWYgeW91IHdhbnQgdG8gcGVyZm9ybSBmcm9tIExFUiBpIHRvIExF UiBqIGFzIGluIHlvdXIgZHJhZnQsIHVzZSBwcm94eSBwaW5nIHRvIHN0YXJ0IGZyb20gTEVSIGk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50IGJhY2sgdG8g UE1TIHdoaWNoIGlzIG5vdCBwYXJ0IG9mIE1QTFMgb3Igc2VnbWVudDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBkb21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1cml0eSBhc3Bl Y3QsIHdoaWNoIG5lZWRzIHRvIGNvbnNpZGVyZWQuIEkgYmVsaWV2ZTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBpdCBhcHBsaWVzIHRvIHNlbmRpbmcgYSByZXF1ZXN0IHRvby4gV2ls bCB5b3UgYmUgZG9jdW1lbnRpbmcgdGhhdCBhc3BlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+W1JHXSBUaGF0 J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRvbWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlv biBhbmQgdGhlIHRlYW0gd2lsbCBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGFzcGVjdHMgcmFpc2Vk IGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJlIGluIHNvbHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5v dCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9yIGEgdXNlIGNhc2UNCiBkb2N1bWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiVzYW0gLSBub2QmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA0LiBTZWMgMy4yIHRvIG1vbml0b3IgYnVuZGxlIGxpbmtzLCBvbmUgY291bGQgcGVyZm9ybSB0 aGF0IHdpdGggUkZDNDM3OSBwaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdp dGggbXVsdHBhdGggJiM0MzsgcHJveHkgcGluZy4gQ291bGQgeW91IGtpbmRseSBkaWZmZXJlbnRp YXRlIGlmIHRoZXJlIGlzIHNvbWV0aGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBuZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPltSR10gVGhlIFNS IE9BTSBhdXRob3IgdGVhbSBoYXMgcHJvdmlkZWQgdGV4dCBob3cgdG8gbW9uaXRvciBhIGJ1bmRs ZWQgbGluayBpbiB0aGUgdXNlIGNhc2UgZHJhZnQuIFlvdSBhcmUgYSBjby1hdXRob3Igb2YgcHJv eHktbHNwLiBJIGNvdWxkbid0IGZpbmQgZXhwbGljaXQgdGV4dCBvbiBob3cgdG8gZGV0ZWN0IGFu ZCBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4NCiBQbGVhc2UgZGVz Y3JpYmUgaG93IHByb3h5LWxzcCBjYW4gYmUgdXNlZCB0byBtb25pdG9yIGEgYnVuZGxlZCBsaW5r IChzb3JyeSBpZiB0aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYgdGhlcmUgYXJl IGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBPQU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1c3MgdGhlbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmli ZWQgYWJvdmUgY291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQgbGluayBtZW1iZXIgaXMgaWRl bnRpZmllZCB3aXRoIGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgdHJhY2Ug b3IgcGluZyB3aXRoIG11bHRpcGF0aCwgTEVSIGkgd2lsbCByZXNwb25kIHdpdGggRERNQVAgaW5m byBmb3IgZWFjaCBvZiB0aGUNCiBsaW5rcyBhbmQgdGhlIG11bHRpcGF0aCBpbmZvIGZvciB0aGUg c2FtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1i ZXIgaGFzIHNhbWUgbGFiZWwgc3RhY2ssIHRoZW4geW91IGNvdWxkIHVzZSBsc3Agc2VsZWN0b3Jz IGFzIGRlZmluZWQgaW4gUkZDNDM3OSwgaW4gdGhpcyBjYXNlIGl0IGlzIGxvY2FsIGhvc3QgZGVz dCBpcCBhZGRyLCB0byBpZGVudGlmeSBlYWNoIGxpbmsgbWVtYmVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj5Ob3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxp bmsgYXMgb25lIGludGVyZmFjZSBidXQgY2Fubm90IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywg dGhlbiB5b3UgY291bGQgb25seSB2YWxpZGF0ZSB0aGUgaW50ZXJmYWNlIGFuZCBub3QgaXRzIGlu ZGl2aWR1YWwgbWVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+U2FtZSBhcHBsaWVzIGluIHlv dXIgY2FzZSB0b28uIENhbm5vdCBzZWUgaG93IGl0IGlzIGRpZmZlcmVudC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB Ij48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NS4gc2VjICM1 LCBJcyB0aGUgcmVxdWlyZW1lbnQgaGVyZSBvbmx5IGZvciBQTVMgdG8gbGVhcm4gdGhlIHRvcG9s b2d5LCBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBjYXNlIG9mIG1peGVkIGVudj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bUkddIE1QTFMgdG9wb2xvZ3kgYXdh cmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24gdG8gc2V0IHVwIHBhY2tldHMgd2l0aCBsYWJlbCBz dGFja3MgZXhlY3V0aW5nIGEgZGVzaXJlZCBjaGFpbiBvZiBMU1BzLiBJZiBzdWl0YWJsZSBMYWJl bC9GRUMvbm9kZSByZWxhdGlvbiBpcyBrbm93biB0byB0aGUgUE1TLCB0aGF0IExTUCBjYW4gYmUg ZXhlY3V0ZWQgZnJvbSB0aGF0IG5vZGUNCiBvbiBieSBhIFBNUyBtb25pdG9yaW5nIHBhY2tldC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiVzYW0gLSBTbywgeW91IGFyZSBzYXlpbmcgdGhh dCB5b3Ugc3RpbGwgbmVlZCB0byBwZXJmb3JtIFJGQzQzNzkgdHJhY2Ugb3IgdHJlZXRyYWNlIHRv IGdldCB0b3BvbG9neS4gSSBkbyBub3QgdGhpbmsgSUdQIGV4dGVuc2lvbnMgYmVpbmcgcHJvcG9z ZWQgaW4gU1BSSU5HIGV4cG9ydCBhbnkgb2YgdGhlIGluZm8gb3RoZXIgdGhhbiBsYWJlbCBzdGFj ay4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QW5kIHRoZSBwcm9wb3NlZCBQTVMgc29sdXRp b24gKG5vdCB1c2UgY2FzZSkgaXMgdGhhdCwgaXQgcGVyZm9ybXMgb24gZGVtYW5kIHBlciBzZWdt ZW50LCB3aGljaCBQcm94eSBwaW5nIGFsc28gZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgdG9w b2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBjYXNlIHlvdSBhcmUgbWFraW5nIGlzIHRo YXQgbm8gbmVlZCBvZiBiZWxscyBhbmQgd2hpc3RsZXMgb2YgUkZDNDM3OS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPlF1ZXN0aW9uIEkgaGF2ZSBmb3Ig eW91IGlzLCBpZiBkYXRhIHBsYW5lIHBhY2tldHMgYXJlIGdldHRpbmcgZHJvcHBlZCBhbmQgUE1T IHBhY2tldHMgZ29pbmcgdGhyb3VnaCwgZm9yIGEgZ2l2ZW4gTFNQIG9yIFNlZ21lbnQsIGhvdyBk byB5b3Uga25vdyB0aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cgZG8geW91IGZp Z3VyZSBvdXQgd2hlcmUgaXQgaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkF0IGxlYXN0IHdpdGgg UkZDNDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIGJl Y2F1c2Ugb2YgdGhlIGJlbGxzIGFuZCB3aGlzdGxlcyBpdCBjYXJyaWVzIGFsb25nIHdpdGggdGhl IHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Ni4gSW4gc2VjIDMuMSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O3NuaXAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0RldGVybWluaW5nIGEgcGF0aCB0byBiZSBleGVjdXRlZCBwcmlvciB0byBhIG1lYXN1cmVt ZW50IG1heSBhbHNvIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rv bmUgYnkgc2V0dGluZyB1cCBhIGxhYmVsIGluY2x1ZGluZyBhbGwgbm9kZSBTSURzIGFsb25nIHRo YXQgcGF0aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoaWYgTEVSMSBo YXMgTm9kZSBTSUQgNDAgaW4gdGhlIGV4YW1wbGUgYW5kIGl0IHNob3VsZCBiZSBwYXNzZWQ8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmV0d2VlbiBMRVIgaSBhbmQgTEVS IGosIHRoZSBsYWJlbCBzdGFjayBpcyAyMCAtIDQwIC0gMzAgLSAxMCkuICZuYnNwO1RoZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZHZhbnRhZ2Ugb2YgdGhpcyBtZXRo b2QgaXMsIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIE9BTTxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmdW5jdGlvbmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVu dCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gJm5ic3A7VGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO21ldGhvZCBzdGlsbCBpcyBhYmxlIHRvIG1vbml0b3IgYWxsIGxp bmsgY29tYmluYXRpb25zIG9mIGFsbCBwYXRocyBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDthbiBNUExTIGRvbWFpbi4gJm5ic3A7SWYgY29ycmVjdCBmb3J3YXJkaW5n IGFsb25nIHRoZSBkZXNpcmVkIHBhdGhzIGhhcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtiZSBjaGVja2VkLCBSRkM0NzM5IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJl IGFwcGxpZWQgYWxzbyBpbiB0aGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2Nhc2UuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZs dDtlbmQgc25pcCZndDs8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SW4gdGhlIGFib3ZlIHlvdSBtZW50aW9uIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExT IE9BTS4gQnV0IGxhdGVyIHlvdSBzYXksPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JGQzQzNzkgZnVuY3Rpb25hbGl0eSBjb3VsZCBiZSB1c2VkLiBDb3VsZCB5b3UgY2xh cmlmeSBob3cgY291bGQgeW91IHZlcmlmeSBhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3BhdGgsIGlmIE1QTFMgdmFsaWRhdGlvbiBpcyBub3QgZG9uZS4gTW9yZSB0ZXh0 IHdpbGwgaGVscC4gQWxzbywgbW9yZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpbXBvcnRhbnRseSwgdGhlIHRleHQgZWFybGllciB0byB0aGUgYWJvdmUgc2F5cywgZm9y IHZhbGlkIHJlc3VsdCwgTVBMUzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtPQU0gaGFzIHRvIGJlIHBlcmZvcm1lZCBmb3IgdG9wb2xvZ3kgY2hhbmdlcyBldGMuIElmIHNv LCBpdCBjb250cmFkaWN0cyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPltSR10gVGhlIHRleHQgc2hvdWxk IHNheSB0aGF0PGJyPg0KLSB3aXRob3V0IE1QTFMgT0FNIGZ1bmN0aW9ucywgdGhlIFBNUyBleGVj dXRlcyBhIHNldCBvZiBwYXRocyBvbmx5IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRp b24uPGJyPg0KLSBpZiB0aGUgb3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBw bGFuZSBjb3JyZXNwb25kcyB0byBjb250cm9sIHBsYW5lLCBSRkM0NzM5IGZ1bmN0aW9ucyBzaG91 bGQgYmUgYXBwbGllZC48YnI+DQpJZiB5b3UgdW5kZXJzdGFuZCB0aGlzIHN0YXRlbWVudCBhbmQg dGhlIHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRlcyBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRy eSB0byByZXdvcmQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4lc2FtIC0gVGhlIHBy b2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1QTFMsIGZvciBPQU0sIHlvdSBo YXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkkgZGVmaW5pdGVs eSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVlbCBpcywgdGhl IHVzZSBjYXNlIGlzIHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZpc2lvbmVkIHNv bHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5PbmNlIHlvdSByZW1vdmUgc29sdXRpb24gb3Ig c3VnZ2VzdGVkIGVuaGFuY2VtZW50cywgaG9wZSBpdCBzaG91bGQgYmUgY2xlYXIgb24gd2hhdCBp cyBiZWluZyBzb2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMgZm9yIGEgc29s dXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVi bGlzaCBhIHNlcGFyYXRlIElELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs3LiBMYXN0IGJ1dCBub3QgdGhlIGxlYXN0LCBob3cgZGlmZmVyZW50 IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtTb21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBj b3VsZCBkbyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Tk1TL0VN UyBjb3VsZG4ndC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5bUkddIEkndmUgbmV2ZXIgaGVhcmQgb2YgYW4gRU1T L05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCB1c2VzIHRoaXMgdG9wb2xvZ3kg YXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0aW5nIExTUCBjb21i aW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVu IGNvbW1lcmNpYWxseSBhdmFpbGFibGUsDQogdGhlIGNvbXBhbnkgSSB3b3JrIGZvciB3b3VsZG4n dCBoYXZlIGJlZW4gZGV2ZWxvcGluZyBhIFBNUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei PiVzYW0gLSBUaGVyZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hpY2gg cGVyZm9ybXMgTVBMUyB0b3BvbG9neSBzcGVjaWZpYyBvcGVyYXRpb25zICZuYnNwO2ZvciBhIGdp dmVuIHNldCBvZiBMU1Ancy4gVGhleSBwZXJmb3JtIFRyZWV0cmFjZSBhbmQgcGVyZm9ybSBwaW5n IHdpdGggbXVsdGlwYXRoLiBBbHNvIHBlcmZvcm0gTFNQIHNwZWNpZmljIHZhbGlkYXRpb24NCiBi eSBjcmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJhY2UgYW5k IHBpbmcgd2l0aCBtdWx0aXBhdGguIFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0 aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcgcHJvYmUgdGVjaG5vbG9neS4gV2ls bCBub3Qgc2F5IGJleW9uZCB0aGF0IDpEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj5jaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+LXNhbTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABA84582F37nkgeml501mbschi_-- From nobody Mon Jul 14 21:11:28 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C9E1B27F9 for ; Mon, 14 Jul 2014 21:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsV5sXxeebLQ for ; Mon, 14 Jul 2014 21:11:16 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B1B1B280B for ; Mon, 14 Jul 2014 21:11:15 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so2027719pdj.28 for ; Mon, 14 Jul 2014 21:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dBfMdNRg697x3jSllcVGn4aqMzv/7YSEkcYEa3mEmKk=; b=jplfvADetP0BbzMIVzlqjrrOgyf90awOLhEK5hjtb0ls8+p3cDxxcPOalRtgT5Vehh 2YmZUPEtIC0EoyJblFO84pg1Ye26nv0aSmbOLwaQDRgvhnfDt4KKO+eIH54jjezVjsuJ 1/foH56NO8kns4EXfsVVnh0RWm+a6qbU7MOItfCdR7+QbbtNB0A3AC62xMOR61TbTe2h 2iwvVKP5pOGVKx2C3zaIM3JKdN6x1cHXgTjyx2O8tc0Avo79iydhw4Gy3lA0i2iarhoU z8hQfiEtnoTRi0Z+fUCsT00bkG1GhDtyQ3lIKwy4YF6ie4j4bsTDjMIW6GDSp1snYYlR F4VA== X-Received: by 10.68.69.7 with SMTP id a7mr9614396pbu.49.1405397475525; Mon, 14 Jul 2014 21:11:15 -0700 (PDT) Received: from [192.168.1.8] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id c17sm16699456pdm.33.2014.07.14.21.11.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 21:11:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A97A4D69-5528-4B79-BFA7-1DDF608B94F9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sam Aldrin In-Reply-To: Date: Mon, 14 Jul 2014 21:11:12 -0700 Message-Id: References: <43C21A33-ED76-4335-9568-62B5088E22ED@gmail.com> To: Qin Wu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/IVVgartu2v7WH6Q2PrizxXMXESk Cc: "Nobo Akiya \(nobo\)" , draft-geib-spring-oam-usecase , spring , "Ruediger.Geib@telekom.de" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 04:11:24 -0000 --Apple-Mail=_A97A4D69-5528-4B79-BFA7-1DDF608B94F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Qin, I do not want to hijack this thread to discuss solution as this is about = use case draft. Discussion should happen at the time of solution draft or respective = draft(read proxy lsp ping draft). As you sent the questions anyway, find my brief replies inline. -sam On Jul 14, 2014, at 7:46 PM, Qin Wu wrote: > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Sam Aldrin > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8814=E6=97=A5= 23:18 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu > =E6=8A=84=E9=80=81: Nobo Akiya (nobo); spring; = draft-geib-spring-oam-usecase; Ruediger.Geib@telekom.de > =E4=B8=BB=E9=A2=98: Re: [spring] Questions > =20 > =20 > On Jul 14, 2014, at 2:07 AM, Qin Wu wrote: >=20 >=20 > Very good point, since segment routing doesn=E2=80=99t require each = network node in the path to maintain state and only ingress node = maintains the state while > Proxy-lsp-ping require each network node in the return path to = maintain the state. > =20 > Wrong!=20 > No state is maintained except in the initiator. > =20 > [Qin]: I am a little bit confused when you say no state is maintained = in other network node. > Does Proxy-lsp-ping require the path to be setup before initiating = proxy LSP ping message? Yes, > How does the initiator know the upstream neighbor's upstream neighbor? whoever implements a solution based on the need should know how to form = a proxy request and where to get the info from. For example: Info could be gotten from tree trace of the topology OR = read from the IGP in the case of SR OR read from the dB of the topology = collected via various means :D > Section 2 of draft-ietf-mpls-proxy-lsp-ping-02 said: > =E2=80=9C > The initiator requests Proxy information so that it can learn = additional > information it needs to use to form a subsequent MPLS Proxy Ping > request.=E2=80=9D > How does proxy LSP have proxy information? Does it require path setup = in advance? There is no proxy LSP. Either case, the same answer as above applies. -sam > Please correct me if I am wrong. > =20 > -sam >=20 > Why apply Proxy-lsp-ping to spring OAM? > =20 > Regards! > -Qin > =E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Nobo Akiya (nobo) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5= 3:00 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de > =E6=8A=84=E9=80=81: spring; draft-geib-spring-oam-usecase > =E4=B8=BB=E9=A2=98: Re: [spring] Questions > =20 > Hi Sam, > =20 > Just to point out one thing about this document =E2=80=A6 > =20 > The test packet generated from a PMS/NMS/EMS/network-device can have = the complete segment stack on how to traverse the network as well as how = to come back to self without any further signaling, OAM state = maintenance on network nodes nor OAM involvement by network nodes. > =20 > That makes this approach quite different from using proxy LSP ping. > =20 > This certainly has some pros and cons but can be quite useful as one = of the OAMs (yes plural) used to monitor the network. > =20 > Thanks! > =20 > -Nobo > =20 > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Thursday, July 10, 2014 2:13 PM > To: Ruediger.Geib@telekom.de > Cc: spring; draft-geib-spring-oam-usecase > Subject: Re: [spring] Questions > =20 > Hi Ruediger, > =20 > Thanks for the quick response. Please find my responses inline. > =20 >=20 > On Thu, Jul 10, 2014 at 7:15 AM, wrote: > Hi Sam, >=20 > my replies are marked [RG] and added to your text. >=20 > - Proxy-lsp-ping is MPLS only, while the PMS architecture is intended = for every SR data plane (MPLS + IPv6). We'll clarify that in the draft. > - Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our = use case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6) >=20 > Based on that, it=C2=B9s a solution with broader scope and better fit = for SPRING as a whole.=20 > %sam - I believe you say it is use case document below. Then solution = is too premature at this point of time, as we haven't deliberated on the = requirements either.=20 >=20 > As you write, SR based OAM partially offers similar functions as = proxy-lsp. Without requiring the additional messages and LER/LSR = processing introduced by proxy-lsp.=20 >=20 > Regards, >=20 > Ruediger >=20 >=20 > Sam Aldrin wrote: >=20 > I have few questions about this draft. >=20 > 1. The title is confusing to me. It says OAM use case but in = section #1 > it says the following >=20 > > This document describes a solution to this problem statement = and > illustrates it with use-cases. >=20 > The solution is described for a single IGP MPLS domain. >=20 > The solution applies to monitoring of LDP LSP's as well as to > monitoring of Segment Routed LSP's. > >=20 > In fact the draft is describing a solution to certain scenarios = and not just > providing use cases/scenarios. My understanding was, use case = draft should > document scenarios where it will drive new requirements. = Solutions could > be covered with existing toolset or defined newly, depending on = the GAP > analysis. But that should be separate as there could be more = than 1 solution, > where as this document could just focus on use cases only. >=20 > If infact this is supposed to be a solution document, then = changing the title > would be more meaningful. That's my observation. >=20 > [RG] Thanks. It's a use case document. We'll review the text of = section 1. > %sam - OK. then I'd like to see any specific solution content removed, = that way we dont have to discuss what other solutions does either or = compare with :D > =20 >=20 > 2. w.r.t. Section number #2, the same problem is being solved = with > "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described = in this > section could be done with the proxy ping(solution wise) where, = request could > be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding > right? If not, how is it different here? >=20 > [RG] The PMS is able to set up packets which stay in data plane and = execute a desired > chain of MPLS LSPs. > %sam - Execute you mean traverse? or perform something else?=20 >=20 > [RG] Proxy-lsp says: This document defines protocol extensions to MPLS = ping [RFC4379] to > allow a third party to remotely cause an MPLS Echo Request message = to > be sent down a LSP or part of an LSP. > %sam - If it is proposing extensions, it has to be solution document = and cannot claim to be use case document. Also this document is on = information track. >=20 > [RG] I take it as saying that if you'd like to remotely execute = RFC4379 functionality on any LSP, you could either use the PMS or = proxy-ping. The PMS however simplifies and adds > functionality: > a) You don't need an additional protocol or functionality like = proxy-ping to check data > plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation. > %sam - RFC4379 performs validation of dataplane and also find out lot = more errors. You need additional information to perform validation = checks. For liveness detection, BFD is preferred tool, atleast in = present deployments.So are you saying, PMS solution is designed for = liveness detection and not to perform validation of data plane to = control plane, etc? (I think you agree to this in the later part of the = doc also) > =20 > b) once PMS detected data plane liveliness and correctness of MPLS = topology by RFC4379, > it can continue to execute arbitrary LSP combinations and the = monitoring packets stay > in data plane. Please point me to the text in proxy-ping offering = this feature. > %sam - This you could perform even without proxy ping. The function = you are describing is, how you use lsp ping rather than what lsp ping = does. Again I am not talking about non-mpls topology. > To answer your question, how you perform. > - Perform treetrace with rfc4379 to get topology info > - pick any arbitary LSP paths discovered along with its multipath = implementation. > - perform ping with right selectors for the path and use TTL for = limiting the hop [LER j]. > - if you want to perform from LER i to LER j as in your draft, use = proxy ping to start from LER i >=20 > 3. When the response is sent back to PMS which is not part of = MPLS or segment > domain, there is a serious security aspect, which needs to = considered. I believe > it applies to sending a request too. Will you be documenting = that aspect? >=20 > [RG] That's a valid point. The domain external system is one option = and the team will deal with the security aspects raised by this option = once we are in solution space. We will not analyse this in depth for a = use case document. > %sam - nod=20 >=20 > 4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping > with multpath + proxy ping. Could you kindly differentiate if = there is something > new the solution brings here? >=20 > [RG] The SR OAM author team has provided text how to monitor a bundled = link in the use case draft. You are a co-author of proxy-lsp. I couldn't = find explicit text on how to detect and monitor a bundled link in = draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a = bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them. > %sam - The same steps described above could be used if each bundled = link member is identified with a unique label. While performing tree = trace or ping with multipath, LER i will respond with DDMAP info for = each of the links and the multipath info for the same. > If you say that each link member has same label stack, then you could = use lsp selectors as defined in RFC4379, in this case it is local host = dest ip addr, to identify each link member. > Now if the MPLS forwarding layer sees the bundled link as one = interface but cannot discern its link members, then you could only = validate the interface and not its individual members. > Same applies in your case too. Cannot see how it is different. > =20 >=20 >=20 > 5. sec #5, Is the requirement here only for PMS to learn the = topology, in the > case of mixed env? >=20 > [RG] MPLS topology awareness is the precondition to set up packets = with label stacks executing a desired chain of LSPs. If suitable = Label/FEC/node relation is known to the PMS, that LSP can be executed = from that node on by a PMS monitoring packet. > %sam - So, you are saying that you still need to perform RFC4379 trace = or treetrace to get topology. I do not think IGP extensions being = proposed in SPRING export any of the info other than label stack.=20 > And the proposed PMS solution (not use case) is that, it performs on = demand per segment, which Proxy ping also does, albeit only for MPLS = topology. > The case you are making is that no need of bells and whistles of = RFC4379. > =20 > Question I have for you is, if data plane packets are getting dropped = and PMS packets going through, for a given LSP or Segment, how do you = know there is a problem? if you know, how do you figure out where it is? > At least with RFC4379 and/or proxy ping, you could validate each hop = because of the bells and whistles it carries along with the packet. > =20 >=20 >=20 > 6. In sec 3.1, > > Determining a path to be executed prior to a measurement may = also be > done by setting up a label including all node SIDs along that = path > (if LER1 has Node SID 40 in the example and it should be = passed > between LER i and LER j, the label stack is 20 - 40 - 30 - = 10). The > advantage of this method is, that it does not involve MPLS = OAM > functionality and it is independent of ECMP functionalities. = The > method still is able to monitor all link combinations of all = paths of > an MPLS domain. If correct forwarding along the desired = paths has to > be checked, RFC4739 functionality should be applied also in = this > case. >=20 > >=20 > In the above you mention that it does not involve MPLS OAM. = But later you say, > RFC4379 functionality could be used. Could you clarify how = could you verify a > path, if MPLS validation is not done. More text will help. = Also, more > importantly, the text earlier to the above says, for valid = result, MPLS > OAM has to be performed for topology changes etc. If so, it = contradicts here. >=20 > [RG] The text should say that > - without MPLS OAM functions, the PMS executes a set of paths only = based on control plane information. > - if the operator wants to make sure that data plane corresponds to = control plane, RFC4739 functions should be applied. > If you understand this statement and the text in the draft states = something different, I'll try to reword it. > %sam - The problem I am having is, in the case of MPLS, for OAM, you = have to validate the lsp. > I definitely see a specific need for SPRING, but what I feel is, the = use case is too much catered to a specific envisioned solution. > Once you remove solution or suggested enhancements, hope it should be = clear on what is being solved and scope out clear requirements for a = solution. > For solution part, please publish a separate ID. > =20 >=20 > 7. Last but not the least, how different is PMS from EMS and = NMS? > Somehow I couldn't find the difference what PMS could do and > NMS/EMS couldn't. >=20 > [RG] I've never heard of an EMS/NMS which is MPLS topology aware and = uses this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS. > %sam - There are tools which are part of NMS/OSS, which performs MPLS = topology specific operations for a given set of LSP's. They perform = Treetrace and perform ping with multipath. Also perform LSP specific = validation by crafting packets with data available with treetrace and = ping with multipath. You could automate the workflow without the need = for OSS/PMS, by using probe technology. Will not say beyond that :D > =20 > cheers > -sam > =20 --Apple-Mail=_A97A4D69-5528-4B79-BFA7-1DDF608B94F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Qin,

I do not want to hijack this = thread to discuss solution as this is about use case = draft.
Discussion should happen at the time of solution draft = or respective draft(read proxy lsp ping draft).
As you sent = the questions anyway, find my brief replies = inline.

-sam
On Jul 14, 2014, at = 7:46 PM, Qin Wu <bill.wu@huawei.com> = wrote:

 
=E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Sam Aldrin
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=88= 14=E6=97=A5 23:18
=E6=94=B6=E4= =BB=B6=E4=BA=BA: Qin = Wu
=E6=8A=84=E9=80=81: Nobo = Akiya (nobo); spring; draft-geib-spring-oam-usecase; Ruediger.Geib@telekom.de
=E4=B8=BB=E9=A2=98: Re: [spring] = Questions
 
 
On Jul 14, 2014, at 2:07 AM, Qin Wu <bill.wu@huawei.com> = wrote:


Very good = point, since segment routing doesn=E2=80=99t require each network node = in the path to maintain state and only ingress node maintains the state = while
Proxy-lsp-ping require each = network node in the return path to maintain the state.
 
Wrong! 
No state is maintained except = in the initiator.
 
[Qin]: I am a little bit confused when you say no = state is maintained in other network node.
Does = Proxy-lsp-ping require the path to be setup before initiating proxy LSP = ping = message?
Yes,
How does the = initiator know the upstream neighbor's upstream = neighbor?
whoever implements = a solution based on the need should know how to form a proxy request and = where to get the info from.
For example: Info could be gotten = from tree trace of the topology OR read from the IGP in the case of SR = OR read from the dB of the topology collected via various means = :D

Section 2 of  = draft-ietf-mpls-proxy-lsp-ping-02 said:
=E2=80=9C
The initiator requests Proxy information so that it can = learn additional
information it needs to use to form a subsequent MPLS = Proxy Ping
request.=E2=80=9D
How does  proxy LSP have = proxy information? Does it require path setup in = advance?
There is no proxy = LSP. Either case, the same answer as above = applies.

-sam
Please = correct me if I am wrong.
 
-sam

Why apply = Proxy-lsp-ping to spring OAM?
 
Regards!
-Qin
=E5=8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Nobo Akiya (nobo)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B47=E6=9C=8811=E6=97=A5 3:00
=E6=94=B6=E4=BB=B6=E4=BA=BA: Sam Aldrin; Ruediger.Geib@telekom.de
=E6=8A=84=E9=80=81: spring; = draft-geib-spring-oam-usecase
=E4=B8=BB=E9=A2=98: Re: [spring] = Questions
 
Hi = Sam,
 
Just to point out one thing about = this document =E2=80=A6
 
The test = packet generated from a PMS/NMS/EMS/network-device can have the complete = segment stack on how to traverse the network as well as how to come back = to self without any further signaling, OAM state maintenance on network = nodes nor OAM involvement by network nodes.
 
That makes this approach quite = different from using proxy LSP ping.
 
This certainly has some pros and = cons but can be quite useful as one of the OAMs (yes plural) used to = monitor the network.
 
Thanks!
 
-Nobo
 
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Sam = Aldrin
Sent: Thursday, July 10, 2014 = 2:13 PM
To: Ruediger.Geib@telekom.de
Cc: spring; = draft-geib-spring-oam-usecase
Subject: Re: [spring] = Questions
 
Hi = Ruediger,
 
Thanks for the quick response. Please find my = responses inline.

 

On Thu, = Jul 10, 2014 at 7:15 AM, <Ruediger.Geib@telekom.de> wrote:
Hi = Sam,

my replies are marked [RG] and added to your text.

- = Proxy-lsp-ping is MPLS only, while the PMS architecture is intended for = every SR data plane (MPLS + IPv6). We'll clarify that in the draft.
- = Proxy-lsp-ping is for MPLS LSP Ping (RFC 4379 / RFC 6424), while our use = case can use any OAM (in particular, specific good uses for BFD, and = ICMPv6)

Based on that, it=C2=B9s a solution with broader scope = and better fit for SPRING as a whole. 
%sam - I = believe you say it is use case document below. Then solution is too = premature at this point of time, as we haven't deliberated on the = requirements either. 

As you write, SR = based OAM partially offers similar functions as proxy-lsp. Without = requiring the additional messages and LER/LSR processing introduced by = proxy-lsp. 

Regards,

Ruediger



      Sam Aldrin = wrote:

      I have few questions about this = draft.

      1. The title is confusing to me. It = says OAM use case but in section #1
      it says the = following

      <snip>
    =    This document describes a solution to this problem = statement and
       illustrates it with = use-cases.

       The solution is described = for a single IGP MPLS domain.

       The = solution applies to monitoring of LDP LSP's as well as to
  =      monitoring of Segment Routed LSP's.
    =   <end snip>

       In fact the = draft is describing a solution to certain scenarios and not = just
       providing use cases/scenarios. My = understanding was, use case draft should
      =  document scenarios where it will drive new requirements. Solutions = could
       be covered with existing toolset or = defined newly, depending on the GAP
      =  analysis. But that should be separate as there could be more than = 1 solution,
       where as this document could = just focus on use cases only.

       If = infact this is supposed to be a solution document, then changing the = title
       would be more meaningful. That's my = observation.

[RG] = Thanks. It's a use case document. We'll review the text of section = 1.
%sam - OK. then I'd like to see any specific = solution content removed, that way we dont have to discuss what other = solutions does either or compare with :D
 


       2. w.r.t. Section number #2, the = same problem is being solved with
      =  "draft-ietf-mpls-proxy-lsp-ping-02" . What is being described in = this
       section could be done with the proxy = ping(solution wise) where, request could
      =  be sent to monitor LER i and LER j segment, from a PMS. Is my = understanding
       right? If not, how is it = different here?

[RG] = The PMS is able to set up packets which stay in data plane and execute a = desired
     chain of MPLS LSPs.
%sam - Execute you mean traverse? or perform = something else? 

[RG] Proxy-lsp = says: This document defines protocol extensions to MPLS ping [RFC4379] = to
   allow a third party to remotely cause an MPLS Echo = Request message to
   be sent down a LSP or part of an = LSP.
%sam - = If it is proposing extensions,  it has to be solution document =  and cannot claim to be use case document. Also this document is on = information track.

[RG] I take it as = saying that if you'd like to remotely execute RFC4379 functionality on = any LSP, you could either use the PMS or proxy-ping. The PMS however = simplifies and adds
functionality:
a) You don't need an additional = protocol or functionality like proxy-ping to check data
  =  plane liveliness, RFC4379 is fine. Deutsche Telekom operates a PMS = implementation.
%sam - RFC4379 performs validation of dataplane and = also find out lot more errors. You need additional information to = perform validation checks. For liveness detection, BFD is preferred = tool, atleast in present deployments.So are you saying, PMS solution is = designed for liveness detection and not to perform validation of data = plane to control plane, etc? (I think you agree to this in the later = part of the doc also)
 
b) once PMS detected = data plane liveliness and correctness of MPLS topology by = RFC4379,
   it can continue to execute arbitrary LSP = combinations and the monitoring packets stay
   in data = plane. Please point me to the text in proxy-ping offering this = feature.
%sam - This you could perform even without proxy = ping. The function you are describing is, how you use lsp ping rather = than what lsp ping does. Again I am not talking about non-mpls = topology.
To = answer your question, how you perform.
- = Perform treetrace with rfc4379 to get topology info
- pick = any arbitary LSP paths discovered along with its multipath = implementation.
- perform ping with right selectors for the path and = use TTL for limiting the hop [LER j].
- if you = want to perform from LER i to LER j as in your draft, use proxy ping to = start from LER i


        3. When the response is sent = back to PMS which is not part of MPLS or segment
      =   domain, there is a serious security aspect, which needs to = considered. I believe
        it applies to = sending a request too. Will you be documenting that aspect?

[RG] = That's a valid point. The domain external system is one option and the = team will deal with the security aspects raised by this option once we = are in solution space. We will not analyse this in depth for a use case = document.
%sam - nod 


    =     4. Sec 3.2 to monitor bundle links, one could perform that = with RFC4379 ping
        with multpath + proxy = ping. Could you kindly differentiate if there is something
  =       new the solution brings here?

[RG] The = SR OAM author team has provided text how to monitor a bundled link in = the use case draft. You are a co-author of proxy-lsp. I couldn't find = explicit text on how to detect and monitor a bundled link in = draft-proxy-lsp. Please describe how proxy-lsp can be used to monitor a = bundled link (sorry if this is obvious and I missed it). If there are = differences to the SR OAM approach, we'll discuss them.
%sam - The same steps described above could be used = if each bundled link member is identified with a unique label. While = performing tree trace or ping with multipath, LER i will respond with = DDMAP info for each of the links and the multipath info for the = same.
If you = say that each link member has same label stack, then you could use lsp = selectors as defined in RFC4379, in this case it is local host dest ip = addr, to identify each link member.
Now if = the MPLS forwarding layer sees the bundled link as one interface but = cannot discern its link members, then you could only validate the = interface and not its individual members.
Same = applies in your case too. Cannot see how it is different.
 



         5. sec #5, Is the = requirement here only for PMS to learn the topology, in the
  =           case of mixed env?

[RG] = MPLS topology awareness is the precondition to set up packets with label = stacks executing a desired chain of LSPs. If suitable Label/FEC/node = relation is known to the PMS, that LSP can be executed from that node on = by a PMS monitoring packet.
%sam - So, you are saying that you still need to = perform RFC4379 trace or treetrace to get topology. I do not think IGP = extensions being proposed in SPRING export any of the info other than = label stack. 
And the proposed PMS solution (not use case) is = that, it performs on demand per segment, which Proxy ping also does, = albeit only for MPLS topology.
The case = you are making is that no need of bells and whistles of = RFC4379.
 
Question I have for you is, if data plane packets = are getting dropped and PMS packets going through, for a given LSP or = Segment, how do you know there is a problem? if you know, how do you = figure out where it is?
At least with RFC4379 and/or proxy ping, you could = validate each hop because of the bells and whistles it carries along = with the packet.
 



    =      6. In sec 3.1,
        =  <snip>
         Determining a = path to be executed prior to a measurement may also be
    =      done by setting up a label including all node SIDs = along that path
         (if LER1 has Node = SID 40 in the example and it should be passed
      =    between LER i and LER j, the label stack is 20 - 40 - 30 - = 10).  The
         advantage of this = method is, that it does not involve MPLS OAM
      =    functionality and it is independent of ECMP = functionalities.  The
         method = still is able to monitor all link combinations of all paths of
  =        an MPLS domain.  If correct forwarding = along the desired paths has to
         be = checked, RFC4739 functionality should be applied also in this
  =        case.

        =  <end snip>

         In the = above you mention that it does not involve MPLS OAM. But later you = say,
         RFC4379 functionality could be = used. Could you clarify how could you verify a
      =    path, if MPLS validation is not done. More text will help. = Also, more
         importantly, the text = earlier to the above says, for valid result, MPLS
    =      OAM has to be performed for topology changes etc. If = so, it contradicts here.

[RG] The text should say that
- without MPLS OAM = functions, the PMS executes a set of paths only based on control plane = information.
- if the operator wants to make sure that data plane = corresponds to control plane, RFC4739 functions should be applied.
If = you understand this statement and the text in the draft states something = different, I'll try to reword it.
%sam - The problem I am having is, in the case of = MPLS, for OAM, you have to validate the lsp.
I = definitely see a specific need for SPRING, but what I feel is, the use = case is too much catered to a specific envisioned solution.
Once you = remove solution or suggested enhancements, hope it should be clear on = what is being solved and scope out clear requirements for a = solution.
For = solution part, please publish a separate ID.
 


         7. Last but not the least, = how different is PMS from EMS and NMS?
        =  Somehow I couldn't find the difference what PMS could do = and
         NMS/EMS couldn't.

[RG] = I've never heard of an EMS/NMS which is MPLS topology aware and uses = this topology awareness to create data plane packets executing LSP = combinations as desired by an operator. Had this feature been = commercially available, the company I work for wouldn't have been = developing a PMS.
%sam - There are tools which are part of NMS/OSS, = which performs MPLS topology specific operations  for a given set = of LSP's. They perform Treetrace and perform ping with multipath. Also = perform LSP specific validation by crafting packets with data available = with treetrace and ping with multipath. You could automate the workflow = without the need for OSS/PMS, by using probe technology. Will not say = beyond that :D
 
cheers
-sam
=
 

= --Apple-Mail=_A97A4D69-5528-4B79-BFA7-1DDF608B94F9-- From nobody Mon Jul 14 21:25:00 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BCF1A02FA for ; Mon, 14 Jul 2014 21:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8XQqFZjr1gh for ; Mon, 14 Jul 2014 21:24: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 C1D751A02A5 for ; Mon, 14 Jul 2014 21:24:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHE76338; Tue, 15 Jul 2014 04:24:54 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Jul 2014 05:24:53 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 15 Jul 2014 12:24:47 +0800 From: Qin Wu To: Sam Aldrin Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7JhndME/roR0Kh13/N0Tpo0QAT5ZsQAA/kkXD//77CAIAADOQA//naTZCADDD5AP/+u3BQgAIcuQD//3ZocA== Date: Tue, 15 Jul 2014 04:24:46 +0000 Message-ID: References: <43C21A33-ED76-4335-9568-62B5088E22ED@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84582FB0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Anfj3IUdChanTBbkfMNQmSlzX1c Cc: "Nobo Akiya \(nobo\)" , draft-geib-spring-oam-usecase , spring , "Ruediger.Geib@telekom.de" Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 04:24:58 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84582FB0nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VjdGlvbiAyIG9mICBkcmFmdC1pZXRmLW1wbHMtcHJveHktbHNwLXBpbmctMDIgc2FpZDoNCuKA nA0KVGhlIGluaXRpYXRvciByZXF1ZXN0cyBQcm94eSBpbmZvcm1hdGlvbiBzbyB0aGF0IGl0IGNh biBsZWFybiBhZGRpdGlvbmFsDQppbmZvcm1hdGlvbiBpdCBuZWVkcyB0byB1c2UgdG8gZm9ybSBh IHN1YnNlcXVlbnQgTVBMUyBQcm94eSBQaW5nDQpyZXF1ZXN0LuKAnQ0KSG93IGRvZXMgIHByb3h5 IExTUCBoYXZlIHByb3h5IGluZm9ybWF0aW9uPyBEb2VzIGl0IHJlcXVpcmUgcGF0aCBzZXR1cCBp biBhZHZhbmNlPw0KVGhlcmUgaXMgbm8gcHJveHkgTFNQLiBFaXRoZXIgY2FzZSwgdGhlIHNhbWUg YW5zd2VyIGFzIGFib3ZlIGFwcGxpZXMuDQoNCltRaW5dOmEgVHlwbywgaXQgc2hvdWxkIHByb3h5 IExTUi4NCg0K --_000_B8F9A780D330094D99AF023C5877DABA84582FB0nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9u IDIgb2YmbmJzcDsgZHJhZnQtaWV0Zi1tcGxzLXByb3h5LWxzcC1waW5nLTAyIHNhaWQ6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlRoZSBpbml0aWF0b3IgcmVxdWVzdHMgUHJveHkgaW5mb3JtYXRpb24g c28gdGhhdCBpdCBjYW4gbGVhcm4gYWRkaXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbmZv cm1hdGlvbiBpdCBuZWVkcyB0byB1c2UgdG8gZm9ybSBhIHN1YnNlcXVlbnQgTVBMUyBQcm94eSBQ aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlcXVlc3QuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCdPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhvdyBkb2VzJm5ic3A7IHByb3h5IExTUCBoYXZlIHByb3h5IGluZm9ybWF0 aW9uPyBEb2VzIGl0IHJlcXVpcmUgcGF0aCBzZXR1cCBpbiBhZHZhbmNlPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGlzIG5vIHBy b3h5IExTUC4gRWl0aGVyIGNhc2UsIHRoZSBzYW1lIGFuc3dlciBhcyBhYm92ZSBhcHBsaWVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bUWluXTphIFR5cG8sIGl0IHNob3Vs ZCBwcm94eSBMU1IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABA84582FB0nkgeml501mbschi_-- From nobody Tue Jul 15 15:16:35 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEF01A010A for ; Tue, 15 Jul 2014 15:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWDY5CsRigaj for ; Tue, 15 Jul 2014 15:16:19 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A241A00B9 for ; Tue, 15 Jul 2014 15:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21988; q=dns/txt; s=iport; t=1405462580; x=1406672180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IU5KkOrHYTJ0G/V5NDtMF/UWzxontA3Ntd0v4bKei54=; b=Fq9/HdY/qHTBgSgvl8RKm7Qzu/qhAT1ij05786B+7HOUKt3yCOHrZv49 7oxFCVnnSzlP1cSi+J/0sZiGDP+dhZSGRQ/i7D10v0TBMUgA+90yoydaI Iu/3J92ILii0xTL+OMIP3sjqJ1F8wUHvfxy8bwuWW+WDgCRsQzrfinKbC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPymxVOtJA2F/2dsb2JhbABPCoJqJFJXBIJyvnuHSgEZeRZ1hAMBAQEDASMRMwsHDAQCAQYCDgMBAwEBAQICBh0DAgICMBQBAgYIAgQBDQUIE4gfCAGWBZwomBgXgSyNQysGEBsHAgICgnE2gRYBBJZ9hWaSWoNEbIEFJBw X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="61073254" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 15 Jul 2014 22:16:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6FMGG34021218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 22:16:16 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 17:16:16 -0500 From: "Nobo Akiya (nobo)" To: Qin Wu , Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLwAKzC+wAABEV34AAhjLYAAB1QKfA= Date: Tue, 15 Jul 2014 22:16:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/zU5wIkBJEdTzH6dEOjQYIY6vR6c Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 22:16:22 -0000 SGkgUWluLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFpbiBXdSBb bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0 IDExOjExIFBNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgU2FtIEFsZHJpbjsgUnVlZGlnZXIu R2VpYkB0ZWxla29tLmRlDQo+IENjOiBzcHJpbmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2Vj YXNlDQo+IFN1YmplY3Q6IFJFOiBbc3ByaW5nXSBRdWVzdGlvbnMNCj4gDQo+IEhpLCBOb2JvOg0K PiBJIGFncmVlIHRoZSBhc3BlY3RzIHRoYXQgYXJlIG1pc3NpbmcgaW4gZHJhZnQtZ2VpYi1zcHJp bmctb2FtLXVzZWNhc2UuDQo+IFNwcmluZyBwcm9ibGVtIHN0YXRlbWVudCBzYXlzIHRoZSBTUFJJ TkcgYXJjaGl0ZWN0dXJlIHdpbGwgYWRkcmVzcyB1c2UNCj4gY2FzZXMgd2hlcmUgcmVtb3ZhbCBv ZiBzaWduYWxpbmcgYW5kIHBhdGggc3RhdGUgaW4NCj4gwqDCoCB0aGUgY29yZSBpcyBhIHJlcXVp cmVtZW50Lg0KDQpZZXMsIGFuZCBhZGRpdGlvbmFsIHN0YXRlcyBiZWluZyByZXF1aXJlZCBmb3Ig T0FNIHB1cnBvc2Ugc2hvdWxkIGJlIG1pbmltaXplZCB3aGVyZSBwb3NzaWJsZSwgSU1PLg0KDQo+ IA0KPiBOb3cgeW91IHNhaWQgZWFjaCBuZXR3b3JrIG5vZGUgc3RpbGwgaGFzIHN0YXRlcyByZWxh dGVkIHRvIHZhcmlvdXMgc2VnbWVudA0KPiB0eXBlcy4NCj4gQXJlIHlvdSBzYXlpbmcgTm9uLVNS IG5vZGUgaW4gdGhlIFNSIGRvbWFpbiBzaG91bGQgbm90IG1haW50YWluIGFueSBwYXRoDQo+IHN0 YXRlIG9yIHNlZ21lbnQgcm91dGluZyByZWxhdGVkIHN0YXRlIGJ1dCBTUiBlbmFibGVkIG5vZGUN Cj4gSW4gdGhlIFNSIGRvbWFpbiBNVVNUIGhhdmUgc2VnbWVudCByb3V0aW5nIHJlbGF0ZWQgc3Rh dGU/IExldCBtZSBrbm93IGlmDQo+IG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdD8NCg0KV2hh dCBJIG1lYW50IHdhcyB0aGF0IGEgbm9kZSBpbiBhbiBTUiBkb21haW4gbmVlZHMgdG8gbWFpbnRh aW46DQotIGxvY2FsIHNlZ21lbnRzIGFuZCByZW1vdGUgc2VnbWVudCBpbiBpdHMgY29udHJvbCBw bGFuZS4NCi0gbG9jYWwgc2VnbWVudHMgYW5kIHN1YnNldCBvZiByZW1vdGUgc2VnbWVudHMgaW4g aXRzIGRhdGEgcGxhbmUuDQoNCkFuZCB0aGUgT0FNIG11c3QgbWFrZSBzdXJlIHRob3NlIHN0YXRl cyBhcmUgY29ycmVjdCBpbiByZWxldmFudCBub2RlcyBpbiBvcmRlciB0byBhbGxvdyBwYWNrZXQg c3RlZXJpbmcgdG8gZnVuY3Rpb24gcHJvcGVybHkuDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KPiAN Cj4gUmVnYXJkcyENCj4gLVFpbg0KPiDlj5Hku7bkuro6IE5vYm8gQWtpeWEgKG5vYm8pIFttYWls dG86bm9ib0BjaXNjby5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxNOW5tDfmnIgxNOaXpSAyMDoz OQ0KPiDmlLbku7bkuro6IFFpbiBXdTsgU2FtIEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0ZWxla29t LmRlDQo+IOaKhOmAgTogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KPiDk uLvpopg6IFJFOiBbc3ByaW5nXSBRdWVzdGlvbnMNCj4gDQo+IEhpIFFpbiwgZXQgYWwsDQo+IA0K PiBFYWNoIG5ldHdvcmsgbm9kZSB3aWxsIHN0aWxsIGhhdmUgc29tZSBzdGF0ZXMgKGkuZS4gbm9k ZS9hZGphY2VuY3kvc2VydmljZQ0KPiBzZWdtZW50cykuDQo+IA0KPiBJIHNlZSB0aGUgdGVjaG5p cXVlIGRlc2NyaWJlZCBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZSBhcyBhIHdheSB0bw0K PiBtb25pdG9yIHRoZSBuZXR3b3JrLCBidXQgbm90IGEgd2F5IHRvIHZhbGlkYXRlIHRoZSBzZWdt ZW50cy4gSW4gcGFydGljdWxhcg0KPiB0aGUgZm9sbG93aW5nIGFzcGVjdHMgY2Fubm90IGJlIHZh bGlkYXRlZCBieSB0aGUgdGVjaG5pcXVlIGRlc2NyaWJlZCBkcmFmdC0NCj4gZ2VpYi1zcHJpbmct b2FtLXVzZWNhc2UuDQo+IA0KPiAxLiBVc2luZyBhIHNlZ21lbnQgb3IgY29tYmluYXRpb24gb2Yg c2VnbWVudHMgcmVzdWx0IGluIGEgcGFja2V0IHRvIHJlYWNoIGFuDQo+IGV4cGVjdGVkIG5ldHdv cmsgbm9kZS4NCj4gMi4gVXNpbmcgYW4gYWRqYWNlbmN5IHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBh Y2tldCB0byB0cmF2ZXJzZSBvdmVyIGFuDQo+IGV4cGVjdGVkIGFkamFjZW5jeS4NCj4gMy4gVXNp bmcgYSBzZXJ2aWNlIHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byBoaXQgYW4gZXhwZWN0 ZWQgc2VydmljZS4NCj4gDQo+IFRoaXMgaXMgd2h5IEkgcHJldmlvdXNseSBtZW50aW9uZWQgdGhh dCB0aGUgdGVjaG5pcXVlIGlzIHVzZWZ1bCBhcyBvbmUgb2YgdGhlDQo+IE9BTXMgdXNlZCB0byBt b25pdG9yIHRoZSBuZXR3b3JrLg0KPiANCj4gSW4gb3RoZXIgd29yZHMsIHdlIHdvdWxkIHN0aWxs IHdhbnQgdGhpbmdzIGluIGFkZGl0aW9uIHRvIHZhbGlkYXRlIHRoZSBzdGF0ZXMNCj4gb24gZWFj aCBuZXR3b3JrIG5vZGUgc28gdGhhdCwgd2hlbiBpbmdyZXNzZXMgc3RlZXIgcGFja2V0cyB1c2lu Zw0KPiBjb21iaW5hdGlvbnMgc2VnbWVudHMgKHRoYXQgbWFrZXMgdXNlIG9mIHRob3NlIHN0YXRl cyksIHRoZW4gZXhwZWN0ZWQgYW5kDQo+IGFjdHVhbCBwYXRocyBhbGlnbnMuDQo+IA0KPiBJIGlu dGVudGlvbmFsbHkgZGlkbuKAmXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24gb24gdGhlIHVzZWZ1bG5l c3Mgb2YgUHJveHkgTFNQDQo+IFBpbmcgbiBTZWdtZW50IFJvdXRpbmcsIGJ1dCBJIHdhbnRlZCB0 byBoaWdobGlnaHQgd2hhdCBhcmUgdGhlIGFkZGl0aW9uYWwNCj4gcG9pbnRzIHdlIHdvdWxkIHdh bnQgdG8gY292ZXIgZnJvbSBPQU0gcGVyc3BlY3RpdmUuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAt Tm9ibw0KPiANCj4gRnJvbTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KPiBT ZW50OiBNb25kYXksIEp1bHkgMTQsIDIwMTQgNTowOCBBTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9i byk7IFNhbSBBbGRyaW47IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZQ0KPiBDYzogc3ByaW5nOyBk cmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KPiBTdWJqZWN0OiBSRTogW3NwcmluZ10gUXVl c3Rpb25zDQo+IA0KPiBWZXJ5IGdvb2QgcG9pbnQsIHNpbmNlIHNlZ21lbnQgcm91dGluZyBkb2Vz buKAmXQgcmVxdWlyZSBlYWNoIG5ldHdvcmsgbm9kZQ0KPiBpbiB0aGUgcGF0aCB0byBtYWludGFp biBzdGF0ZSBhbmQgb25seSBpbmdyZXNzIG5vZGUgbWFpbnRhaW5zIHRoZSBzdGF0ZQ0KPiB3aGls ZQ0KPiBQcm94eS1sc3AtcGluZyByZXF1aXJlIGVhY2ggbmV0d29yayBub2RlIGluIHRoZSByZXR1 cm4gcGF0aCB0byBtYWludGFpbg0KPiB0aGUgc3RhdGUuDQo+IFdoeSBhcHBseSBQcm94eS1sc3At cGluZyB0byBzcHJpbmcgT0FNPw0KPiANCj4gUmVnYXJkcyENCj4gLVFpbg0KPiDlj5Hku7bkuro6 IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggTm9ibyBBa2l5 YSAobm9ibykNCj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0N+aciDEx5pelIDM6MDANCj4g5pS25Lu2 5Lq6OiBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4g5oqE6YCBOiBzcHJp bmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQo+IOS4u+mimDogUmU6IFtzcHJpbmdd IFF1ZXN0aW9ucw0KPiANCj4gSGkgU2FtLA0KPiANCj4gSnVzdCB0byBwb2ludCBvdXQgb25lIHRo aW5nIGFib3V0IHRoaXMgZG9jdW1lbnQg4oCmDQo+IA0KPiBUaGUgdGVzdCBwYWNrZXQgZ2VuZXJh dGVkIGZyb20gYSBQTVMvTk1TL0VNUy9uZXR3b3JrLWRldmljZSBjYW4gaGF2ZQ0KPiB0aGUgY29t cGxldGUgc2VnbWVudCBzdGFjayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdvcmsgYXMgd2Vs bCBhcyBob3cNCj4gdG8gY29tZSBiYWNrIHRvIHNlbGYgd2l0aG91dCBhbnkgZnVydGhlciBzaWdu YWxpbmcsIE9BTSBzdGF0ZSBtYWludGVuYW5jZQ0KPiBvbiBuZXR3b3JrIG5vZGVzIG5vciBPQU0g aW52b2x2ZW1lbnQgYnkgbmV0d29yayBub2Rlcy4NCj4gDQo+IFRoYXQgbWFrZXMgdGhpcyBhcHBy b2FjaCBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB1c2luZyBwcm94eSBMU1AgcGluZy4NCj4gDQo+IFRo aXMgY2VydGFpbmx5IGhhcyBzb21lIHByb3MgYW5kIGNvbnMgYnV0IGNhbiBiZSBxdWl0ZSB1c2Vm dWwgYXMgb25lIG9mIHRoZQ0KPiBPQU1zICh5ZXMgcGx1cmFsKSB1c2VkIHRvIG1vbml0b3IgdGhl IG5ldHdvcmsuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAtTm9ibw0KPiANCj4gRnJvbTogc3ByaW5n IFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW0gQWxkcmlu DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDEwLCAyMDE0IDI6MTMgUE0NCj4gVG86IFJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZQ0KPiBDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNl Y2FzZQ0KPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQo+IA0KPiBIaSBSdWVkaWdl ciwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBQbGVhc2UgZmluZCBteSBy ZXNwb25zZXMgaW5saW5lLg0KPiANCj4gT24gVGh1LCBKdWwgMTAsIDIwMTQgYXQgNzoxNSBBTSwg PFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4gd3JvdGU6DQo+IEhpIFNhbSwNCj4gDQo+IG15IHJl cGxpZXMgYXJlIG1hcmtlZCBbUkddIGFuZCBhZGRlZCB0byB5b3VyIHRleHQuDQo+IA0KPiAtIFBy b3h5LWxzcC1waW5nIGlzIE1QTFMgb25seSwgd2hpbGUgdGhlIFBNUyBhcmNoaXRlY3R1cmUgaXMg aW50ZW5kZWQgZm9yDQo+IGV2ZXJ5IFNSIGRhdGEgcGxhbmUgKE1QTFMgKyBJUHY2KS4gV2UnbGwg Y2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC4NCj4gLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBM UyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMgNjQyNCksIHdoaWxlIG91ciB1c2UNCj4gY2FzZSBj YW4gdXNlIGFueSBPQU0gKGluIHBhcnRpY3VsYXIsIHNwZWNpZmljIGdvb2QgdXNlcyBmb3IgQkZE LCBhbmQgSUNNUHY2KQ0KPiANCj4gQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBzb2x1dGlvbiB3aXRo IGJyb2FkZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yIFNQUklORyBhcw0KPiBhIHdob2xlLg0K PiAlc2FtIC0gSSBiZWxpZXZlIHlvdSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cu IFRoZW4gc29sdXRpb24gaXMgdG9vDQo+IHByZW1hdHVyZSBhdCB0aGlzIHBvaW50IG9mIHRpbWUs IGFzIHdlIGhhdmVuJ3QgZGVsaWJlcmF0ZWQgb24gdGhlDQo+IHJlcXVpcmVtZW50cyBlaXRoZXIu DQo+IA0KPiBBcyB5b3Ugd3JpdGUsIFNSIGJhc2VkIE9BTSBwYXJ0aWFsbHkgb2ZmZXJzIHNpbWls YXIgZnVuY3Rpb25zIGFzIHByb3h5LWxzcC4NCj4gV2l0aG91dCByZXF1aXJpbmcgdGhlIGFkZGl0 aW9uYWwgbWVzc2FnZXMgYW5kIExFUi9MU1IgcHJvY2Vzc2luZw0KPiBpbnRyb2R1Y2VkIGJ5IHBy b3h5LWxzcC4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBSdWVkaWdlcg0KPiANCj4gDQo+IMKgIMKg IMKgIFNhbSBBbGRyaW4gd3JvdGU6DQo+IA0KPiDCoCDCoCDCoCBJIGhhdmUgZmV3IHF1ZXN0aW9u cyBhYm91dCB0aGlzIGRyYWZ0Lg0KPiANCj4gwqAgwqAgwqAgMS4gVGhlIHRpdGxlIGlzIGNvbmZ1 c2luZyB0byBtZS4gSXQgc2F5cyBPQU0gdXNlIGNhc2UgYnV0IGluIHNlY3Rpb24gIzENCj4gwqAg wqAgwqAgaXQgc2F5cyB0aGUgZm9sbG93aW5nDQo+IA0KPiDCoCDCoCDCoCA8c25pcD4NCj4gwqAg wqAgwqAgwqBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxl bSBzdGF0ZW1lbnQgYW5kDQo+IMKgIMKgIMKgIMKgaWxsdXN0cmF0ZXMgaXQgd2l0aCB1c2UtY2Fz ZXMuDQo+IA0KPiDCoCDCoCDCoCDCoFRoZSBzb2x1dGlvbiBpcyBkZXNjcmliZWQgZm9yIGEgc2lu Z2xlIElHUCBNUExTIGRvbWFpbi4NCj4gDQo+IMKgIMKgIMKgIMKgVGhlIHNvbHV0aW9uIGFwcGxp ZXMgdG8gbW9uaXRvcmluZyBvZiBMRFAgTFNQJ3MgYXMgd2VsbCBhcyB0bw0KPiDCoCDCoCDCoCDC oG1vbml0b3Jpbmcgb2YgU2VnbWVudCBSb3V0ZWQgTFNQJ3MuDQo+IMKgIMKgIMKgIDxlbmQgc25p cD4NCj4gDQo+IMKgIMKgIMKgIMKgSW4gZmFjdCB0aGUgZHJhZnQgaXMgZGVzY3JpYmluZyBhIHNv bHV0aW9uIHRvIGNlcnRhaW4gc2NlbmFyaW9zIGFuZCBub3QganVzdA0KPiDCoCDCoCDCoCDCoHBy b3ZpZGluZyB1c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNh c2UgZHJhZnQNCj4gc2hvdWxkDQo+IMKgIMKgIMKgIMKgZG9jdW1lbnQgc2NlbmFyaW9zIHdoZXJl IGl0IHdpbGwgZHJpdmUgbmV3IHJlcXVpcmVtZW50cy4gU29sdXRpb25zDQo+IGNvdWxkDQo+IMKg IMKgIMKgIMKgYmUgY292ZXJlZCB3aXRoIGV4aXN0aW5nIHRvb2xzZXQgb3IgZGVmaW5lZCBuZXds eSwgZGVwZW5kaW5nIG9uIHRoZQ0KPiBHQVANCj4gwqAgwqAgwqAgwqBhbmFseXNpcy4gQnV0IHRo YXQgc2hvdWxkIGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxkIGJlIG1vcmUgdGhhbiAxDQo+IHNv bHV0aW9uLA0KPiDCoCDCoCDCoCDCoHdoZXJlIGFzIHRoaXMgZG9jdW1lbnQgY291bGQganVzdCBm b2N1cyBvbiB1c2UgY2FzZXMgb25seS4NCj4gDQo+IMKgIMKgIMKgIMKgSWYgaW5mYWN0IHRoaXMg aXMgc3VwcG9zZWQgdG8gYmUgYSBzb2x1dGlvbiBkb2N1bWVudCwgdGhlbiBjaGFuZ2luZyB0aGUN Cj4gdGl0bGUNCj4gwqAgwqAgwqAgwqB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBt eSBvYnNlcnZhdGlvbi4NCj4gW1JHXSBUaGFua3MuIEl0J3MgYSB1c2UgY2FzZSBkb2N1bWVudC4g V2UnbGwgcmV2aWV3IHRoZSB0ZXh0IG9mIHNlY3Rpb24gMS4NCj4gJXNhbSAtIE9LLiB0aGVuIEkn ZCBsaWtlIHRvIHNlZSBhbnkgc3BlY2lmaWMgc29sdXRpb24gY29udGVudCByZW1vdmVkLCB0aGF0 DQo+IHdheSB3ZSBkb250IGhhdmUgdG8gZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2Vz IGVpdGhlciBvciBjb21wYXJlDQo+IHdpdGggOkQNCj4gDQo+IA0KPiDCoCDCoCDCoCDCoDIuIHcu ci50LiBTZWN0aW9uIG51bWJlciAjMiwgdGhlIHNhbWUgcHJvYmxlbSBpcyBiZWluZyBzb2x2ZWQg d2l0aA0KPiDCoCDCoCDCoCDCoCJkcmFmdC1pZXRmLW1wbHMtcHJveHktbHNwLXBpbmctMDIiIC4g V2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaW4gdGhpcw0KPiDCoCDCoCDCoCDCoHNlY3Rpb24gY291 bGQgYmUgZG9uZSB3aXRoIHRoZSBwcm94eSBwaW5nKHNvbHV0aW9uIHdpc2UpIHdoZXJlLA0KPiBy ZXF1ZXN0IGNvdWxkDQo+IMKgIMKgIMKgIMKgYmUgc2VudCB0byBtb25pdG9yIExFUiBpIGFuZCBM RVIgaiBzZWdtZW50LCBmcm9tIGEgUE1TLiBJcyBteQ0KPiB1bmRlcnN0YW5kaW5nDQo+IMKgIMKg IMKgIMKgcmlnaHQ/IElmIG5vdCwgaG93IGlzIGl0IGRpZmZlcmVudCBoZXJlPw0KPiBbUkddIFRo ZSBQTVMgaXMgYWJsZSB0byBzZXQgdXAgcGFja2V0cyB3aGljaCBzdGF5IGluIGRhdGEgcGxhbmUg YW5kIGV4ZWN1dGUNCj4gYSBkZXNpcmVkDQo+IMKgIMKgIMKgY2hhaW4gb2YgTVBMUyBMU1BzLg0K PiAlc2FtIC0gRXhlY3V0ZSB5b3UgbWVhbiB0cmF2ZXJzZT8gb3IgcGVyZm9ybSBzb21ldGhpbmcg ZWxzZT8NCj4gDQo+IFtSR10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBw cm90b2NvbCBleHRlbnNpb25zIHRvIE1QTFMNCj4gcGluZyBbUkZDNDM3OV0gdG8NCj4gwqAgwqBh bGxvdyBhIHRoaXJkIHBhcnR5IHRvIHJlbW90ZWx5IGNhdXNlIGFuIE1QTFMgRWNobyBSZXF1ZXN0 IG1lc3NhZ2UgdG8NCj4gwqAgwqBiZSBzZW50IGRvd24gYSBMU1Agb3IgcGFydCBvZiBhbiBMU1Au DQo+ICVzYW0gLSBJZiBpdCBpcyBwcm9wb3NpbmcgZXh0ZW5zaW9ucywgwqBpdCBoYXMgdG8gYmUg c29sdXRpb24gZG9jdW1lbnQgwqBhbmQNCj4gY2Fubm90IGNsYWltIHRvIGJlIHVzZSBjYXNlIGRv Y3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24gaW5mb3JtYXRpb24NCj4gdHJhY2suDQo+ IA0KPiBbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5b3UnZCBsaWtlIHRvIHJlbW90 ZWx5IGV4ZWN1dGUgUkZDNDM3OQ0KPiBmdW5jdGlvbmFsaXR5IG9uIGFueSBMU1AsIHlvdSBjb3Vs ZCBlaXRoZXIgdXNlIHRoZSBQTVMgb3IgcHJveHktcGluZy4gVGhlDQo+IFBNUyBob3dldmVyIHNp bXBsaWZpZXMgYW5kIGFkZHMNCj4gZnVuY3Rpb25hbGl0eToNCj4gYSkgWW91IGRvbid0IG5lZWQg YW4gYWRkaXRpb25hbCBwcm90b2NvbCBvciBmdW5jdGlvbmFsaXR5IGxpa2UgcHJveHktcGluZyB0 bw0KPiBjaGVjayBkYXRhDQo+IMKgIMKgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3OSBpcyBmaW5l LiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TDQo+IGltcGxlbWVudGF0aW9uLg0KPiAl c2FtIC0gUkZDNDM3OSBwZXJmb3JtcyB2YWxpZGF0aW9uIG9mIGRhdGFwbGFuZSBhbmQgYWxzbyBm aW5kIG91dCBsb3QgbW9yZQ0KPiBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGNoZWNrcy4gRm9yDQo+IGxpdmVuZXNzIGRldGVjdGlv biwgQkZEIGlzIHByZWZlcnJlZCB0b29sLCBhdGxlYXN0IGluIHByZXNlbnQgZGVwbG95bWVudHMu U28NCj4gYXJlIHlvdSBzYXlpbmcsIFBNUyBzb2x1dGlvbiBpcyBkZXNpZ25lZCBmb3IgbGl2ZW5l c3MgZGV0ZWN0aW9uIGFuZCBub3QgdG8NCj4gcGVyZm9ybSB2YWxpZGF0aW9uIG9mIGRhdGEgcGxh bmUgdG8gY29udHJvbCBwbGFuZSwgZXRjPyAoSSB0aGluayB5b3UgYWdyZWUgdG8NCj4gdGhpcyBp biB0aGUgbGF0ZXIgcGFydCBvZiB0aGUgZG9jIGFsc28pDQo+IA0KPiBiKSBvbmNlIFBNUyBkZXRl Y3RlZCBkYXRhIHBsYW5lIGxpdmVsaW5lc3MgYW5kIGNvcnJlY3RuZXNzIG9mIE1QTFMNCj4gdG9w b2xvZ3kgYnkgUkZDNDM3OSwNCj4gwqAgwqBpdCBjYW4gY29udGludWUgdG8gZXhlY3V0ZSBhcmJp dHJhcnkgTFNQIGNvbWJpbmF0aW9ucyBhbmQgdGhlIG1vbml0b3JpbmcNCj4gcGFja2V0cyBzdGF5 DQo+IMKgIMKgaW4gZGF0YSBwbGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0ZXh0IGluIHBy b3h5LXBpbmcgb2ZmZXJpbmcgdGhpcw0KPiBmZWF0dXJlLg0KPiAlc2FtIC0gVGhpcyB5b3UgY291 bGQgcGVyZm9ybSBldmVuIHdpdGhvdXQgcHJveHkgcGluZy4gVGhlIGZ1bmN0aW9uIHlvdQ0KPiBh cmUgZGVzY3JpYmluZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBs c3AgcGluZyBkb2VzLiBBZ2Fpbg0KPiBJIGFtIG5vdCB0YWxraW5nIGFib3V0IG5vbi1tcGxzIHRv cG9sb2d5Lg0KPiBUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgaG93IHlvdSBwZXJmb3JtLg0KPiAt IFBlcmZvcm0gdHJlZXRyYWNlIHdpdGggcmZjNDM3OSB0byBnZXQgdG9wb2xvZ3kgaW5mbw0KPiAt IHBpY2sgYW55IGFyYml0YXJ5IExTUCBwYXRocyBkaXNjb3ZlcmVkIGFsb25nIHdpdGggaXRzIG11 bHRpcGF0aA0KPiBpbXBsZW1lbnRhdGlvbi4NCj4gLSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBz ZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvciBsaW1pdGluZyB0aGUNCj4gaG9w IFtMRVIgal0uDQo+IC0gaWYgeW91IHdhbnQgdG8gcGVyZm9ybSBmcm9tIExFUiBpIHRvIExFUiBq IGFzIGluIHlvdXIgZHJhZnQsIHVzZSBwcm94eSBwaW5nIHRvDQo+IHN0YXJ0IGZyb20gTEVSIGkN Cj4gDQo+IMKgIMKgIMKgIMKgIDMuIFdoZW4gdGhlIHJlc3BvbnNlIGlzIHNlbnQgYmFjayB0byBQ TVMgd2hpY2ggaXMgbm90IHBhcnQgb2YgTVBMUyBvcg0KPiBzZWdtZW50DQo+IMKgIMKgIMKgIMKg IGRvbWFpbiwgdGhlcmUgaXMgYSBzZXJpb3VzIHNlY3VyaXR5IGFzcGVjdCwgd2hpY2ggbmVlZHMg dG8gY29uc2lkZXJlZC4gSQ0KPiBiZWxpZXZlDQo+IMKgIMKgIMKgIMKgIGl0IGFwcGxpZXMgdG8g c2VuZGluZyBhIHJlcXVlc3QgdG9vLiBXaWxsIHlvdSBiZSBkb2N1bWVudGluZyB0aGF0DQo+IGFz cGVjdD8NCj4gW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4gVGhlIGRvbWFpbiBleHRlcm5hbCBz eXN0ZW0gaXMgb25lIG9wdGlvbiBhbmQgdGhlDQo+IHRlYW0gd2lsbCBkZWFsIHdpdGggdGhlIHNl Y3VyaXR5IGFzcGVjdHMgcmFpc2VkIGJ5IHRoaXMgb3B0aW9uIG9uY2Ugd2UgYXJlIGluDQo+IHNv bHV0aW9uIHNwYWNlLiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9yIGEgdXNl IGNhc2UgZG9jdW1lbnQuDQo+ICVzYW0gLSBub2QNCj4gDQo+IMKgIMKgIMKgIMKgIDQuIFNlYyAz LjIgdG8gbW9uaXRvciBidW5kbGUgbGlua3MsIG9uZSBjb3VsZCBwZXJmb3JtIHRoYXQgd2l0aCBS RkM0Mzc5DQo+IHBpbmcNCj4gwqAgwqAgwqAgwqAgd2l0aCBtdWx0cGF0aCArIHByb3h5IHBpbmcu IENvdWxkIHlvdSBraW5kbHkgZGlmZmVyZW50aWF0ZSBpZiB0aGVyZSBpcw0KPiBzb21ldGhpbmcN Cj4gwqAgwqAgwqAgwqAgbmV3IHRoZSBzb2x1dGlvbiBicmluZ3MgaGVyZT8NCj4gW1JHXSBUaGUg U1IgT0FNIGF1dGhvciB0ZWFtIGhhcyBwcm92aWRlZCB0ZXh0IGhvdyB0byBtb25pdG9yIGEgYnVu ZGxlZA0KPiBsaW5rIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBv ZiBwcm94eS1sc3AuIEkgY291bGRuJ3QgZmluZA0KPiBleHBsaWNpdCB0ZXh0IG9uIGhvdyB0byBk ZXRlY3QgYW5kIG1vbml0b3IgYSBidW5kbGVkIGxpbmsgaW4gZHJhZnQtcHJveHktbHNwLg0KPiBQ bGVhc2UgZGVzY3JpYmUgaG93IHByb3h5LWxzcCBjYW4gYmUgdXNlZCB0byBtb25pdG9yIGEgYnVu ZGxlZCBsaW5rIChzb3JyeQ0KPiBpZiB0aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4g SWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIHRvIHRoZSBTUiBPQU0NCj4gYXBwcm9hY2gsIHdlJ2xs IGRpc2N1c3MgdGhlbS4NCj4gJXNhbSAtIFRoZSBzYW1lIHN0ZXBzIGRlc2NyaWJlZCBhYm92ZSBj b3VsZCBiZSB1c2VkIGlmIGVhY2ggYnVuZGxlZCBsaW5rDQo+IG1lbWJlciBpcyBpZGVudGlmaWVk IHdpdGggYSB1bmlxdWUgbGFiZWwuIFdoaWxlIHBlcmZvcm1pbmcgdHJlZSB0cmFjZSBvcg0KPiBw aW5nIHdpdGggbXVsdGlwYXRoLCBMRVIgaSB3aWxsIHJlc3BvbmQgd2l0aCBERE1BUCBpbmZvIGZv ciBlYWNoIG9mIHRoZQ0KPiBsaW5rcyBhbmQgdGhlIG11bHRpcGF0aCBpbmZvIGZvciB0aGUgc2Ft ZS4NCj4gSWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUgbGFiZWwgc3Rh Y2ssIHRoZW4geW91IGNvdWxkIHVzZQ0KPiBsc3Agc2VsZWN0b3JzIGFzIGRlZmluZWQgaW4gUkZD NDM3OSwgaW4gdGhpcyBjYXNlIGl0IGlzIGxvY2FsIGhvc3QgZGVzdCBpcCBhZGRyLA0KPiB0byBp ZGVudGlmeSBlYWNoIGxpbmsgbWVtYmVyLg0KPiBOb3cgaWYgdGhlIE1QTFMgZm9yd2FyZGluZyBs YXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lIGludGVyZmFjZSBidXQNCj4gY2Fubm90 IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSB2YWxpZGF0ZSB0 aGUgaW50ZXJmYWNlDQo+IGFuZCBub3QgaXRzIGluZGl2aWR1YWwgbWVtYmVycy4NCj4gU2FtZSBh cHBsaWVzIGluIHlvdXIgY2FzZSB0b28uIENhbm5vdCBzZWUgaG93IGl0IGlzIGRpZmZlcmVudC4N Cj4gDQo+IA0KPiANCj4gwqAgwqAgwqAgwqAgwqA1LiBzZWMgIzUsIElzIHRoZSByZXF1aXJlbWVu dCBoZXJlIG9ubHkgZm9yIFBNUyB0byBsZWFybiB0aGUgdG9wb2xvZ3ksIGluDQo+IHRoZQ0KPiDC oCDCoCDCoCDCoCDCoCDCoCBjYXNlIG9mIG1peGVkIGVudj8NCj4gW1JHXSBNUExTIHRvcG9sb2d5 IGF3YXJlbmVzcyBpcyB0aGUgcHJlY29uZGl0aW9uIHRvIHNldCB1cCBwYWNrZXRzIHdpdGgNCj4g bGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQcy4gSWYgc3VpdGFi bGUgTGFiZWwvRkVDL25vZGUNCj4gcmVsYXRpb24gaXMga25vd24gdG8gdGhlIFBNUywgdGhhdCBM U1AgY2FuIGJlIGV4ZWN1dGVkIGZyb20gdGhhdCBub2RlIG9uIGJ5DQo+IGEgUE1TIG1vbml0b3Jp bmcgcGFja2V0Lg0KPiAlc2FtIC0gU28sIHlvdSBhcmUgc2F5aW5nIHRoYXQgeW91IHN0aWxsIG5l ZWQgdG8gcGVyZm9ybSBSRkM0Mzc5IHRyYWNlIG9yDQo+IHRyZWV0cmFjZSB0byBnZXQgdG9wb2xv Z3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIHByb3Bvc2VkIGluDQo+IFNQ UklORyBleHBvcnQgYW55IG9mIHRoZSBpbmZvIG90aGVyIHRoYW4gbGFiZWwgc3RhY2suDQo+IEFu ZCB0aGUgcHJvcG9zZWQgUE1TIHNvbHV0aW9uIChub3QgdXNlIGNhc2UpIGlzIHRoYXQsIGl0IHBl cmZvcm1zIG9uDQo+IGRlbWFuZCBwZXIgc2VnbWVudCwgd2hpY2ggUHJveHkgcGluZyBhbHNvIGRv ZXMsIGFsYmVpdCBvbmx5IGZvciBNUExTDQo+IHRvcG9sb2d5Lg0KPiBUaGUgY2FzZSB5b3UgYXJl IG1ha2luZyBpcyB0aGF0IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9mIFJGQzQzNzku DQo+IA0KPiBRdWVzdGlvbiBJIGhhdmUgZm9yIHlvdSBpcywgaWYgZGF0YSBwbGFuZSBwYWNrZXRz IGFyZSBnZXR0aW5nIGRyb3BwZWQgYW5kDQo+IFBNUyBwYWNrZXRzIGdvaW5nIHRocm91Z2gsIGZv ciBhIGdpdmVuIExTUCBvciBTZWdtZW50LCBob3cgZG8geW91IGtub3cNCj4gdGhlcmUgaXMgYSBw cm9ibGVtPyBpZiB5b3Uga25vdywgaG93IGRvIHlvdSBmaWd1cmUgb3V0IHdoZXJlIGl0IGlzPw0K PiBBdCBsZWFzdCB3aXRoIFJGQzQzNzkgYW5kL29yIHByb3h5IHBpbmcsIHlvdSBjb3VsZCB2YWxp ZGF0ZSBlYWNoIGhvcA0KPiBiZWNhdXNlIG9mIHRoZSBiZWxscyBhbmQgd2hpc3RsZXMgaXQgY2Fy cmllcyBhbG9uZyB3aXRoIHRoZSBwYWNrZXQuDQo+IA0KPiANCj4gDQo+IMKgIMKgIMKgIMKgIMKg Ni4gSW4gc2VjIDMuMSwNCj4gwqAgwqAgwqAgwqAgwqA8c25pcD4NCj4gwqAgwqAgwqAgwqAgwqBE ZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8gYSBtZWFzdXJlbWVudCBt YXkgYWxzbyBiZQ0KPiDCoCDCoCDCoCDCoCDCoGRvbmUgYnkgc2V0dGluZyB1cCBhIGxhYmVsIGlu Y2x1ZGluZyBhbGwgbm9kZSBTSURzIGFsb25nIHRoYXQgcGF0aA0KPiDCoCDCoCDCoCDCoCDCoChp ZiBMRVIxIGhhcyBOb2RlIFNJRCA0MCBpbiB0aGUgZXhhbXBsZSBhbmQgaXQgc2hvdWxkIGJlIHBh c3NlZA0KPiDCoCDCoCDCoCDCoCDCoGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLCB0aGUgbGFiZWwg c3RhY2sgaXMgMjAgLSA0MCAtIDMwIC0gMTApLiDCoFRoZQ0KPiDCoCDCoCDCoCDCoCDCoGFkdmFu dGFnZSBvZiB0aGlzIG1ldGhvZCBpcywgdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FN DQo+IMKgIMKgIMKgIMKgIMKgZnVuY3Rpb25hbGl0eSBhbmQgaXQgaXMgaW5kZXBlbmRlbnQgb2Yg RUNNUCBmdW5jdGlvbmFsaXRpZXMuIMKgVGhlDQo+IMKgIMKgIMKgIMKgIMKgbWV0aG9kIHN0aWxs IGlzIGFibGUgdG8gbW9uaXRvciBhbGwgbGluayBjb21iaW5hdGlvbnMgb2YgYWxsIHBhdGhzIG9m DQo+IMKgIMKgIMKgIMKgIMKgYW4gTVBMUyBkb21haW4uIMKgSWYgY29ycmVjdCBmb3J3YXJkaW5n IGFsb25nIHRoZSBkZXNpcmVkIHBhdGhzIGhhcyB0bw0KPiDCoCDCoCDCoCDCoCDCoGJlIGNoZWNr ZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBhbHNvIGluIHRoaXMN Cj4gwqAgwqAgwqAgwqAgwqBjYXNlLg0KPiANCj4gwqAgwqAgwqAgwqAgwqA8ZW5kIHNuaXA+DQo+ IA0KPiDCoCDCoCDCoCDCoCDCoEluIHRoZSBhYm92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMg bm90IGludm9sdmUgTVBMUyBPQU0uIEJ1dCBsYXRlcg0KPiB5b3Ugc2F5LA0KPiDCoCDCoCDCoCDC oCDCoFJGQzQzNzkgZnVuY3Rpb25hbGl0eSBjb3VsZCBiZSB1c2VkLiBDb3VsZCB5b3UgY2xhcmlm eSBob3cgY291bGQgeW91DQo+IHZlcmlmeSBhDQo+IMKgIMKgIMKgIMKgIMKgcGF0aCwgaWYgTVBM UyB2YWxpZGF0aW9uIGlzIG5vdCBkb25lLiBNb3JlIHRleHQgd2lsbCBoZWxwLiBBbHNvLCBtb3Jl DQo+IMKgIMKgIMKgIMKgIMKgaW1wb3J0YW50bHksIHRoZSB0ZXh0IGVhcmxpZXIgdG8gdGhlIGFi b3ZlIHNheXMsIGZvciB2YWxpZCByZXN1bHQsIE1QTFMNCj4gwqAgwqAgwqAgwqAgwqBPQU0gaGFz IHRvIGJlIHBlcmZvcm1lZCBmb3IgdG9wb2xvZ3kgY2hhbmdlcyBldGMuIElmIHNvLCBpdCBjb250 cmFkaWN0cw0KPiBoZXJlLg0KPiBbUkddIFRoZSB0ZXh0IHNob3VsZCBzYXkgdGhhdA0KPiAtIHdp dGhvdXQgTVBMUyBPQU0gZnVuY3Rpb25zLCB0aGUgUE1TIGV4ZWN1dGVzIGEgc2V0IG9mIHBhdGhz IG9ubHkgYmFzZWQNCj4gb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCj4gLSBpZiB0aGUg b3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBwbGFuZSBjb3JyZXNwb25kcyB0 byBjb250cm9sDQo+IHBsYW5lLCBSRkM0NzM5IGZ1bmN0aW9ucyBzaG91bGQgYmUgYXBwbGllZC4N Cj4gSWYgeW91IHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQgYW5kIHRoZSB0ZXh0IGluIHRoZSBk cmFmdCBzdGF0ZXMgc29tZXRoaW5nDQo+IGRpZmZlcmVudCwgSSdsbCB0cnkgdG8gcmV3b3JkIGl0 Lg0KPiAlc2FtIC0gVGhlIHByb2JsZW0gSSBhbSBoYXZpbmcgaXMsIGluIHRoZSBjYXNlIG9mIE1Q TFMsIGZvciBPQU0sIHlvdSBoYXZlDQo+IHRvIHZhbGlkYXRlIHRoZSBsc3AuDQo+IEkgZGVmaW5p dGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVlbCBpcywg dGhlIHVzZSBjYXNlIGlzDQo+IHRvbyBtdWNoIGNhdGVyZWQgdG8gYSBzcGVjaWZpYyBlbnZpc2lv bmVkIHNvbHV0aW9uLg0KPiBPbmNlIHlvdSByZW1vdmUgc29sdXRpb24gb3Igc3VnZ2VzdGVkIGVu aGFuY2VtZW50cywgaG9wZSBpdCBzaG91bGQgYmUNCj4gY2xlYXIgb24gd2hhdCBpcyBiZWluZyBz b2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMgZm9yIGENCj4gc29sdXRpb24u DQo+IEZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVibGlzaCBhIHNlcGFyYXRlIElELg0KPiAN Cj4gDQo+IMKgIMKgIMKgIMKgIMKgNy4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwgaG93IGRpZmZl cmVudCBpcyBQTVMgZnJvbSBFTVMgYW5kIE5NUz8NCj4gwqAgwqAgwqAgwqAgwqBTb21laG93IEkg Y291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBhbmQNCj4gwqAg wqAgwqAgwqAgwqBOTVMvRU1TIGNvdWxkbid0Lg0KPiBbUkddIEkndmUgbmV2ZXIgaGVhcmQgb2Yg YW4gRU1TL05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZA0KPiB1c2VzIHRoaXMg dG9wb2xvZ3kgYXdhcmVuZXNzIHRvIGNyZWF0ZSBkYXRhIHBsYW5lIHBhY2tldHMgZXhlY3V0aW5n IExTUA0KPiBjb21iaW5hdGlvbnMgYXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMg ZmVhdHVyZSBiZWVuIGNvbW1lcmNpYWxseQ0KPiBhdmFpbGFibGUsIHRoZSBjb21wYW55IEkgd29y ayBmb3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQo+ICVzYW0gLSBUaGVy ZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hpY2ggcGVyZm9ybXMgTVBM Uw0KPiB0b3BvbG9neSBzcGVjaWZpYyBvcGVyYXRpb25zIMKgZm9yIGEgZ2l2ZW4gc2V0IG9mIExT UCdzLiBUaGV5IHBlcmZvcm0gVHJlZXRyYWNlDQo+IGFuZCBwZXJmb3JtIHBpbmcgd2l0aCBtdWx0 aXBhdGguIEFsc28gcGVyZm9ybSBMU1Agc3BlY2lmaWMgdmFsaWRhdGlvbiBieQ0KPiBjcmFmdGlu ZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJhY2UgYW5kIHBpbmcgd2l0 aCBtdWx0aXBhdGguDQo+IFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0 aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcNCj4gcHJvYmUgdGVjaG5vbG9neS4gV2lsbCBu b3Qgc2F5IGJleW9uZCB0aGF0IDpEDQo+IA0KPiBjaGVlcnMNCj4gLXNhbQ0KPiANCg0K From nobody Tue Jul 15 15:25:44 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB01A0AA0 for ; Tue, 15 Jul 2014 15:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_48=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98U5i-XoZJaA for ; Tue, 15 Jul 2014 15:25:39 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDBF1A011D for ; Tue, 15 Jul 2014 15:25:39 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-c7-53c5555c6f52 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BE.A7.25146.C5555C35; Tue, 15 Jul 2014 18:22:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 15 Jul 2014 18:25:31 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Qin Wu , "Sam Aldrin" , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J7jN0xU3VU02zGXJ+32rA7gAT5ZsQAA/kkXAAEP2oAAABnHcAALR9hQAAB2IRAAAecB0AACgDNYAACE+qYA== Date: Tue, 15 Jul 2014 22:25:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7ED884@eusaamb103.ericsson.se> References: 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+NgFmpjkeLIzCtJLcpLzFFi42KZXLonQTcm9GiwwaRdehYTWr8wWjyeu4DV YsWad+wWszviLT5M47A4fuE3owObx5TfG1k9ds66y+7RcuQtq8eSJT+ZPNpeKnh8ufyZLYAt issmJTUnsyy1SN8ugSuj/0MnU8GpnYwV/65fYW5gfLGFsYuRk0NCwERi/bNNzBC2mMSFe+vZ uhi5OIQEjjJKNO/ezwrhLGeUuDbtNBtIFZuAkcSLjT3sIAkRgWWMEh+eT2EBSTAL5Eg8et8K NlZYQF6it+UqE4gtIqAgce5GO5SdJbH27E52EJtFQFXi7dZ+oKEcHLwCvhIHX5mChIUEmlgk djeAlXAChef13Qbbywh03fdTa5ggVolL3HoynwniagGJJXvOQ30gKvHy8T9WCFtRYl//dHaQ 8cwCmhLrd+lDtCpKTOl+CDaeV0BQ4uTMJywTGMVmIZk6C6FjFpKOWUg6FjCyrGLkKC1OLctN NzLcxAiMuGMSbI47GBd8sjzEKMDBqMTD+8D4aLAQa2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhi71e4qNl5Unr3psLWdxj2Txt81ufaqN0X3pB0VWfr1hdti +T7BKVsqN0pLrTJ7uvSh6OZqsd/3PVU3C0+zKlhrX54l9XTf+ymLHqyNMHebVGf/+HTzHo65 /0IeX/+1neWu5IuYxIsf/u2fW32yg7919r9eh5qiHbsWfFlkuOcXU4ZA2/W1zDJzlFiKMxIN tZiLihMBnPYLf5kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/spring/hfTi9T3xYQCsVry79BH7MVawdhI Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 22:25:42 -0000 SGkgTm9ibywgZXQuIGFsLA0KYWxsb3cgbWUgdG8gb2ZmZXIgbXkgJC4wMi4NCg0KIiBXaGF0IEkg bWVhbnQgd2FzIHRoYXQgYSBub2RlIGluIGFuIFNSIGRvbWFpbiBuZWVkcyB0byBtYWludGFpbjoN Ci0gbG9jYWwgc2VnbWVudHMgYW5kIHJlbW90ZSBzZWdtZW50IGluIGl0cyBjb250cm9sIHBsYW5l Lg0KLSBsb2NhbCBzZWdtZW50cyBhbmQgc3Vic2V0IG9mIHJlbW90ZSBzZWdtZW50cyBpbiBpdHMg ZGF0YSBwbGFuZS4NCg0KQW5kIHRoZSBPQU0gbXVzdCBtYWtlIHN1cmUgdGhvc2Ugc3RhdGVzIGFy ZSBjb3JyZWN0IGluIHJlbGV2YW50IG5vZGVzIGluIG9yZGVyIHRvIGFsbG93IHBhY2tldCBzdGVl cmluZyB0byBmdW5jdGlvbiBwcm9wZXJseS4iDQoNCkkgdGhpbmsgdGhhdCBPQU0gbXVzdCBiZSBh YmxlIHRvIGRldGVjdCBkZWZlY3QsIGluIHRoaXMgY2FzZSBpbmNvbnNpc3RlbmN5IGJldHdlZW4g Y29udHJvbC9tYW5hZ2VtZW50IHBsYW5lIGFuZCBkYXRhIHBsYW5lLCBhbmQgbG9jYWxpemUgaXQu IEVuc3VyaW5nIHRoYXQgY29udHJvbC9tYW5hZ2VtZW50IHBsYW5lIGlzIGluIHN5bmMsIGluIHN0 YWJsZSBzdGF0ZSwgd2l0aCB0aGUgZGF0YSBwbGFuZSwgSU1PIGlzIHJlc3BvbnNpYmlsaXR5IG9m IE8mTS4gKE9BTSBhbmQgTyZNIGJlaW5nIHVzZWQgYWNjb3JkaW5nIHRvIFJGQyA2MjkxKS4NCg0K CVJlZ2FyZHMsDQoJCUdyZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNw cmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9ibyBB a2l5YSAobm9ibykNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMTUsIDIwMTQgMzoxNiBQTQ0KVG86IFFp biBXdTsgU2FtIEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlDQpDYzogc3ByaW5nOyBk cmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KU3ViamVjdDogUmU6IFtzcHJpbmddIFF1ZXN0 aW9ucw0KDQpIaSBRaW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog UWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEp1bHkg MTQsIDIwMTQgMTE6MTEgUE0NCj4gVG86IE5vYm8gQWtpeWEgKG5vYm8pOyBTYW0gQWxkcmluOyBS dWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4gQ2M6IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmct b2FtLXVzZWNhc2UNCj4gU3ViamVjdDogUkU6IFtzcHJpbmddIFF1ZXN0aW9ucw0KPiANCj4gSGks IE5vYm86DQo+IEkgYWdyZWUgdGhlIGFzcGVjdHMgdGhhdCBhcmUgbWlzc2luZyBpbiBkcmFmdC1n ZWliLXNwcmluZy1vYW0tdXNlY2FzZS4NCj4gU3ByaW5nIHByb2JsZW0gc3RhdGVtZW50IHNheXMg dGhlIFNQUklORyBhcmNoaXRlY3R1cmUgd2lsbCBhZGRyZXNzIHVzZSANCj4gY2FzZXMgd2hlcmUg cmVtb3ZhbCBvZiBzaWduYWxpbmcgYW5kIHBhdGggc3RhdGUgaW4NCj4gwqDCoCB0aGUgY29yZSBp cyBhIHJlcXVpcmVtZW50Lg0KDQpZZXMsIGFuZCBhZGRpdGlvbmFsIHN0YXRlcyBiZWluZyByZXF1 aXJlZCBmb3IgT0FNIHB1cnBvc2Ugc2hvdWxkIGJlIG1pbmltaXplZCB3aGVyZSBwb3NzaWJsZSwg SU1PLg0KDQo+IA0KPiBOb3cgeW91IHNhaWQgZWFjaCBuZXR3b3JrIG5vZGUgc3RpbGwgaGFzIHN0 YXRlcyByZWxhdGVkIHRvIHZhcmlvdXMgDQo+IHNlZ21lbnQgdHlwZXMuDQo+IEFyZSB5b3Ugc2F5 aW5nIE5vbi1TUiBub2RlIGluIHRoZSBTUiBkb21haW4gc2hvdWxkIG5vdCBtYWludGFpbiBhbnkg DQo+IHBhdGggc3RhdGUgb3Igc2VnbWVudCByb3V0aW5nIHJlbGF0ZWQgc3RhdGUgYnV0IFNSIGVu YWJsZWQgbm9kZSBJbiB0aGUgDQo+IFNSIGRvbWFpbiBNVVNUIGhhdmUgc2VnbWVudCByb3V0aW5n IHJlbGF0ZWQgc3RhdGU/IExldCBtZSBrbm93IGlmIG15IA0KPiB1bmRlcnN0YW5kaW5nIGlzIGNv cnJlY3Q/DQoNCldoYXQgSSBtZWFudCB3YXMgdGhhdCBhIG5vZGUgaW4gYW4gU1IgZG9tYWluIG5l ZWRzIHRvIG1haW50YWluOg0KLSBsb2NhbCBzZWdtZW50cyBhbmQgcmVtb3RlIHNlZ21lbnQgaW4g aXRzIGNvbnRyb2wgcGxhbmUuDQotIGxvY2FsIHNlZ21lbnRzIGFuZCBzdWJzZXQgb2YgcmVtb3Rl IHNlZ21lbnRzIGluIGl0cyBkYXRhIHBsYW5lLg0KDQpBbmQgdGhlIE9BTSBtdXN0IG1ha2Ugc3Vy ZSB0aG9zZSBzdGF0ZXMgYXJlIGNvcnJlY3QgaW4gcmVsZXZhbnQgbm9kZXMgaW4gb3JkZXIgdG8g YWxsb3cgcGFja2V0IHN0ZWVyaW5nIHRvIGZ1bmN0aW9uIHByb3Blcmx5Lg0KDQpUaGFua3MhDQoN Ci1Ob2JvDQoNCj4gDQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4g5Y+R5Lu25Lq6OiBOb2JvIEFraXlh IChub2JvKSBbbWFpbHRvOm5vYm9AY2lzY28uY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTTlubQ3 5pyIMTTml6UgMjA6MzkNCj4g5pS25Lu25Lq6OiBRaW4gV3U7IFNhbSBBbGRyaW47IFJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZQ0KPiDmioTpgIE6IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2Ft LXVzZWNhc2UNCj4g5Li76aKYOiBSRTogW3NwcmluZ10gUXVlc3Rpb25zDQo+IA0KPiBIaSBRaW4s IGV0IGFsLA0KPiANCj4gRWFjaCBuZXR3b3JrIG5vZGUgd2lsbCBzdGlsbCBoYXZlIHNvbWUgc3Rh dGVzIChpLmUuIA0KPiBub2RlL2FkamFjZW5jeS9zZXJ2aWNlIHNlZ21lbnRzKS4NCj4gDQo+IEkg c2VlIHRoZSB0ZWNobmlxdWUgZGVzY3JpYmVkIGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNl IGFzIGEgd2F5IA0KPiB0byBtb25pdG9yIHRoZSBuZXR3b3JrLCBidXQgbm90IGEgd2F5IHRvIHZh bGlkYXRlIHRoZSBzZWdtZW50cy4gSW4gDQo+IHBhcnRpY3VsYXIgdGhlIGZvbGxvd2luZyBhc3Bl Y3RzIGNhbm5vdCBiZSB2YWxpZGF0ZWQgYnkgdGhlIHRlY2huaXF1ZSANCj4gZGVzY3JpYmVkIGRy YWZ0LSBnZWliLXNwcmluZy1vYW0tdXNlY2FzZS4NCj4gDQo+IDEuIFVzaW5nIGEgc2VnbWVudCBv ciBjb21iaW5hdGlvbiBvZiBzZWdtZW50cyByZXN1bHQgaW4gYSBwYWNrZXQgdG8gDQo+IHJlYWNo IGFuIGV4cGVjdGVkIG5ldHdvcmsgbm9kZS4NCj4gMi4gVXNpbmcgYW4gYWRqYWNlbmN5IHNlZ21l bnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byB0cmF2ZXJzZSBvdmVyIGFuIA0KPiBleHBlY3RlZCBh ZGphY2VuY3kuDQo+IDMuIFVzaW5nIGEgc2VydmljZSBzZWdtZW50IHJlc3VsdHMgaW4gYSBwYWNr ZXQgdG8gaGl0IGFuIGV4cGVjdGVkIHNlcnZpY2UuDQo+IA0KPiBUaGlzIGlzIHdoeSBJIHByZXZp b3VzbHkgbWVudGlvbmVkIHRoYXQgdGhlIHRlY2huaXF1ZSBpcyB1c2VmdWwgYXMgb25lIA0KPiBv ZiB0aGUgT0FNcyB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQo+IA0KPiBJbiBvdGhlciB3 b3Jkcywgd2Ugd291bGQgc3RpbGwgd2FudCB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdmFsaWRhdGUg dGhlIA0KPiBzdGF0ZXMgb24gZWFjaCBuZXR3b3JrIG5vZGUgc28gdGhhdCwgd2hlbiBpbmdyZXNz ZXMgc3RlZXIgcGFja2V0cyANCj4gdXNpbmcgY29tYmluYXRpb25zIHNlZ21lbnRzICh0aGF0IG1h a2VzIHVzZSBvZiB0aG9zZSBzdGF0ZXMpLCB0aGVuIA0KPiBleHBlY3RlZCBhbmQgYWN0dWFsIHBh dGhzIGFsaWducy4NCj4gDQo+IEkgaW50ZW50aW9uYWxseSBkaWRu4oCZdCBhbnN3ZXIgeW91ciBx dWVzdGlvbiBvbiB0aGUgdXNlZnVsbmVzcyBvZiBQcm94eSANCj4gTFNQIFBpbmcgbiBTZWdtZW50 IFJvdXRpbmcsIGJ1dCBJIHdhbnRlZCB0byBoaWdobGlnaHQgd2hhdCBhcmUgdGhlIA0KPiBhZGRp dGlvbmFsIHBvaW50cyB3ZSB3b3VsZCB3YW50IHRvIGNvdmVyIGZyb20gT0FNIHBlcnNwZWN0aXZl Lg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLU5vYm8NCj4gDQo+IEZyb206IFFpbiBXdSBbbWFpbHRv OmJpbGwud3VAaHVhd2VpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdWx5IDE0LCAyMDE0IDU6MDgg QU0NCj4gVG86IE5vYm8gQWtpeWEgKG5vYm8pOyBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRl bGVrb20uZGUNCj4gQ2M6IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNCj4g U3ViamVjdDogUkU6IFtzcHJpbmddIFF1ZXN0aW9ucw0KPiANCj4gVmVyeSBnb29kIHBvaW50LCBz aW5jZSBzZWdtZW50IHJvdXRpbmcgZG9lc27igJl0IHJlcXVpcmUgZWFjaCBuZXR3b3JrIA0KPiBu b2RlIGluIHRoZSBwYXRoIHRvIG1haW50YWluIHN0YXRlIGFuZCBvbmx5IGluZ3Jlc3Mgbm9kZSBt YWludGFpbnMgdGhlIA0KPiBzdGF0ZSB3aGlsZSBQcm94eS1sc3AtcGluZyByZXF1aXJlIGVhY2gg bmV0d29yayBub2RlIGluIHRoZSByZXR1cm4gDQo+IHBhdGggdG8gbWFpbnRhaW4gdGhlIHN0YXRl Lg0KPiBXaHkgYXBwbHkgUHJveHktbHNwLXBpbmcgdG8gc3ByaW5nIE9BTT8NCj4gDQo+IFJlZ2Fy ZHMhDQo+IC1RaW4NCj4g5Y+R5Lu25Lq6OiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIE5vYm8gQWtpeWEgKG5vYm8pDQo+IOWPkemAgeaXtumXtDogMjAxNOW5 tDfmnIgxMeaXpSAzOjAwDQo+IOaUtuS7tuS6ujogU2FtIEFsZHJpbjsgUnVlZGlnZXIuR2VpYkB0 ZWxla29tLmRlDQo+IOaKhOmAgTogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2Fz ZQ0KPiDkuLvpopg6IFJlOiBbc3ByaW5nXSBRdWVzdGlvbnMNCj4gDQo+IEhpIFNhbSwNCj4gDQo+ IEp1c3QgdG8gcG9pbnQgb3V0IG9uZSB0aGluZyBhYm91dCB0aGlzIGRvY3VtZW50IOKApg0KPiAN Cj4gVGhlIHRlc3QgcGFja2V0IGdlbmVyYXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1k ZXZpY2UgY2FuIGhhdmUgDQo+IHRoZSBjb21wbGV0ZSBzZWdtZW50IHN0YWNrIG9uIGhvdyB0byB0 cmF2ZXJzZSB0aGUgbmV0d29yayBhcyB3ZWxsIGFzIA0KPiBob3cgdG8gY29tZSBiYWNrIHRvIHNl bGYgd2l0aG91dCBhbnkgZnVydGhlciBzaWduYWxpbmcsIE9BTSBzdGF0ZSANCj4gbWFpbnRlbmFu Y2Ugb24gbmV0d29yayBub2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMu DQo+IA0KPiBUaGF0IG1ha2VzIHRoaXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNp bmcgcHJveHkgTFNQIHBpbmcuDQo+IA0KPiBUaGlzIGNlcnRhaW5seSBoYXMgc29tZSBwcm9zIGFu ZCBjb25zIGJ1dCBjYW4gYmUgcXVpdGUgdXNlZnVsIGFzIG9uZSANCj4gb2YgdGhlIE9BTXMgKHll cyBwbHVyYWwpIHVzZWQgdG8gbW9uaXRvciB0aGUgbmV0d29yay4NCj4gDQo+IFRoYW5rcyENCj4g DQo+IC1Ob2JvDQo+IA0KPiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFNhbSBBbGRyaW4NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTAs IDIwMTQgMjoxMyBQTQ0KPiBUbzogUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlDQo+IENjOiBzcHJp bmc7IGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlDQo+IFN1YmplY3Q6IFJlOiBbc3ByaW5n XSBRdWVzdGlvbnMNCj4gDQo+IEhpIFJ1ZWRpZ2VyLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgcXVp Y2sgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxpbmUuDQo+IA0KPiBPbiBU aHUsIEp1bCAxMCwgMjAxNCBhdCA3OjE1IEFNLCA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPiB3 cm90ZToNCj4gSGkgU2FtLA0KPiANCj4gbXkgcmVwbGllcyBhcmUgbWFya2VkIFtSR10gYW5kIGFk ZGVkIHRvIHlvdXIgdGV4dC4NCj4gDQo+IC0gUHJveHktbHNwLXBpbmcgaXMgTVBMUyBvbmx5LCB3 aGlsZSB0aGUgUE1TIGFyY2hpdGVjdHVyZSBpcyBpbnRlbmRlZCANCj4gZm9yIGV2ZXJ5IFNSIGRh dGEgcGxhbmUgKE1QTFMgKyBJUHY2KS4gV2UnbGwgY2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC4N Cj4gLSBQcm94eS1sc3AtcGluZyBpcyBmb3IgTVBMUyBMU1AgUGluZyAoUkZDIDQzNzkgLyBSRkMg NjQyNCksIHdoaWxlIG91ciANCj4gdXNlIGNhc2UgY2FuIHVzZSBhbnkgT0FNIChpbiBwYXJ0aWN1 bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9yIEJGRCwgDQo+IGFuZCBJQ01QdjYpDQo+IA0KPiBC YXNlZCBvbiB0aGF0LCBpdMK5cyBhIHNvbHV0aW9uIHdpdGggYnJvYWRlciBzY29wZSBhbmQgYmV0 dGVyIGZpdCBmb3IgDQo+IFNQUklORyBhcyBhIHdob2xlLg0KPiAlc2FtIC0gSSBiZWxpZXZlIHlv dSBzYXkgaXQgaXMgdXNlIGNhc2UgZG9jdW1lbnQgYmVsb3cuIFRoZW4gc29sdXRpb24gDQo+IGlz IHRvbyBwcmVtYXR1cmUgYXQgdGhpcyBwb2ludCBvZiB0aW1lLCBhcyB3ZSBoYXZlbid0IGRlbGli ZXJhdGVkIG9uIA0KPiB0aGUgcmVxdWlyZW1lbnRzIGVpdGhlci4NCj4gDQo+IEFzIHlvdSB3cml0 ZSwgU1IgYmFzZWQgT0FNIHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJv eHktbHNwLg0KPiBXaXRob3V0IHJlcXVpcmluZyB0aGUgYWRkaXRpb25hbCBtZXNzYWdlcyBhbmQg TEVSL0xTUiBwcm9jZXNzaW5nIA0KPiBpbnRyb2R1Y2VkIGJ5IHByb3h5LWxzcC4NCj4gDQo+IFJl Z2FyZHMsDQo+IA0KPiBSdWVkaWdlcg0KPiANCj4gDQo+IMKgIMKgIMKgIFNhbSBBbGRyaW4gd3Jv dGU6DQo+IA0KPiDCoCDCoCDCoCBJIGhhdmUgZmV3IHF1ZXN0aW9ucyBhYm91dCB0aGlzIGRyYWZ0 Lg0KPiANCj4gwqAgwqAgwqAgMS4gVGhlIHRpdGxlIGlzIGNvbmZ1c2luZyB0byBtZS4gSXQgc2F5 cyBPQU0gdXNlIGNhc2UgYnV0IGluIA0KPiBzZWN0aW9uICMxDQo+IMKgIMKgIMKgIGl0IHNheXMg dGhlIGZvbGxvd2luZw0KPiANCj4gwqAgwqAgwqAgPHNuaXA+DQo+IMKgIMKgIMKgIMKgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gc3RhdGVtZW50IA0K PiBhbmQNCj4gwqAgwqAgwqAgwqBpbGx1c3RyYXRlcyBpdCB3aXRoIHVzZS1jYXNlcy4NCj4gDQo+ IMKgIMKgIMKgIMKgVGhlIHNvbHV0aW9uIGlzIGRlc2NyaWJlZCBmb3IgYSBzaW5nbGUgSUdQIE1Q TFMgZG9tYWluLg0KPiANCj4gwqAgwqAgwqAgwqBUaGUgc29sdXRpb24gYXBwbGllcyB0byBtb25p dG9yaW5nIG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvDQo+IMKgIMKgIMKgIMKgbW9uaXRvcmlu ZyBvZiBTZWdtZW50IFJvdXRlZCBMU1Ancy4NCj4gwqAgwqAgwqAgPGVuZCBzbmlwPg0KPiANCj4g wqAgwqAgwqAgwqBJbiBmYWN0IHRoZSBkcmFmdCBpcyBkZXNjcmliaW5nIGEgc29sdXRpb24gdG8g Y2VydGFpbiBzY2VuYXJpb3MgDQo+IGFuZCBub3QganVzdA0KPiDCoCDCoCDCoCDCoHByb3ZpZGlu ZyB1c2UgY2FzZXMvc2NlbmFyaW9zLiBNeSB1bmRlcnN0YW5kaW5nIHdhcywgdXNlIGNhc2UgDQo+ IGRyYWZ0IHNob3VsZA0KPiDCoCDCoCDCoCDCoGRvY3VtZW50IHNjZW5hcmlvcyB3aGVyZSBpdCB3 aWxsIGRyaXZlIG5ldyByZXF1aXJlbWVudHMuIA0KPiBTb2x1dGlvbnMgY291bGQNCj4gwqAgwqAg wqAgwqBiZSBjb3ZlcmVkIHdpdGggZXhpc3RpbmcgdG9vbHNldCBvciBkZWZpbmVkIG5ld2x5LCBk ZXBlbmRpbmcgb24gDQo+IHRoZSBHQVANCj4gwqAgwqAgwqAgwqBhbmFseXNpcy4gQnV0IHRoYXQg c2hvdWxkIGJlIHNlcGFyYXRlIGFzIHRoZXJlIGNvdWxkIGJlIG1vcmUgDQo+IHRoYW4gMSBzb2x1 dGlvbiwNCj4gwqAgwqAgwqAgwqB3aGVyZSBhcyB0aGlzIGRvY3VtZW50IGNvdWxkIGp1c3QgZm9j dXMgb24gdXNlIGNhc2VzIG9ubHkuDQo+IA0KPiDCoCDCoCDCoCDCoElmIGluZmFjdCB0aGlzIGlz IHN1cHBvc2VkIHRvIGJlIGEgc29sdXRpb24gZG9jdW1lbnQsIHRoZW4gDQo+IGNoYW5naW5nIHRo ZSB0aXRsZQ0KPiDCoCDCoCDCoCDCoHdvdWxkIGJlIG1vcmUgbWVhbmluZ2Z1bC4gVGhhdCdzIG15 IG9ic2VydmF0aW9uLg0KPiBbUkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBX ZSdsbCByZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLg0KPiAlc2FtIC0gT0suIHRoZW4gSSdk IGxpa2UgdG8gc2VlIGFueSBzcGVjaWZpYyBzb2x1dGlvbiBjb250ZW50IHJlbW92ZWQsIA0KPiB0 aGF0IHdheSB3ZSBkb250IGhhdmUgdG8gZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2Vz IGVpdGhlciBvciANCj4gY29tcGFyZSB3aXRoIDpEDQo+IA0KPiANCj4gwqAgwqAgwqAgwqAyLiB3 LnIudC4gU2VjdGlvbiBudW1iZXIgIzIsIHRoZSBzYW1lIHByb2JsZW0gaXMgYmVpbmcgc29sdmVk IA0KPiB3aXRoDQo+IMKgIMKgIMKgIMKgImRyYWZ0LWlldGYtbXBscy1wcm94eS1sc3AtcGluZy0w MiIgLiBXaGF0IGlzIGJlaW5nIGRlc2NyaWJlZCANCj4gaW4gdGhpcw0KPiDCoCDCoCDCoCDCoHNl Y3Rpb24gY291bGQgYmUgZG9uZSB3aXRoIHRoZSBwcm94eSBwaW5nKHNvbHV0aW9uIHdpc2UpIHdo ZXJlLCANCj4gcmVxdWVzdCBjb3VsZA0KPiDCoCDCoCDCoCDCoGJlIHNlbnQgdG8gbW9uaXRvciBM RVIgaSBhbmQgTEVSIGogc2VnbWVudCwgZnJvbSBhIFBNUy4gSXMgbXkgDQo+IHVuZGVyc3RhbmRp bmcNCj4gwqAgwqAgwqAgwqByaWdodD8gSWYgbm90LCBob3cgaXMgaXQgZGlmZmVyZW50IGhlcmU/ DQo+IFtSR10gVGhlIFBNUyBpcyBhYmxlIHRvIHNldCB1cCBwYWNrZXRzIHdoaWNoIHN0YXkgaW4g ZGF0YSBwbGFuZSBhbmQgDQo+IGV4ZWN1dGUgYSBkZXNpcmVkDQo+IMKgIMKgIMKgY2hhaW4gb2Yg TVBMUyBMU1BzLg0KPiAlc2FtIC0gRXhlY3V0ZSB5b3UgbWVhbiB0cmF2ZXJzZT8gb3IgcGVyZm9y bSBzb21ldGhpbmcgZWxzZT8NCj4gDQo+IFtSR10gUHJveHktbHNwIHNheXM6IFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBwcm90b2NvbCBleHRlbnNpb25zIHRvIE1QTFMgDQo+IHBpbmcgW1JGQzQzNzld IHRvDQo+IMKgIMKgYWxsb3cgYSB0aGlyZCBwYXJ0eSB0byByZW1vdGVseSBjYXVzZSBhbiBNUExT IEVjaG8gUmVxdWVzdCBtZXNzYWdlIA0KPiB0bw0KPiDCoCDCoGJlIHNlbnQgZG93biBhIExTUCBv ciBwYXJ0IG9mIGFuIExTUC4NCj4gJXNhbSAtIElmIGl0IGlzIHByb3Bvc2luZyBleHRlbnNpb25z LCDCoGl0IGhhcyB0byBiZSBzb2x1dGlvbiBkb2N1bWVudCDCoA0KPiBhbmQgY2Fubm90IGNsYWlt IHRvIGJlIHVzZSBjYXNlIGRvY3VtZW50LiBBbHNvIHRoaXMgZG9jdW1lbnQgaXMgb24gDQo+IGlu Zm9ybWF0aW9uIHRyYWNrLg0KPiANCj4gW1JHXSBJIHRha2UgaXQgYXMgc2F5aW5nIHRoYXQgaWYg eW91J2QgbGlrZSB0byByZW1vdGVseSBleGVjdXRlIA0KPiBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkg b24gYW55IExTUCwgeW91IGNvdWxkIGVpdGhlciB1c2UgdGhlIFBNUyBvciANCj4gcHJveHktcGlu Zy4gVGhlIFBNUyBob3dldmVyIHNpbXBsaWZpZXMgYW5kIGFkZHMNCj4gZnVuY3Rpb25hbGl0eToN Cj4gYSkgWW91IGRvbid0IG5lZWQgYW4gYWRkaXRpb25hbCBwcm90b2NvbCBvciBmdW5jdGlvbmFs aXR5IGxpa2UgDQo+IHByb3h5LXBpbmcgdG8gY2hlY2sgZGF0YQ0KPiDCoCDCoHBsYW5lIGxpdmVs aW5lc3MsIFJGQzQzNzkgaXMgZmluZS4gRGV1dHNjaGUgVGVsZWtvbSBvcGVyYXRlcyBhIFBNUyAN Cj4gaW1wbGVtZW50YXRpb24uDQo+ICVzYW0gLSBSRkM0Mzc5IHBlcmZvcm1zIHZhbGlkYXRpb24g b2YgZGF0YXBsYW5lIGFuZCBhbHNvIGZpbmQgb3V0IGxvdCANCj4gbW9yZSBlcnJvcnMuIFlvdSBu ZWVkIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uIA0KPiBjaGVj a3MuIEZvciBsaXZlbmVzcyBkZXRlY3Rpb24sIEJGRCBpcyBwcmVmZXJyZWQgdG9vbCwgYXRsZWFz dCBpbiANCj4gcHJlc2VudCBkZXBsb3ltZW50cy5TbyBhcmUgeW91IHNheWluZywgUE1TIHNvbHV0 aW9uIGlzIGRlc2lnbmVkIGZvciANCj4gbGl2ZW5lc3MgZGV0ZWN0aW9uIGFuZCBub3QgdG8gcGVy Zm9ybSB2YWxpZGF0aW9uIG9mIGRhdGEgcGxhbmUgdG8gDQo+IGNvbnRyb2wgcGxhbmUsIGV0Yz8g KEkgdGhpbmsgeW91IGFncmVlIHRvIHRoaXMgaW4gdGhlIGxhdGVyIHBhcnQgb2YgDQo+IHRoZSBk b2MgYWxzbykNCj4gDQo+IGIpIG9uY2UgUE1TIGRldGVjdGVkIGRhdGEgcGxhbmUgbGl2ZWxpbmVz cyBhbmQgY29ycmVjdG5lc3Mgb2YgTVBMUyANCj4gdG9wb2xvZ3kgYnkgUkZDNDM3OSwNCj4gwqAg wqBpdCBjYW4gY29udGludWUgdG8gZXhlY3V0ZSBhcmJpdHJhcnkgTFNQIGNvbWJpbmF0aW9ucyBh bmQgdGhlIA0KPiBtb25pdG9yaW5nIHBhY2tldHMgc3RheQ0KPiDCoCDCoGluIGRhdGEgcGxhbmUu IFBsZWFzZSBwb2ludCBtZSB0byB0aGUgdGV4dCBpbiBwcm94eS1waW5nIG9mZmVyaW5nIA0KPiB0 aGlzIGZlYXR1cmUuDQo+ICVzYW0gLSBUaGlzIHlvdSBjb3VsZCBwZXJmb3JtIGV2ZW4gd2l0aG91 dCBwcm94eSBwaW5nLiBUaGUgZnVuY3Rpb24gDQo+IHlvdSBhcmUgZGVzY3JpYmluZyBpcywgaG93 IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBsc3AgcGluZyANCj4gZG9lcy4gQWdh aW4gSSBhbSBub3QgdGFsa2luZyBhYm91dCBub24tbXBscyB0b3BvbG9neS4NCj4gVG8gYW5zd2Vy IHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS4NCj4gLSBQZXJmb3JtIHRyZWV0cmFjZSB3 aXRoIHJmYzQzNzkgdG8gZ2V0IHRvcG9sb2d5IGluZm8NCj4gLSBwaWNrIGFueSBhcmJpdGFyeSBM U1AgcGF0aHMgZGlzY292ZXJlZCBhbG9uZyB3aXRoIGl0cyBtdWx0aXBhdGggDQo+IGltcGxlbWVu dGF0aW9uLg0KPiAtIHBlcmZvcm0gcGluZyB3aXRoIHJpZ2h0IHNlbGVjdG9ycyBmb3IgdGhlIHBh dGggYW5kIHVzZSBUVEwgZm9yIA0KPiBsaW1pdGluZyB0aGUgaG9wIFtMRVIgal0uDQo+IC0gaWYg eW91IHdhbnQgdG8gcGVyZm9ybSBmcm9tIExFUiBpIHRvIExFUiBqIGFzIGluIHlvdXIgZHJhZnQs IHVzZSANCj4gcHJveHkgcGluZyB0byBzdGFydCBmcm9tIExFUiBpDQo+IA0KPiDCoCDCoCDCoCDC oCAzLiBXaGVuIHRoZSByZXNwb25zZSBpcyBzZW50IGJhY2sgdG8gUE1TIHdoaWNoIGlzIG5vdCBw YXJ0IG9mIA0KPiBNUExTIG9yIHNlZ21lbnQNCj4gwqAgwqAgwqAgwqAgZG9tYWluLCB0aGVyZSBp cyBhIHNlcmlvdXMgc2VjdXJpdHkgYXNwZWN0LCB3aGljaCBuZWVkcyB0byANCj4gY29uc2lkZXJl ZC4gSSBiZWxpZXZlDQo+IMKgIMKgIMKgIMKgIGl0IGFwcGxpZXMgdG8gc2VuZGluZyBhIHJlcXVl c3QgdG9vLiBXaWxsIHlvdSBiZSBkb2N1bWVudGluZyANCj4gdGhhdCBhc3BlY3Q/DQo+IFtSR10g VGhhdCdzIGEgdmFsaWQgcG9pbnQuIFRoZSBkb21haW4gZXh0ZXJuYWwgc3lzdGVtIGlzIG9uZSBv cHRpb24gDQo+IGFuZCB0aGUgdGVhbSB3aWxsIGRlYWwgd2l0aCB0aGUgc2VjdXJpdHkgYXNwZWN0 cyByYWlzZWQgYnkgdGhpcyBvcHRpb24gDQo+IG9uY2Ugd2UgYXJlIGluIHNvbHV0aW9uIHNwYWNl LiBXZSB3aWxsIG5vdCBhbmFseXNlIHRoaXMgaW4gZGVwdGggZm9yIGEgdXNlIGNhc2UgZG9jdW1l bnQuDQo+ICVzYW0gLSBub2QNCj4gDQo+IMKgIMKgIMKgIMKgIDQuIFNlYyAzLjIgdG8gbW9uaXRv ciBidW5kbGUgbGlua3MsIG9uZSBjb3VsZCBwZXJmb3JtIHRoYXQgDQo+IHdpdGggUkZDNDM3OSBw aW5nDQo+IMKgIMKgIMKgIMKgIHdpdGggbXVsdHBhdGggKyBwcm94eSBwaW5nLiBDb3VsZCB5b3Ug a2luZGx5IGRpZmZlcmVudGlhdGUgaWYgDQo+IHRoZXJlIGlzIHNvbWV0aGluZw0KPiDCoCDCoCDC oCDCoCBuZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KPiBbUkddIFRoZSBTUiBPQU0gYXV0 aG9yIHRlYW0gaGFzIHByb3ZpZGVkIHRleHQgaG93IHRvIG1vbml0b3IgYSBidW5kbGVkIA0KPiBs aW5rIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1s c3AuIEkgDQo+IGNvdWxkbid0IGZpbmQgZXhwbGljaXQgdGV4dCBvbiBob3cgdG8gZGV0ZWN0IGFu ZCBtb25pdG9yIGEgYnVuZGxlZCBsaW5rIGluIGRyYWZ0LXByb3h5LWxzcC4NCj4gUGxlYXNlIGRl c2NyaWJlIGhvdyBwcm94eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQgbGlu ayANCj4gKHNvcnJ5IGlmIHRoaXMgaXMgb2J2aW91cyBhbmQgSSBtaXNzZWQgaXQpLiBJZiB0aGVy ZSBhcmUgZGlmZmVyZW5jZXMgDQo+IHRvIHRoZSBTUiBPQU0gYXBwcm9hY2gsIHdlJ2xsIGRpc2N1 c3MgdGhlbS4NCj4gJXNhbSAtIFRoZSBzYW1lIHN0ZXBzIGRlc2NyaWJlZCBhYm92ZSBjb3VsZCBi ZSB1c2VkIGlmIGVhY2ggYnVuZGxlZCANCj4gbGluayBtZW1iZXIgaXMgaWRlbnRpZmllZCB3aXRo IGEgdW5pcXVlIGxhYmVsLiBXaGlsZSBwZXJmb3JtaW5nIHRyZWUgDQo+IHRyYWNlIG9yIHBpbmcg d2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRoIERETUFQIGluZm8gZm9yIA0K PiBlYWNoIG9mIHRoZSBsaW5rcyBhbmQgdGhlIG11bHRpcGF0aCBpbmZvIGZvciB0aGUgc2FtZS4N Cj4gSWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUgbGFiZWwgc3RhY2ss IHRoZW4geW91IGNvdWxkIA0KPiB1c2UgbHNwIHNlbGVjdG9ycyBhcyBkZWZpbmVkIGluIFJGQzQz NzksIGluIHRoaXMgY2FzZSBpdCBpcyBsb2NhbCBob3N0IA0KPiBkZXN0IGlwIGFkZHIsIHRvIGlk ZW50aWZ5IGVhY2ggbGluayBtZW1iZXIuDQo+IE5vdyBpZiB0aGUgTVBMUyBmb3J3YXJkaW5nIGxh eWVyIHNlZXMgdGhlIGJ1bmRsZWQgbGluayBhcyBvbmUgDQo+IGludGVyZmFjZSBidXQgY2Fubm90 IGRpc2Nlcm4gaXRzIGxpbmsgbWVtYmVycywgdGhlbiB5b3UgY291bGQgb25seSANCj4gdmFsaWRh dGUgdGhlIGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRpdmlkdWFsIG1lbWJlcnMuDQo+IFNhbWUg YXBwbGllcyBpbiB5b3VyIGNhc2UgdG9vLiBDYW5ub3Qgc2VlIGhvdyBpdCBpcyBkaWZmZXJlbnQu DQo+IA0KPiANCj4gDQo+IMKgIMKgIMKgIMKgIMKgNS4gc2VjICM1LCBJcyB0aGUgcmVxdWlyZW1l bnQgaGVyZSBvbmx5IGZvciBQTVMgdG8gbGVhcm4gdGhlIA0KPiB0b3BvbG9neSwgaW4gdGhlDQo+ IMKgIMKgIMKgIMKgIMKgIMKgIGNhc2Ugb2YgbWl4ZWQgZW52Pw0KPiBbUkddIE1QTFMgdG9wb2xv Z3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25kaXRpb24gdG8gc2V0IHVwIHBhY2tldHMgDQo+IHdp dGggbGFiZWwgc3RhY2tzIGV4ZWN1dGluZyBhIGRlc2lyZWQgY2hhaW4gb2YgTFNQcy4gSWYgc3Vp dGFibGUgDQo+IExhYmVsL0ZFQy9ub2RlIHJlbGF0aW9uIGlzIGtub3duIHRvIHRoZSBQTVMsIHRo YXQgTFNQIGNhbiBiZSBleGVjdXRlZCANCj4gZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQTVMgbW9u aXRvcmluZyBwYWNrZXQuDQo+ICVzYW0gLSBTbywgeW91IGFyZSBzYXlpbmcgdGhhdCB5b3Ugc3Rp bGwgbmVlZCB0byBwZXJmb3JtIFJGQzQzNzkgdHJhY2UgDQo+IG9yIHRyZWV0cmFjZSB0byBnZXQg dG9wb2xvZ3kuIEkgZG8gbm90IHRoaW5rIElHUCBleHRlbnNpb25zIGJlaW5nIA0KPiBwcm9wb3Nl ZCBpbiBTUFJJTkcgZXhwb3J0IGFueSBvZiB0aGUgaW5mbyBvdGhlciB0aGFuIGxhYmVsIHN0YWNr Lg0KPiBBbmQgdGhlIHByb3Bvc2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBpcyB0aGF0 LCBpdCBwZXJmb3JtcyBvbiANCj4gZGVtYW5kIHBlciBzZWdtZW50LCB3aGljaCBQcm94eSBwaW5n IGFsc28gZG9lcywgYWxiZWl0IG9ubHkgZm9yIE1QTFMgDQo+IHRvcG9sb2d5Lg0KPiBUaGUgY2Fz ZSB5b3UgYXJlIG1ha2luZyBpcyB0aGF0IG5vIG5lZWQgb2YgYmVsbHMgYW5kIHdoaXN0bGVzIG9m IFJGQzQzNzkuDQo+IA0KPiBRdWVzdGlvbiBJIGhhdmUgZm9yIHlvdSBpcywgaWYgZGF0YSBwbGFu ZSBwYWNrZXRzIGFyZSBnZXR0aW5nIGRyb3BwZWQgDQo+IGFuZCBQTVMgcGFja2V0cyBnb2luZyB0 aHJvdWdoLCBmb3IgYSBnaXZlbiBMU1Agb3IgU2VnbWVudCwgaG93IGRvIHlvdSANCj4ga25vdyB0 aGVyZSBpcyBhIHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cgZG8geW91IGZpZ3VyZSBvdXQgd2hl cmUgaXQgaXM/DQo+IEF0IGxlYXN0IHdpdGggUkZDNDM3OSBhbmQvb3IgcHJveHkgcGluZywgeW91 IGNvdWxkIHZhbGlkYXRlIGVhY2ggaG9wIA0KPiBiZWNhdXNlIG9mIHRoZSBiZWxscyBhbmQgd2hp c3RsZXMgaXQgY2FycmllcyBhbG9uZyB3aXRoIHRoZSBwYWNrZXQuDQo+IA0KPiANCj4gDQo+IMKg IMKgIMKgIMKgIMKgNi4gSW4gc2VjIDMuMSwNCj4gwqAgwqAgwqAgwqAgwqA8c25pcD4NCj4gwqAg wqAgwqAgwqAgwqBEZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8gYSBt ZWFzdXJlbWVudCBtYXkgDQo+IGFsc28gYmUNCj4gwqAgwqAgwqAgwqAgwqBkb25lIGJ5IHNldHRp bmcgdXAgYSBsYWJlbCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0IA0KPiBwYXRo DQo+IMKgIMKgIMKgIMKgIMKgKGlmIExFUjEgaGFzIE5vZGUgU0lEIDQwIGluIHRoZSBleGFtcGxl IGFuZCBpdCBzaG91bGQgYmUgDQo+IHBhc3NlZA0KPiDCoCDCoCDCoCDCoCDCoGJldHdlZW4gTEVS IGkgYW5kIExFUiBqLCB0aGUgbGFiZWwgc3RhY2sgaXMgMjAgLSA0MCAtIDMwIC0gDQo+IDEwKS4g wqBUaGUNCj4gwqAgwqAgwqAgwqAgwqBhZHZhbnRhZ2Ugb2YgdGhpcyBtZXRob2QgaXMsIHRoYXQg aXQgZG9lcyBub3QgaW52b2x2ZSBNUExTIA0KPiBPQU0NCj4gwqAgwqAgwqAgwqAgwqBmdW5jdGlv bmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1bmN0aW9uYWxpdGllcy4gwqAN Cj4gVGhlDQo+IMKgIMKgIMKgIMKgIMKgbWV0aG9kIHN0aWxsIGlzIGFibGUgdG8gbW9uaXRvciBh bGwgbGluayBjb21iaW5hdGlvbnMgb2YgYWxsIA0KPiBwYXRocyBvZg0KPiDCoCDCoCDCoCDCoCDC oGFuIE1QTFMgZG9tYWluLiDCoElmIGNvcnJlY3QgZm9yd2FyZGluZyBhbG9uZyB0aGUgZGVzaXJl ZCANCj4gcGF0aHMgaGFzIHRvDQo+IMKgIMKgIMKgIMKgIMKgYmUgY2hlY2tlZCwgUkZDNDczOSBm dW5jdGlvbmFsaXR5IHNob3VsZCBiZSBhcHBsaWVkIGFsc28gaW4gDQo+IHRoaXMNCj4gwqAgwqAg wqAgwqAgwqBjYXNlLg0KPiANCj4gwqAgwqAgwqAgwqAgwqA8ZW5kIHNuaXA+DQo+IA0KPiDCoCDC oCDCoCDCoCDCoEluIHRoZSBhYm92ZSB5b3UgbWVudGlvbiB0aGF0IGl0IGRvZXMgbm90IGludm9s dmUgTVBMUyBPQU0uIA0KPiBCdXQgbGF0ZXIgeW91IHNheSwNCj4gwqAgwqAgwqAgwqAgwqBSRkM0 Mzc5IGZ1bmN0aW9uYWxpdHkgY291bGQgYmUgdXNlZC4gQ291bGQgeW91IGNsYXJpZnkgaG93IA0K PiBjb3VsZCB5b3UgdmVyaWZ5IGENCj4gwqAgwqAgwqAgwqAgwqBwYXRoLCBpZiBNUExTIHZhbGlk YXRpb24gaXMgbm90IGRvbmUuIE1vcmUgdGV4dCB3aWxsIGhlbHAuIA0KPiBBbHNvLCBtb3JlDQo+ IMKgIMKgIMKgIMKgIMKgaW1wb3J0YW50bHksIHRoZSB0ZXh0IGVhcmxpZXIgdG8gdGhlIGFib3Zl IHNheXMsIGZvciB2YWxpZCANCj4gcmVzdWx0LCBNUExTDQo+IMKgIMKgIMKgIMKgIMKgT0FNIGhh cyB0byBiZSBwZXJmb3JtZWQgZm9yIHRvcG9sb2d5IGNoYW5nZXMgZXRjLiBJZiBzbywgaXQgDQo+ IGNvbnRyYWRpY3RzIGhlcmUuDQo+IFtSR10gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0DQo+IC0g d2l0aG91dCBNUExTIE9BTSBmdW5jdGlvbnMsIHRoZSBQTVMgZXhlY3V0ZXMgYSBzZXQgb2YgcGF0 aHMgb25seSANCj4gYmFzZWQgb24gY29udHJvbCBwbGFuZSBpbmZvcm1hdGlvbi4NCj4gLSBpZiB0 aGUgb3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBwbGFuZSBjb3JyZXNwb25k cyB0byANCj4gY29udHJvbCBwbGFuZSwgUkZDNDczOSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFwcGxp ZWQuDQo+IElmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUgdGV4dCBpbiB0 aGUgZHJhZnQgc3RhdGVzIA0KPiBzb21ldGhpbmcgZGlmZmVyZW50LCBJJ2xsIHRyeSB0byByZXdv cmQgaXQuDQo+ICVzYW0gLSBUaGUgcHJvYmxlbSBJIGFtIGhhdmluZyBpcywgaW4gdGhlIGNhc2Ug b2YgTVBMUywgZm9yIE9BTSwgeW91IA0KPiBoYXZlIHRvIHZhbGlkYXRlIHRoZSBsc3AuDQo+IEkg ZGVmaW5pdGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0IEkgZmVl bCBpcywgdGhlIA0KPiB1c2UgY2FzZSBpcyB0b28gbXVjaCBjYXRlcmVkIHRvIGEgc3BlY2lmaWMg ZW52aXNpb25lZCBzb2x1dGlvbi4NCj4gT25jZSB5b3UgcmVtb3ZlIHNvbHV0aW9uIG9yIHN1Z2dl c3RlZCBlbmhhbmNlbWVudHMsIGhvcGUgaXQgc2hvdWxkIGJlIA0KPiBjbGVhciBvbiB3aGF0IGlz IGJlaW5nIHNvbHZlZCBhbmQgc2NvcGUgb3V0IGNsZWFyIHJlcXVpcmVtZW50cyBmb3IgYSANCj4g c29sdXRpb24uDQo+IEZvciBzb2x1dGlvbiBwYXJ0LCBwbGVhc2UgcHVibGlzaCBhIHNlcGFyYXRl IElELg0KPiANCj4gDQo+IMKgIMKgIMKgIMKgIMKgNy4gTGFzdCBidXQgbm90IHRoZSBsZWFzdCwg aG93IGRpZmZlcmVudCBpcyBQTVMgZnJvbSBFTVMgYW5kIE5NUz8NCj4gwqAgwqAgwqAgwqAgwqBT b21laG93IEkgY291bGRuJ3QgZmluZCB0aGUgZGlmZmVyZW5jZSB3aGF0IFBNUyBjb3VsZCBkbyBh bmQNCj4gwqAgwqAgwqAgwqAgwqBOTVMvRU1TIGNvdWxkbid0Lg0KPiBbUkddIEkndmUgbmV2ZXIg aGVhcmQgb2YgYW4gRU1TL05NUyB3aGljaCBpcyBNUExTIHRvcG9sb2d5IGF3YXJlIGFuZCANCj4g dXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVzcyB0byBjcmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRz IGV4ZWN1dGluZyANCj4gTFNQIGNvbWJpbmF0aW9ucyBhcyBkZXNpcmVkIGJ5IGFuIG9wZXJhdG9y LiBIYWQgdGhpcyBmZWF0dXJlIGJlZW4gDQo+IGNvbW1lcmNpYWxseSBhdmFpbGFibGUsIHRoZSBj b21wYW55IEkgd29yayBmb3Igd291bGRuJ3QgaGF2ZSBiZWVuIGRldmVsb3BpbmcgYSBQTVMuDQo+ ICVzYW0gLSBUaGVyZSBhcmUgdG9vbHMgd2hpY2ggYXJlIHBhcnQgb2YgTk1TL09TUywgd2hpY2gg cGVyZm9ybXMgTVBMUyANCj4gdG9wb2xvZ3kgc3BlY2lmaWMgb3BlcmF0aW9ucyDCoGZvciBhIGdp dmVuIHNldCBvZiBMU1Ancy4gVGhleSBwZXJmb3JtIA0KPiBUcmVldHJhY2UgYW5kIHBlcmZvcm0g cGluZyB3aXRoIG11bHRpcGF0aC4gQWxzbyBwZXJmb3JtIExTUCBzcGVjaWZpYyANCj4gdmFsaWRh dGlvbiBieSBjcmFmdGluZyBwYWNrZXRzIHdpdGggZGF0YSBhdmFpbGFibGUgd2l0aCB0cmVldHJh Y2UgYW5kIHBpbmcgd2l0aCBtdWx0aXBhdGguDQo+IFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29y a2Zsb3cgd2l0aG91dCB0aGUgbmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcgDQo+IHByb2JlIHRl Y2hub2xvZ3kuIFdpbGwgbm90IHNheSBiZXlvbmQgdGhhdCA6RA0KPiANCj4gY2hlZXJzDQo+IC1z YW0NCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo= From nobody Tue Jul 15 18:01:20 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7E91B29CB for ; Tue, 15 Jul 2014 18:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.552 X-Spam-Level: X-Spam-Status: No, score=-114.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQFfIYTUNlJU for ; Tue, 15 Jul 2014 18:01:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942261B27BB for ; Tue, 15 Jul 2014 18:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25236; q=dns/txt; s=iport; t=1405472475; x=1406682075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OzYxaPeLBUo3ObE0Y2VVQMSBl7haDMuHn5739oAtydk=; b=jtZSUIf3+I84So7WskaEe5k2oCRUvRpieXvayahFHfp9uIyk860LVxx/ mHd93LhQU2MmcguT8JegLx1Blf7lSaByNSu3SiOv/124obqrIvitbl62/ nY1XHHaGVCU1pyQqhdBhXess/UMWN23kfWAs/N/vdtNWVGYNFKJ1EEDtt 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAG7OxVOtJV2T/2dsb2JhbABPCoJqJFJXBIJyvn0Khm9TARl3FnWEAwEBAQMBAQEBIBEzBwQHBQcEAgEGAhEBAwEBAQICBh0DAgICJQsUAQIGCAIEAQ0FCBOIHwgBDJVunCiYDReBLI1DKwYQGwcCAgKCcTaBFgWWfYVmklqDRGyBBSQc X-IronPort-AV: E=Sophos;i="5.01,668,1400025600"; d="scan'208";a="340372882" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2014 01:01:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6G11DZZ007325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 01:01:13 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 20:01:13 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Qin Wu , Sam Aldrin , "Ruediger.Geib@telekom.de" Thread-Topic: [spring] Questions Thread-Index: Ac+buQ7J0p+bstYmPE68DfyqQITqogAT5ZsQAA/kkXAAExYZAAAJVwLwAKzC+wAABEV34AAhjLYAAB1QKfAACwXAAAAFLXsw Date: Wed, 16 Jul 2014 01:01:12 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B7ED884@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7ED884@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/2S5clBFxjOyROmCuXwZZSMwoCgs Cc: spring , draft-geib-spring-oam-usecase Subject: Re: [spring] Questions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 01:01:20 -0000 SGkgR3JlZywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHcmVnb3J5 IE1pcnNreSBbbWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbV0NCj4gU2VudDogVHVl c2RheSwgSnVseSAxNSwgMjAxNCA2OjI1IFBNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgUWlu IFd1OyBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4gQ2M6IHNwcmluZzsg ZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNCj4gU3ViamVjdDogUkU6IFtzcHJpbmddIFF1 ZXN0aW9ucw0KPiANCj4gSGkgTm9ibywgZXQuIGFsLA0KPiBhbGxvdyBtZSB0byBvZmZlciBteSAk LjAyLg0KPiANCj4gIiBXaGF0IEkgbWVhbnQgd2FzIHRoYXQgYSBub2RlIGluIGFuIFNSIGRvbWFp biBuZWVkcyB0byBtYWludGFpbjoNCj4gLSBsb2NhbCBzZWdtZW50cyBhbmQgcmVtb3RlIHNlZ21l bnQgaW4gaXRzIGNvbnRyb2wgcGxhbmUuDQo+IC0gbG9jYWwgc2VnbWVudHMgYW5kIHN1YnNldCBv ZiByZW1vdGUgc2VnbWVudHMgaW4gaXRzIGRhdGEgcGxhbmUuDQo+IA0KPiBBbmQgdGhlIE9BTSBt dXN0IG1ha2Ugc3VyZSB0aG9zZSBzdGF0ZXMgYXJlIGNvcnJlY3QgaW4gcmVsZXZhbnQgbm9kZXMg aW4NCj4gb3JkZXIgdG8gYWxsb3cgcGFja2V0IHN0ZWVyaW5nIHRvIGZ1bmN0aW9uIHByb3Blcmx5 LiINCj4gDQo+IEkgdGhpbmsgdGhhdCBPQU0gbXVzdCBiZSBhYmxlIHRvIGRldGVjdCBkZWZlY3Qs IGluIHRoaXMgY2FzZSBpbmNvbnNpc3RlbmN5DQo+IGJldHdlZW4gY29udHJvbC9tYW5hZ2VtZW50 IHBsYW5lIGFuZCBkYXRhIHBsYW5lLCBhbmQgbG9jYWxpemUgaXQuDQo+IEVuc3VyaW5nIHRoYXQg Y29udHJvbC9tYW5hZ2VtZW50IHBsYW5lIGlzIGluIHN5bmMsIGluIHN0YWJsZSBzdGF0ZSwgd2l0 aCB0aGUNCj4gZGF0YSBwbGFuZSwgSU1PIGlzIHJlc3BvbnNpYmlsaXR5IG9mIE8mTS4gKE9BTSBh bmQgTyZNIGJlaW5nIHVzZWQNCj4gYWNjb3JkaW5nIHRvIFJGQyA2MjkxKS4NCg0KRnVsbHkgYWdy ZWUgdGhhdCB3aGF0IHlvdSBjcmlzcGx5IGRlc2NyaWJlZCBpcyBhIGNyaXRpY2FsIGFzcGVjdCB0 aGF0IHdlIG5lZWQgdG8gYWNoaWV2ZSB3aXRoIHRoZSBTUFJJTkcgTyZNLg0KDQpUaGFua3MhDQoN Ci1Ob2JvDQoNCj4gDQo+IAlSZWdhcmRzLA0KPiAJCUdyZWcNCj4gDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTm9ibyBBa2l5YQ0KPiAobm9ibykNCj4gU2VudDogVHVlc2RheSwg SnVseSAxNSwgMjAxNCAzOjE2IFBNDQo+IFRvOiBRaW4gV3U7IFNhbSBBbGRyaW47IFJ1ZWRpZ2Vy LkdlaWJAdGVsZWtvbS5kZQ0KPiBDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNl Y2FzZQ0KPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gUXVlc3Rpb25zDQo+IA0KPiBIaSBRaW4sDQo+ IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUWluIFd1IFttYWls dG86YmlsbC53dUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCAx MToxMSBQTQ0KPiA+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgU2FtIEFsZHJpbjsgUnVlZGlnZXIu R2VpYkB0ZWxla29tLmRlDQo+ID4gQ2M6IHNwcmluZzsgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVz ZWNhc2UNCj4gPiBTdWJqZWN0OiBSRTogW3NwcmluZ10gUXVlc3Rpb25zDQo+ID4NCj4gPiBIaSwg Tm9ibzoNCj4gPiBJIGFncmVlIHRoZSBhc3BlY3RzIHRoYXQgYXJlIG1pc3NpbmcgaW4gZHJhZnQt Z2VpYi1zcHJpbmctb2FtLXVzZWNhc2UuDQo+ID4gU3ByaW5nIHByb2JsZW0gc3RhdGVtZW50IHNh eXMgdGhlIFNQUklORyBhcmNoaXRlY3R1cmUgd2lsbCBhZGRyZXNzIHVzZQ0KPiA+IGNhc2VzIHdo ZXJlIHJlbW92YWwgb2Ygc2lnbmFsaW5nIGFuZCBwYXRoIHN0YXRlIGluDQo+ID4gwqDCoCB0aGUg Y29yZSBpcyBhIHJlcXVpcmVtZW50Lg0KPiANCj4gWWVzLCBhbmQgYWRkaXRpb25hbCBzdGF0ZXMg YmVpbmcgcmVxdWlyZWQgZm9yIE9BTSBwdXJwb3NlIHNob3VsZCBiZQ0KPiBtaW5pbWl6ZWQgd2hl cmUgcG9zc2libGUsIElNTy4NCj4gDQo+ID4NCj4gPiBOb3cgeW91IHNhaWQgZWFjaCBuZXR3b3Jr IG5vZGUgc3RpbGwgaGFzIHN0YXRlcyByZWxhdGVkIHRvIHZhcmlvdXMNCj4gPiBzZWdtZW50IHR5 cGVzLg0KPiA+IEFyZSB5b3Ugc2F5aW5nIE5vbi1TUiBub2RlIGluIHRoZSBTUiBkb21haW4gc2hv dWxkIG5vdCBtYWludGFpbiBhbnkNCj4gPiBwYXRoIHN0YXRlIG9yIHNlZ21lbnQgcm91dGluZyBy ZWxhdGVkIHN0YXRlIGJ1dCBTUiBlbmFibGVkIG5vZGUgSW4gdGhlDQo+ID4gU1IgZG9tYWluIE1V U1QgaGF2ZSBzZWdtZW50IHJvdXRpbmcgcmVsYXRlZCBzdGF0ZT8gTGV0IG1lIGtub3cgaWYgbXkN Cj4gPiB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3Q/DQo+IA0KPiBXaGF0IEkgbWVhbnQgd2FzIHRo YXQgYSBub2RlIGluIGFuIFNSIGRvbWFpbiBuZWVkcyB0byBtYWludGFpbjoNCj4gLSBsb2NhbCBz ZWdtZW50cyBhbmQgcmVtb3RlIHNlZ21lbnQgaW4gaXRzIGNvbnRyb2wgcGxhbmUuDQo+IC0gbG9j YWwgc2VnbWVudHMgYW5kIHN1YnNldCBvZiByZW1vdGUgc2VnbWVudHMgaW4gaXRzIGRhdGEgcGxh bmUuDQo+IA0KPiBBbmQgdGhlIE9BTSBtdXN0IG1ha2Ugc3VyZSB0aG9zZSBzdGF0ZXMgYXJlIGNv cnJlY3QgaW4gcmVsZXZhbnQgbm9kZXMgaW4NCj4gb3JkZXIgdG8gYWxsb3cgcGFja2V0IHN0ZWVy aW5nIHRvIGZ1bmN0aW9uIHByb3Blcmx5Lg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gLU5vYm8NCj4g DQo+ID4NCj4gPiBSZWdhcmRzIQ0KPiA+IC1RaW4NCj4gPiDlj5Hku7bkuro6IE5vYm8gQWtpeWEg KG5vYm8pIFttYWlsdG86bm9ib0BjaXNjby5jb21dDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0 N+aciDE05pelIDIwOjM5DQo+ID4g5pS25Lu25Lq6OiBRaW4gV3U7IFNhbSBBbGRyaW47IFJ1ZWRp Z2VyLkdlaWJAdGVsZWtvbS5kZQ0KPiA+IOaKhOmAgTogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmlu Zy1vYW0tdXNlY2FzZQ0KPiA+IOS4u+mimDogUkU6IFtzcHJpbmddIFF1ZXN0aW9ucw0KPiA+DQo+ ID4gSGkgUWluLCBldCBhbCwNCj4gPg0KPiA+IEVhY2ggbmV0d29yayBub2RlIHdpbGwgc3RpbGwg aGF2ZSBzb21lIHN0YXRlcyAoaS5lLg0KPiA+IG5vZGUvYWRqYWNlbmN5L3NlcnZpY2Ugc2VnbWVu dHMpLg0KPiA+DQo+ID4gSSBzZWUgdGhlIHRlY2huaXF1ZSBkZXNjcmliZWQgZHJhZnQtZ2VpYi1z cHJpbmctb2FtLXVzZWNhc2UgYXMgYSB3YXkNCj4gPiB0byBtb25pdG9yIHRoZSBuZXR3b3JrLCBi dXQgbm90IGEgd2F5IHRvIHZhbGlkYXRlIHRoZSBzZWdtZW50cy4gSW4NCj4gPiBwYXJ0aWN1bGFy IHRoZSBmb2xsb3dpbmcgYXNwZWN0cyBjYW5ub3QgYmUgdmFsaWRhdGVkIGJ5IHRoZSB0ZWNobmlx dWUNCj4gPiBkZXNjcmliZWQgZHJhZnQtIGdlaWItc3ByaW5nLW9hbS11c2VjYXNlLg0KPiA+DQo+ ID4gMS4gVXNpbmcgYSBzZWdtZW50IG9yIGNvbWJpbmF0aW9uIG9mIHNlZ21lbnRzIHJlc3VsdCBp biBhIHBhY2tldCB0bw0KPiA+IHJlYWNoIGFuIGV4cGVjdGVkIG5ldHdvcmsgbm9kZS4NCj4gPiAy LiBVc2luZyBhbiBhZGphY2VuY3kgc2VnbWVudCByZXN1bHRzIGluIGEgcGFja2V0IHRvIHRyYXZl cnNlIG92ZXIgYW4NCj4gPiBleHBlY3RlZCBhZGphY2VuY3kuDQo+ID4gMy4gVXNpbmcgYSBzZXJ2 aWNlIHNlZ21lbnQgcmVzdWx0cyBpbiBhIHBhY2tldCB0byBoaXQgYW4gZXhwZWN0ZWQgc2Vydmlj ZS4NCj4gPg0KPiA+IFRoaXMgaXMgd2h5IEkgcHJldmlvdXNseSBtZW50aW9uZWQgdGhhdCB0aGUg dGVjaG5pcXVlIGlzIHVzZWZ1bCBhcyBvbmUNCj4gPiBvZiB0aGUgT0FNcyB1c2VkIHRvIG1vbml0 b3IgdGhlIG5ldHdvcmsuDQo+ID4NCj4gPiBJbiBvdGhlciB3b3Jkcywgd2Ugd291bGQgc3RpbGwg d2FudCB0aGluZ3MgaW4gYWRkaXRpb24gdG8gdmFsaWRhdGUgdGhlDQo+ID4gc3RhdGVzIG9uIGVh Y2ggbmV0d29yayBub2RlIHNvIHRoYXQsIHdoZW4gaW5ncmVzc2VzIHN0ZWVyIHBhY2tldHMNCj4g PiB1c2luZyBjb21iaW5hdGlvbnMgc2VnbWVudHMgKHRoYXQgbWFrZXMgdXNlIG9mIHRob3NlIHN0 YXRlcyksIHRoZW4NCj4gPiBleHBlY3RlZCBhbmQgYWN0dWFsIHBhdGhzIGFsaWducy4NCj4gPg0K PiA+IEkgaW50ZW50aW9uYWxseSBkaWRu4oCZdCBhbnN3ZXIgeW91ciBxdWVzdGlvbiBvbiB0aGUg dXNlZnVsbmVzcyBvZiBQcm94eQ0KPiA+IExTUCBQaW5nIG4gU2VnbWVudCBSb3V0aW5nLCBidXQg SSB3YW50ZWQgdG8gaGlnaGxpZ2h0IHdoYXQgYXJlIHRoZQ0KPiA+IGFkZGl0aW9uYWwgcG9pbnRz IHdlIHdvdWxkIHdhbnQgdG8gY292ZXIgZnJvbSBPQU0gcGVyc3BlY3RpdmUuDQo+ID4NCj4gPiBU aGFua3MhDQo+ID4NCj4gPiAtTm9ibw0KPiA+DQo+ID4gRnJvbTogUWluIFd1IFttYWlsdG86Ymls bC53dUBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAxNCA1OjA4IEFN DQo+ID4gVG86IE5vYm8gQWtpeWEgKG5vYm8pOyBTYW0gQWxkcmluOyBSdWVkaWdlci5HZWliQHRl bGVrb20uZGUNCj4gPiBDYzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0K PiA+IFN1YmplY3Q6IFJFOiBbc3ByaW5nXSBRdWVzdGlvbnMNCj4gPg0KPiA+IFZlcnkgZ29vZCBw b2ludCwgc2luY2Ugc2VnbWVudCByb3V0aW5nIGRvZXNu4oCZdCByZXF1aXJlIGVhY2ggbmV0d29y aw0KPiA+IG5vZGUgaW4gdGhlIHBhdGggdG8gbWFpbnRhaW4gc3RhdGUgYW5kIG9ubHkgaW5ncmVz cyBub2RlIG1haW50YWlucyB0aGUNCj4gPiBzdGF0ZSB3aGlsZSBQcm94eS1sc3AtcGluZyByZXF1 aXJlIGVhY2ggbmV0d29yayBub2RlIGluIHRoZSByZXR1cm4NCj4gPiBwYXRoIHRvIG1haW50YWlu IHRoZSBzdGF0ZS4NCj4gPiBXaHkgYXBwbHkgUHJveHktbHNwLXBpbmcgdG8gc3ByaW5nIE9BTT8N Cj4gPg0KPiA+IFJlZ2FyZHMhDQo+ID4gLVFpbg0KPiA+IOWPkeS7tuS6ujogc3ByaW5nIFttYWls dG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBOb2JvIEFraXlhIChub2JvKQ0KPiA+ IOWPkemAgeaXtumXtDogMjAxNOW5tDfmnIgxMeaXpSAzOjAwDQo+ID4g5pS25Lu25Lq6OiBTYW0g QWxkcmluOyBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4gPiDmioTpgIE6IHNwcmluZzsgZHJh ZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UNCj4gPiDkuLvpopg6IFJlOiBbc3ByaW5nXSBRdWVz dGlvbnMNCj4gPg0KPiA+IEhpIFNhbSwNCj4gPg0KPiA+IEp1c3QgdG8gcG9pbnQgb3V0IG9uZSB0 aGluZyBhYm91dCB0aGlzIGRvY3VtZW50IOKApg0KPiA+DQo+ID4gVGhlIHRlc3QgcGFja2V0IGdl bmVyYXRlZCBmcm9tIGEgUE1TL05NUy9FTVMvbmV0d29yay1kZXZpY2UgY2FuDQo+IGhhdmUNCj4g PiB0aGUgY29tcGxldGUgc2VnbWVudCBzdGFjayBvbiBob3cgdG8gdHJhdmVyc2UgdGhlIG5ldHdv cmsgYXMgd2VsbCBhcw0KPiA+IGhvdyB0byBjb21lIGJhY2sgdG8gc2VsZiB3aXRob3V0IGFueSBm dXJ0aGVyIHNpZ25hbGluZywgT0FNIHN0YXRlDQo+ID4gbWFpbnRlbmFuY2Ugb24gbmV0d29yayBu b2RlcyBub3IgT0FNIGludm9sdmVtZW50IGJ5IG5ldHdvcmsgbm9kZXMuDQo+ID4NCj4gPiBUaGF0 IG1ha2VzIHRoaXMgYXBwcm9hY2ggcXVpdGUgZGlmZmVyZW50IGZyb20gdXNpbmcgcHJveHkgTFNQ IHBpbmcuDQo+ID4NCj4gPiBUaGlzIGNlcnRhaW5seSBoYXMgc29tZSBwcm9zIGFuZCBjb25zIGJ1 dCBjYW4gYmUgcXVpdGUgdXNlZnVsIGFzIG9uZQ0KPiA+IG9mIHRoZSBPQU1zICh5ZXMgcGx1cmFs KSB1c2VkIHRvIG1vbml0b3IgdGhlIG5ldHdvcmsuDQo+ID4NCj4gPiBUaGFua3MhDQo+ID4NCj4g PiAtTm9ibw0KPiA+DQo+ID4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTYW0gQWxkcmluDQo+ID4gU2VudDogVGh1cnNkYXksIEp1bHkg MTAsIDIwMTQgMjoxMyBQTQ0KPiA+IFRvOiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGUNCj4gPiBD Yzogc3ByaW5nOyBkcmFmdC1nZWliLXNwcmluZy1vYW0tdXNlY2FzZQ0KPiA+IFN1YmplY3Q6IFJl OiBbc3ByaW5nXSBRdWVzdGlvbnMNCj4gPg0KPiA+IEhpIFJ1ZWRpZ2VyLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IHJlc3BvbnNlcyBpbmxp bmUuDQo+ID4NCj4gPiBPbiBUaHUsIEp1bCAxMCwgMjAxNCBhdCA3OjE1IEFNLCA8UnVlZGlnZXIu R2VpYkB0ZWxla29tLmRlPiB3cm90ZToNCj4gPiBIaSBTYW0sDQo+ID4NCj4gPiBteSByZXBsaWVz IGFyZSBtYXJrZWQgW1JHXSBhbmQgYWRkZWQgdG8geW91ciB0ZXh0Lg0KPiA+DQo+ID4gLSBQcm94 eS1sc3AtcGluZyBpcyBNUExTIG9ubHksIHdoaWxlIHRoZSBQTVMgYXJjaGl0ZWN0dXJlIGlzIGlu dGVuZGVkDQo+ID4gZm9yIGV2ZXJ5IFNSIGRhdGEgcGxhbmUgKE1QTFMgKyBJUHY2KS4gV2UnbGwg Y2xhcmlmeSB0aGF0IGluIHRoZSBkcmFmdC4NCj4gPiAtIFByb3h5LWxzcC1waW5nIGlzIGZvciBN UExTIExTUCBQaW5nIChSRkMgNDM3OSAvIFJGQyA2NDI0KSwgd2hpbGUgb3VyDQo+ID4gdXNlIGNh c2UgY2FuIHVzZSBhbnkgT0FNIChpbiBwYXJ0aWN1bGFyLCBzcGVjaWZpYyBnb29kIHVzZXMgZm9y IEJGRCwNCj4gPiBhbmQgSUNNUHY2KQ0KPiA+DQo+ID4gQmFzZWQgb24gdGhhdCwgaXTCuXMgYSBz b2x1dGlvbiB3aXRoIGJyb2FkZXIgc2NvcGUgYW5kIGJldHRlciBmaXQgZm9yDQo+ID4gU1BSSU5H IGFzIGEgd2hvbGUuDQo+ID4gJXNhbSAtIEkgYmVsaWV2ZSB5b3Ugc2F5IGl0IGlzIHVzZSBjYXNl IGRvY3VtZW50IGJlbG93LiBUaGVuIHNvbHV0aW9uDQo+ID4gaXMgdG9vIHByZW1hdHVyZSBhdCB0 aGlzIHBvaW50IG9mIHRpbWUsIGFzIHdlIGhhdmVuJ3QgZGVsaWJlcmF0ZWQgb24NCj4gPiB0aGUg cmVxdWlyZW1lbnRzIGVpdGhlci4NCj4gPg0KPiA+IEFzIHlvdSB3cml0ZSwgU1IgYmFzZWQgT0FN IHBhcnRpYWxseSBvZmZlcnMgc2ltaWxhciBmdW5jdGlvbnMgYXMgcHJveHktbHNwLg0KPiA+IFdp dGhvdXQgcmVxdWlyaW5nIHRoZSBhZGRpdGlvbmFsIG1lc3NhZ2VzIGFuZCBMRVIvTFNSIHByb2Nl c3NpbmcNCj4gPiBpbnRyb2R1Y2VkIGJ5IHByb3h5LWxzcC4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ ID4NCj4gPiBSdWVkaWdlcg0KPiA+DQo+ID4NCj4gPiDCoCDCoCDCoCBTYW0gQWxkcmluIHdyb3Rl Og0KPiA+DQo+ID4gwqAgwqAgwqAgSSBoYXZlIGZldyBxdWVzdGlvbnMgYWJvdXQgdGhpcyBkcmFm dC4NCj4gPg0KPiA+IMKgIMKgIMKgIDEuIFRoZSB0aXRsZSBpcyBjb25mdXNpbmcgdG8gbWUuIEl0 IHNheXMgT0FNIHVzZSBjYXNlIGJ1dCBpbg0KPiA+IHNlY3Rpb24gIzENCj4gPiDCoCDCoCDCoCBp dCBzYXlzIHRoZSBmb2xsb3dpbmcNCj4gPg0KPiA+IMKgIMKgIMKgIDxzbmlwPg0KPiA+IMKgIMKg IMKgIMKgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0g c3RhdGVtZW50DQo+ID4gYW5kDQo+ID4gwqAgwqAgwqAgwqBpbGx1c3RyYXRlcyBpdCB3aXRoIHVz ZS1jYXNlcy4NCj4gPg0KPiA+IMKgIMKgIMKgIMKgVGhlIHNvbHV0aW9uIGlzIGRlc2NyaWJlZCBm b3IgYSBzaW5nbGUgSUdQIE1QTFMgZG9tYWluLg0KPiA+DQo+ID4gwqAgwqAgwqAgwqBUaGUgc29s dXRpb24gYXBwbGllcyB0byBtb25pdG9yaW5nIG9mIExEUCBMU1AncyBhcyB3ZWxsIGFzIHRvDQo+ ID4gwqAgwqAgwqAgwqBtb25pdG9yaW5nIG9mIFNlZ21lbnQgUm91dGVkIExTUCdzLg0KPiA+IMKg IMKgIMKgIDxlbmQgc25pcD4NCj4gPg0KPiA+IMKgIMKgIMKgIMKgSW4gZmFjdCB0aGUgZHJhZnQg aXMgZGVzY3JpYmluZyBhIHNvbHV0aW9uIHRvIGNlcnRhaW4gc2NlbmFyaW9zDQo+ID4gYW5kIG5v dCBqdXN0DQo+ID4gwqAgwqAgwqAgwqBwcm92aWRpbmcgdXNlIGNhc2VzL3NjZW5hcmlvcy4gTXkg dW5kZXJzdGFuZGluZyB3YXMsIHVzZSBjYXNlDQo+ID4gZHJhZnQgc2hvdWxkDQo+ID4gwqAgwqAg wqAgwqBkb2N1bWVudCBzY2VuYXJpb3Mgd2hlcmUgaXQgd2lsbCBkcml2ZSBuZXcgcmVxdWlyZW1l bnRzLg0KPiA+IFNvbHV0aW9ucyBjb3VsZA0KPiA+IMKgIMKgIMKgIMKgYmUgY292ZXJlZCB3aXRo IGV4aXN0aW5nIHRvb2xzZXQgb3IgZGVmaW5lZCBuZXdseSwgZGVwZW5kaW5nIG9uDQo+ID4gdGhl IEdBUA0KPiA+IMKgIMKgIMKgIMKgYW5hbHlzaXMuIEJ1dCB0aGF0IHNob3VsZCBiZSBzZXBhcmF0 ZSBhcyB0aGVyZSBjb3VsZCBiZSBtb3JlDQo+ID4gdGhhbiAxIHNvbHV0aW9uLA0KPiA+IMKgIMKg IMKgIMKgd2hlcmUgYXMgdGhpcyBkb2N1bWVudCBjb3VsZCBqdXN0IGZvY3VzIG9uIHVzZSBjYXNl cyBvbmx5Lg0KPiA+DQo+ID4gwqAgwqAgwqAgwqBJZiBpbmZhY3QgdGhpcyBpcyBzdXBwb3NlZCB0 byBiZSBhIHNvbHV0aW9uIGRvY3VtZW50LCB0aGVuDQo+ID4gY2hhbmdpbmcgdGhlIHRpdGxlDQo+ ID4gwqAgwqAgwqAgwqB3b3VsZCBiZSBtb3JlIG1lYW5pbmdmdWwuIFRoYXQncyBteSBvYnNlcnZh dGlvbi4NCj4gPiBbUkddIFRoYW5rcy4gSXQncyBhIHVzZSBjYXNlIGRvY3VtZW50LiBXZSdsbCBy ZXZpZXcgdGhlIHRleHQgb2Ygc2VjdGlvbiAxLg0KPiA+ICVzYW0gLSBPSy4gdGhlbiBJJ2QgbGlr ZSB0byBzZWUgYW55IHNwZWNpZmljIHNvbHV0aW9uIGNvbnRlbnQgcmVtb3ZlZCwNCj4gPiB0aGF0 IHdheSB3ZSBkb250IGhhdmUgdG8gZGlzY3VzcyB3aGF0IG90aGVyIHNvbHV0aW9ucyBkb2VzIGVp dGhlciBvcg0KPiA+IGNvbXBhcmUgd2l0aCA6RA0KPiA+DQo+ID4NCj4gPiDCoCDCoCDCoCDCoDIu IHcuci50LiBTZWN0aW9uIG51bWJlciAjMiwgdGhlIHNhbWUgcHJvYmxlbSBpcyBiZWluZyBzb2x2 ZWQNCj4gPiB3aXRoDQo+ID4gwqAgwqAgwqAgwqAiZHJhZnQtaWV0Zi1tcGxzLXByb3h5LWxzcC1w aW5nLTAyIiAuIFdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkDQo+ID4gaW4gdGhpcw0KPiA+IMKgIMKg IMKgIMKgc2VjdGlvbiBjb3VsZCBiZSBkb25lIHdpdGggdGhlIHByb3h5IHBpbmcoc29sdXRpb24g d2lzZSkgd2hlcmUsDQo+ID4gcmVxdWVzdCBjb3VsZA0KPiA+IMKgIMKgIMKgIMKgYmUgc2VudCB0 byBtb25pdG9yIExFUiBpIGFuZCBMRVIgaiBzZWdtZW50LCBmcm9tIGEgUE1TLiBJcyBteQ0KPiA+ IHVuZGVyc3RhbmRpbmcNCj4gPiDCoCDCoCDCoCDCoHJpZ2h0PyBJZiBub3QsIGhvdyBpcyBpdCBk aWZmZXJlbnQgaGVyZT8NCj4gPiBbUkddIFRoZSBQTVMgaXMgYWJsZSB0byBzZXQgdXAgcGFja2V0 cyB3aGljaCBzdGF5IGluIGRhdGEgcGxhbmUgYW5kDQo+ID4gZXhlY3V0ZSBhIGRlc2lyZWQNCj4g PiDCoCDCoCDCoGNoYWluIG9mIE1QTFMgTFNQcy4NCj4gPiAlc2FtIC0gRXhlY3V0ZSB5b3UgbWVh biB0cmF2ZXJzZT8gb3IgcGVyZm9ybSBzb21ldGhpbmcgZWxzZT8NCj4gPg0KPiA+IFtSR10gUHJv eHktbHNwIHNheXM6IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBwcm90b2NvbCBleHRlbnNpb25zIHRv IE1QTFMNCj4gPiBwaW5nIFtSRkM0Mzc5XSB0bw0KPiA+IMKgIMKgYWxsb3cgYSB0aGlyZCBwYXJ0 eSB0byByZW1vdGVseSBjYXVzZSBhbiBNUExTIEVjaG8gUmVxdWVzdCBtZXNzYWdlDQo+ID4gdG8N Cj4gPiDCoCDCoGJlIHNlbnQgZG93biBhIExTUCBvciBwYXJ0IG9mIGFuIExTUC4NCj4gPiAlc2Ft IC0gSWYgaXQgaXMgcHJvcG9zaW5nIGV4dGVuc2lvbnMsIMKgaXQgaGFzIHRvIGJlIHNvbHV0aW9u IGRvY3VtZW50DQo+ID4gYW5kIGNhbm5vdCBjbGFpbSB0byBiZSB1c2UgY2FzZSBkb2N1bWVudC4g QWxzbyB0aGlzIGRvY3VtZW50IGlzIG9uDQo+ID4gaW5mb3JtYXRpb24gdHJhY2suDQo+ID4NCj4g PiBbUkddIEkgdGFrZSBpdCBhcyBzYXlpbmcgdGhhdCBpZiB5b3UnZCBsaWtlIHRvIHJlbW90ZWx5 IGV4ZWN1dGUNCj4gPiBSRkM0Mzc5IGZ1bmN0aW9uYWxpdHkgb24gYW55IExTUCwgeW91IGNvdWxk IGVpdGhlciB1c2UgdGhlIFBNUyBvcg0KPiA+IHByb3h5LXBpbmcuIFRoZSBQTVMgaG93ZXZlciBz aW1wbGlmaWVzIGFuZCBhZGRzDQo+ID4gZnVuY3Rpb25hbGl0eToNCj4gPiBhKSBZb3UgZG9uJ3Qg bmVlZCBhbiBhZGRpdGlvbmFsIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbGlrZQ0KPiA+IHBy b3h5LXBpbmcgdG8gY2hlY2sgZGF0YQ0KPiA+IMKgIMKgcGxhbmUgbGl2ZWxpbmVzcywgUkZDNDM3 OSBpcyBmaW5lLiBEZXV0c2NoZSBUZWxla29tIG9wZXJhdGVzIGEgUE1TDQo+ID4gaW1wbGVtZW50 YXRpb24uDQo+ID4gJXNhbSAtIFJGQzQzNzkgcGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBkYXRhcGxh bmUgYW5kIGFsc28gZmluZCBvdXQgbG90DQo+ID4gbW9yZSBlcnJvcnMuIFlvdSBuZWVkIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gdG8gcGVyZm9ybSB2YWxpZGF0aW9uDQo+ID4gY2hlY2tzLiBGb3Ig bGl2ZW5lc3MgZGV0ZWN0aW9uLCBCRkQgaXMgcHJlZmVycmVkIHRvb2wsIGF0bGVhc3QgaW4NCj4g PiBwcmVzZW50IGRlcGxveW1lbnRzLlNvIGFyZSB5b3Ugc2F5aW5nLCBQTVMgc29sdXRpb24gaXMg ZGVzaWduZWQgZm9yDQo+ID4gbGl2ZW5lc3MgZGV0ZWN0aW9uIGFuZCBub3QgdG8gcGVyZm9ybSB2 YWxpZGF0aW9uIG9mIGRhdGEgcGxhbmUgdG8NCj4gPiBjb250cm9sIHBsYW5lLCBldGM/IChJIHRo aW5rIHlvdSBhZ3JlZSB0byB0aGlzIGluIHRoZSBsYXRlciBwYXJ0IG9mDQo+ID4gdGhlIGRvYyBh bHNvKQ0KPiA+DQo+ID4gYikgb25jZSBQTVMgZGV0ZWN0ZWQgZGF0YSBwbGFuZSBsaXZlbGluZXNz IGFuZCBjb3JyZWN0bmVzcyBvZiBNUExTDQo+ID4gdG9wb2xvZ3kgYnkgUkZDNDM3OSwNCj4gPiDC oCDCoGl0IGNhbiBjb250aW51ZSB0byBleGVjdXRlIGFyYml0cmFyeSBMU1AgY29tYmluYXRpb25z IGFuZCB0aGUNCj4gPiBtb25pdG9yaW5nIHBhY2tldHMgc3RheQ0KPiA+IMKgIMKgaW4gZGF0YSBw bGFuZS4gUGxlYXNlIHBvaW50IG1lIHRvIHRoZSB0ZXh0IGluIHByb3h5LXBpbmcgb2ZmZXJpbmcN Cj4gPiB0aGlzIGZlYXR1cmUuDQo+ID4gJXNhbSAtIFRoaXMgeW91IGNvdWxkIHBlcmZvcm0gZXZl biB3aXRob3V0IHByb3h5IHBpbmcuIFRoZSBmdW5jdGlvbg0KPiA+IHlvdSBhcmUgZGVzY3JpYmlu ZyBpcywgaG93IHlvdSB1c2UgbHNwIHBpbmcgcmF0aGVyIHRoYW4gd2hhdCBsc3AgcGluZw0KPiA+ IGRvZXMuIEFnYWluIEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgbm9uLW1wbHMgdG9wb2xvZ3kuDQo+ ID4gVG8gYW5zd2VyIHlvdXIgcXVlc3Rpb24sIGhvdyB5b3UgcGVyZm9ybS4NCj4gPiAtIFBlcmZv cm0gdHJlZXRyYWNlIHdpdGggcmZjNDM3OSB0byBnZXQgdG9wb2xvZ3kgaW5mbw0KPiA+IC0gcGlj ayBhbnkgYXJiaXRhcnkgTFNQIHBhdGhzIGRpc2NvdmVyZWQgYWxvbmcgd2l0aCBpdHMgbXVsdGlw YXRoDQo+ID4gaW1wbGVtZW50YXRpb24uDQo+ID4gLSBwZXJmb3JtIHBpbmcgd2l0aCByaWdodCBz ZWxlY3RvcnMgZm9yIHRoZSBwYXRoIGFuZCB1c2UgVFRMIGZvcg0KPiA+IGxpbWl0aW5nIHRoZSBo b3AgW0xFUiBqXS4NCj4gPiAtIGlmIHlvdSB3YW50IHRvIHBlcmZvcm0gZnJvbSBMRVIgaSB0byBM RVIgaiBhcyBpbiB5b3VyIGRyYWZ0LCB1c2UNCj4gPiBwcm94eSBwaW5nIHRvIHN0YXJ0IGZyb20g TEVSIGkNCj4gPg0KPiA+IMKgIMKgIMKgIMKgIDMuIFdoZW4gdGhlIHJlc3BvbnNlIGlzIHNlbnQg YmFjayB0byBQTVMgd2hpY2ggaXMgbm90IHBhcnQgb2YNCj4gPiBNUExTIG9yIHNlZ21lbnQNCj4g PiDCoCDCoCDCoCDCoCBkb21haW4sIHRoZXJlIGlzIGEgc2VyaW91cyBzZWN1cml0eSBhc3BlY3Qs IHdoaWNoIG5lZWRzIHRvDQo+ID4gY29uc2lkZXJlZC4gSSBiZWxpZXZlDQo+ID4gwqAgwqAgwqAg wqAgaXQgYXBwbGllcyB0byBzZW5kaW5nIGEgcmVxdWVzdCB0b28uIFdpbGwgeW91IGJlIGRvY3Vt ZW50aW5nDQo+ID4gdGhhdCBhc3BlY3Q/DQo+ID4gW1JHXSBUaGF0J3MgYSB2YWxpZCBwb2ludC4g VGhlIGRvbWFpbiBleHRlcm5hbCBzeXN0ZW0gaXMgb25lIG9wdGlvbg0KPiA+IGFuZCB0aGUgdGVh bSB3aWxsIGRlYWwgd2l0aCB0aGUgc2VjdXJpdHkgYXNwZWN0cyByYWlzZWQgYnkgdGhpcyBvcHRp b24NCj4gPiBvbmNlIHdlIGFyZSBpbiBzb2x1dGlvbiBzcGFjZS4gV2Ugd2lsbCBub3QgYW5hbHlz ZSB0aGlzIGluIGRlcHRoIGZvciBhIHVzZQ0KPiBjYXNlIGRvY3VtZW50Lg0KPiA+ICVzYW0gLSBu b2QNCj4gPg0KPiA+IMKgIMKgIMKgIMKgIDQuIFNlYyAzLjIgdG8gbW9uaXRvciBidW5kbGUgbGlu a3MsIG9uZSBjb3VsZCBwZXJmb3JtIHRoYXQNCj4gPiB3aXRoIFJGQzQzNzkgcGluZw0KPiA+IMKg IMKgIMKgIMKgIHdpdGggbXVsdHBhdGggKyBwcm94eSBwaW5nLiBDb3VsZCB5b3Uga2luZGx5IGRp ZmZlcmVudGlhdGUgaWYNCj4gPiB0aGVyZSBpcyBzb21ldGhpbmcNCj4gPiDCoCDCoCDCoCDCoCBu ZXcgdGhlIHNvbHV0aW9uIGJyaW5ncyBoZXJlPw0KPiA+IFtSR10gVGhlIFNSIE9BTSBhdXRob3Ig dGVhbSBoYXMgcHJvdmlkZWQgdGV4dCBob3cgdG8gbW9uaXRvciBhIGJ1bmRsZWQNCj4gPiBsaW5r IGluIHRoZSB1c2UgY2FzZSBkcmFmdC4gWW91IGFyZSBhIGNvLWF1dGhvciBvZiBwcm94eS1sc3Au IEkNCj4gPiBjb3VsZG4ndCBmaW5kIGV4cGxpY2l0IHRleHQgb24gaG93IHRvIGRldGVjdCBhbmQg bW9uaXRvciBhIGJ1bmRsZWQgbGluayBpbg0KPiBkcmFmdC1wcm94eS1sc3AuDQo+ID4gUGxlYXNl IGRlc2NyaWJlIGhvdyBwcm94eS1sc3AgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIGJ1bmRsZWQg bGluaw0KPiA+IChzb3JyeSBpZiB0aGlzIGlzIG9idmlvdXMgYW5kIEkgbWlzc2VkIGl0KS4gSWYg dGhlcmUgYXJlIGRpZmZlcmVuY2VzDQo+ID4gdG8gdGhlIFNSIE9BTSBhcHByb2FjaCwgd2UnbGwg ZGlzY3VzcyB0aGVtLg0KPiA+ICVzYW0gLSBUaGUgc2FtZSBzdGVwcyBkZXNjcmliZWQgYWJvdmUg Y291bGQgYmUgdXNlZCBpZiBlYWNoIGJ1bmRsZWQNCj4gPiBsaW5rIG1lbWJlciBpcyBpZGVudGlm aWVkIHdpdGggYSB1bmlxdWUgbGFiZWwuIFdoaWxlIHBlcmZvcm1pbmcgdHJlZQ0KPiA+IHRyYWNl IG9yIHBpbmcgd2l0aCBtdWx0aXBhdGgsIExFUiBpIHdpbGwgcmVzcG9uZCB3aXRoIERETUFQIGlu Zm8gZm9yDQo+ID4gZWFjaCBvZiB0aGUgbGlua3MgYW5kIHRoZSBtdWx0aXBhdGggaW5mbyBmb3Ig dGhlIHNhbWUuDQo+ID4gSWYgeW91IHNheSB0aGF0IGVhY2ggbGluayBtZW1iZXIgaGFzIHNhbWUg bGFiZWwgc3RhY2ssIHRoZW4geW91IGNvdWxkDQo+ID4gdXNlIGxzcCBzZWxlY3RvcnMgYXMgZGVm aW5lZCBpbiBSRkM0Mzc5LCBpbiB0aGlzIGNhc2UgaXQgaXMgbG9jYWwgaG9zdA0KPiA+IGRlc3Qg aXAgYWRkciwgdG8gaWRlbnRpZnkgZWFjaCBsaW5rIG1lbWJlci4NCj4gPiBOb3cgaWYgdGhlIE1Q TFMgZm9yd2FyZGluZyBsYXllciBzZWVzIHRoZSBidW5kbGVkIGxpbmsgYXMgb25lDQo+ID4gaW50 ZXJmYWNlIGJ1dCBjYW5ub3QgZGlzY2VybiBpdHMgbGluayBtZW1iZXJzLCB0aGVuIHlvdSBjb3Vs ZCBvbmx5DQo+ID4gdmFsaWRhdGUgdGhlIGludGVyZmFjZSBhbmQgbm90IGl0cyBpbmRpdmlkdWFs IG1lbWJlcnMuDQo+ID4gU2FtZSBhcHBsaWVzIGluIHlvdXIgY2FzZSB0b28uIENhbm5vdCBzZWUg aG93IGl0IGlzIGRpZmZlcmVudC4NCj4gPg0KPiA+DQo+ID4NCj4gPiDCoCDCoCDCoCDCoCDCoDUu IHNlYyAjNSwgSXMgdGhlIHJlcXVpcmVtZW50IGhlcmUgb25seSBmb3IgUE1TIHRvIGxlYXJuIHRo ZQ0KPiA+IHRvcG9sb2d5LCBpbiB0aGUNCj4gPiDCoCDCoCDCoCDCoCDCoCDCoCBjYXNlIG9mIG1p eGVkIGVudj8NCj4gPiBbUkddIE1QTFMgdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIHRoZSBwcmVjb25k aXRpb24gdG8gc2V0IHVwIHBhY2tldHMNCj4gPiB3aXRoIGxhYmVsIHN0YWNrcyBleGVjdXRpbmcg YSBkZXNpcmVkIGNoYWluIG9mIExTUHMuIElmIHN1aXRhYmxlDQo+ID4gTGFiZWwvRkVDL25vZGUg cmVsYXRpb24gaXMga25vd24gdG8gdGhlIFBNUywgdGhhdCBMU1AgY2FuIGJlIGV4ZWN1dGVkDQo+ ID4gZnJvbSB0aGF0IG5vZGUgb24gYnkgYSBQTVMgbW9uaXRvcmluZyBwYWNrZXQuDQo+ID4gJXNh bSAtIFNvLCB5b3UgYXJlIHNheWluZyB0aGF0IHlvdSBzdGlsbCBuZWVkIHRvIHBlcmZvcm0gUkZD NDM3OSB0cmFjZQ0KPiA+IG9yIHRyZWV0cmFjZSB0byBnZXQgdG9wb2xvZ3kuIEkgZG8gbm90IHRo aW5rIElHUCBleHRlbnNpb25zIGJlaW5nDQo+ID4gcHJvcG9zZWQgaW4gU1BSSU5HIGV4cG9ydCBh bnkgb2YgdGhlIGluZm8gb3RoZXIgdGhhbiBsYWJlbCBzdGFjay4NCj4gPiBBbmQgdGhlIHByb3Bv c2VkIFBNUyBzb2x1dGlvbiAobm90IHVzZSBjYXNlKSBpcyB0aGF0LCBpdCBwZXJmb3JtcyBvbg0K PiA+IGRlbWFuZCBwZXIgc2VnbWVudCwgd2hpY2ggUHJveHkgcGluZyBhbHNvIGRvZXMsIGFsYmVp dCBvbmx5IGZvciBNUExTDQo+ID4gdG9wb2xvZ3kuDQo+ID4gVGhlIGNhc2UgeW91IGFyZSBtYWtp bmcgaXMgdGhhdCBubyBuZWVkIG9mIGJlbGxzIGFuZCB3aGlzdGxlcyBvZiBSRkM0Mzc5Lg0KPiA+ DQo+ID4gUXVlc3Rpb24gSSBoYXZlIGZvciB5b3UgaXMsIGlmIGRhdGEgcGxhbmUgcGFja2V0cyBh cmUgZ2V0dGluZyBkcm9wcGVkDQo+ID4gYW5kIFBNUyBwYWNrZXRzIGdvaW5nIHRocm91Z2gsIGZv ciBhIGdpdmVuIExTUCBvciBTZWdtZW50LCBob3cgZG8geW91DQo+ID4ga25vdyB0aGVyZSBpcyBh IHByb2JsZW0/IGlmIHlvdSBrbm93LCBob3cgZG8geW91IGZpZ3VyZSBvdXQgd2hlcmUgaXQgaXM/ DQo+ID4gQXQgbGVhc3Qgd2l0aCBSRkM0Mzc5IGFuZC9vciBwcm94eSBwaW5nLCB5b3UgY291bGQg dmFsaWRhdGUgZWFjaCBob3ANCj4gPiBiZWNhdXNlIG9mIHRoZSBiZWxscyBhbmQgd2hpc3RsZXMg aXQgY2FycmllcyBhbG9uZyB3aXRoIHRoZSBwYWNrZXQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gwqAg wqAgwqAgwqAgwqA2LiBJbiBzZWMgMy4xLA0KPiA+IMKgIMKgIMKgIMKgIMKgPHNuaXA+DQo+ID4g wqAgwqAgwqAgwqAgwqBEZXRlcm1pbmluZyBhIHBhdGggdG8gYmUgZXhlY3V0ZWQgcHJpb3IgdG8g YSBtZWFzdXJlbWVudCBtYXkNCj4gPiBhbHNvIGJlDQo+ID4gwqAgwqAgwqAgwqAgwqBkb25lIGJ5 IHNldHRpbmcgdXAgYSBsYWJlbCBpbmNsdWRpbmcgYWxsIG5vZGUgU0lEcyBhbG9uZyB0aGF0DQo+ ID4gcGF0aA0KPiA+IMKgIMKgIMKgIMKgIMKgKGlmIExFUjEgaGFzIE5vZGUgU0lEIDQwIGluIHRo ZSBleGFtcGxlIGFuZCBpdCBzaG91bGQgYmUNCj4gPiBwYXNzZWQNCj4gPiDCoCDCoCDCoCDCoCDC oGJldHdlZW4gTEVSIGkgYW5kIExFUiBqLCB0aGUgbGFiZWwgc3RhY2sgaXMgMjAgLSA0MCAtIDMw IC0NCj4gPiAxMCkuIMKgVGhlDQo+ID4gwqAgwqAgwqAgwqAgwqBhZHZhbnRhZ2Ugb2YgdGhpcyBt ZXRob2QgaXMsIHRoYXQgaXQgZG9lcyBub3QgaW52b2x2ZSBNUExTDQo+ID4gT0FNDQo+ID4gwqAg wqAgwqAgwqAgwqBmdW5jdGlvbmFsaXR5IGFuZCBpdCBpcyBpbmRlcGVuZGVudCBvZiBFQ01QIGZ1 bmN0aW9uYWxpdGllcy4NCj4gPiBUaGUNCj4gPiDCoCDCoCDCoCDCoCDCoG1ldGhvZCBzdGlsbCBp cyBhYmxlIHRvIG1vbml0b3IgYWxsIGxpbmsgY29tYmluYXRpb25zIG9mIGFsbA0KPiA+IHBhdGhz IG9mDQo+ID4gwqAgwqAgwqAgwqAgwqBhbiBNUExTIGRvbWFpbi4gwqBJZiBjb3JyZWN0IGZvcndh cmRpbmcgYWxvbmcgdGhlIGRlc2lyZWQNCj4gPiBwYXRocyBoYXMgdG8NCj4gPiDCoCDCoCDCoCDC oCDCoGJlIGNoZWNrZWQsIFJGQzQ3MzkgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXBwbGllZCBh bHNvIGluDQo+ID4gdGhpcw0KPiA+IMKgIMKgIMKgIMKgIMKgY2FzZS4NCj4gPg0KPiA+IMKgIMKg IMKgIMKgIMKgPGVuZCBzbmlwPg0KPiA+DQo+ID4gwqAgwqAgwqAgwqAgwqBJbiB0aGUgYWJvdmUg eW91IG1lbnRpb24gdGhhdCBpdCBkb2VzIG5vdCBpbnZvbHZlIE1QTFMgT0FNLg0KPiA+IEJ1dCBs YXRlciB5b3Ugc2F5LA0KPiA+IMKgIMKgIMKgIMKgIMKgUkZDNDM3OSBmdW5jdGlvbmFsaXR5IGNv dWxkIGJlIHVzZWQuIENvdWxkIHlvdSBjbGFyaWZ5IGhvdw0KPiA+IGNvdWxkIHlvdSB2ZXJpZnkg YQ0KPiA+IMKgIMKgIMKgIMKgIMKgcGF0aCwgaWYgTVBMUyB2YWxpZGF0aW9uIGlzIG5vdCBkb25l LiBNb3JlIHRleHQgd2lsbCBoZWxwLg0KPiA+IEFsc28sIG1vcmUNCj4gPiDCoCDCoCDCoCDCoCDC oGltcG9ydGFudGx5LCB0aGUgdGV4dCBlYXJsaWVyIHRvIHRoZSBhYm92ZSBzYXlzLCBmb3IgdmFs aWQNCj4gPiByZXN1bHQsIE1QTFMNCj4gPiDCoCDCoCDCoCDCoCDCoE9BTSBoYXMgdG8gYmUgcGVy Zm9ybWVkIGZvciB0b3BvbG9neSBjaGFuZ2VzIGV0Yy4gSWYgc28sIGl0DQo+ID4gY29udHJhZGlj dHMgaGVyZS4NCj4gPiBbUkddIFRoZSB0ZXh0IHNob3VsZCBzYXkgdGhhdA0KPiA+IC0gd2l0aG91 dCBNUExTIE9BTSBmdW5jdGlvbnMsIHRoZSBQTVMgZXhlY3V0ZXMgYSBzZXQgb2YgcGF0aHMgb25s eQ0KPiA+IGJhc2VkIG9uIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24uDQo+ID4gLSBpZiB0aGUg b3BlcmF0b3Igd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQgZGF0YSBwbGFuZSBjb3JyZXNwb25kcyB0 bw0KPiA+IGNvbnRyb2wgcGxhbmUsIFJGQzQ3MzkgZnVuY3Rpb25zIHNob3VsZCBiZSBhcHBsaWVk Lg0KPiA+IElmIHlvdSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50IGFuZCB0aGUgdGV4dCBpbiB0 aGUgZHJhZnQgc3RhdGVzDQo+ID4gc29tZXRoaW5nIGRpZmZlcmVudCwgSSdsbCB0cnkgdG8gcmV3 b3JkIGl0Lg0KPiA+ICVzYW0gLSBUaGUgcHJvYmxlbSBJIGFtIGhhdmluZyBpcywgaW4gdGhlIGNh c2Ugb2YgTVBMUywgZm9yIE9BTSwgeW91DQo+ID4gaGF2ZSB0byB2YWxpZGF0ZSB0aGUgbHNwLg0K PiA+IEkgZGVmaW5pdGVseSBzZWUgYSBzcGVjaWZpYyBuZWVkIGZvciBTUFJJTkcsIGJ1dCB3aGF0 IEkgZmVlbCBpcywgdGhlDQo+ID4gdXNlIGNhc2UgaXMgdG9vIG11Y2ggY2F0ZXJlZCB0byBhIHNw ZWNpZmljIGVudmlzaW9uZWQgc29sdXRpb24uDQo+ID4gT25jZSB5b3UgcmVtb3ZlIHNvbHV0aW9u IG9yIHN1Z2dlc3RlZCBlbmhhbmNlbWVudHMsIGhvcGUgaXQgc2hvdWxkIGJlDQo+ID4gY2xlYXIg b24gd2hhdCBpcyBiZWluZyBzb2x2ZWQgYW5kIHNjb3BlIG91dCBjbGVhciByZXF1aXJlbWVudHMg Zm9yIGENCj4gPiBzb2x1dGlvbi4NCj4gPiBGb3Igc29sdXRpb24gcGFydCwgcGxlYXNlIHB1Ymxp c2ggYSBzZXBhcmF0ZSBJRC4NCj4gPg0KPiA+DQo+ID4gwqAgwqAgwqAgwqAgwqA3LiBMYXN0IGJ1 dCBub3QgdGhlIGxlYXN0LCBob3cgZGlmZmVyZW50IGlzIFBNUyBmcm9tIEVNUyBhbmQgTk1TPw0K PiA+IMKgIMKgIMKgIMKgIMKgU29tZWhvdyBJIGNvdWxkbid0IGZpbmQgdGhlIGRpZmZlcmVuY2Ug d2hhdCBQTVMgY291bGQgZG8gYW5kDQo+ID4gwqAgwqAgwqAgwqAgwqBOTVMvRU1TIGNvdWxkbid0 Lg0KPiA+IFtSR10gSSd2ZSBuZXZlciBoZWFyZCBvZiBhbiBFTVMvTk1TIHdoaWNoIGlzIE1QTFMg dG9wb2xvZ3kgYXdhcmUgYW5kDQo+ID4gdXNlcyB0aGlzIHRvcG9sb2d5IGF3YXJlbmVzcyB0byBj cmVhdGUgZGF0YSBwbGFuZSBwYWNrZXRzIGV4ZWN1dGluZw0KPiA+IExTUCBjb21iaW5hdGlvbnMg YXMgZGVzaXJlZCBieSBhbiBvcGVyYXRvci4gSGFkIHRoaXMgZmVhdHVyZSBiZWVuDQo+ID4gY29t bWVyY2lhbGx5IGF2YWlsYWJsZSwgdGhlIGNvbXBhbnkgSSB3b3JrIGZvciB3b3VsZG4ndCBoYXZl IGJlZW4NCj4gZGV2ZWxvcGluZyBhIFBNUy4NCj4gPiAlc2FtIC0gVGhlcmUgYXJlIHRvb2xzIHdo aWNoIGFyZSBwYXJ0IG9mIE5NUy9PU1MsIHdoaWNoIHBlcmZvcm1zIE1QTFMNCj4gPiB0b3BvbG9n eSBzcGVjaWZpYyBvcGVyYXRpb25zIMKgZm9yIGEgZ2l2ZW4gc2V0IG9mIExTUCdzLiBUaGV5IHBl cmZvcm0NCj4gPiBUcmVldHJhY2UgYW5kIHBlcmZvcm0gcGluZyB3aXRoIG11bHRpcGF0aC4gQWxz byBwZXJmb3JtIExTUCBzcGVjaWZpYw0KPiA+IHZhbGlkYXRpb24gYnkgY3JhZnRpbmcgcGFja2V0 cyB3aXRoIGRhdGEgYXZhaWxhYmxlIHdpdGggdHJlZXRyYWNlIGFuZCBwaW5nDQo+IHdpdGggbXVs dGlwYXRoLg0KPiA+IFlvdSBjb3VsZCBhdXRvbWF0ZSB0aGUgd29ya2Zsb3cgd2l0aG91dCB0aGUg bmVlZCBmb3IgT1NTL1BNUywgYnkgdXNpbmcNCj4gPiBwcm9iZSB0ZWNobm9sb2d5LiBXaWxsIG5v dCBzYXkgYmV5b25kIHRoYXQgOkQNCj4gPg0KPiA+IGNoZWVycw0KPiA+IC1zYW0NCj4gPg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3By aW5nIG1haWxpbmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Thu Jul 17 18:59:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451DF1A03A9; Thu, 17 Jul 2014 18:59:03 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SkSv6TXLqXK; Thu, 17 Jul 2014 18:59:01 -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 031BC1A01BA; Thu, 17 Jul 2014 18:59:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH71716; Fri, 18 Jul 2014 01:58:59 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 02:58:59 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 09:58:52 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPw== Date: Fri, 18 Jul 2014 01:58:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/_50WX4Lh7Sss7d_sKs_FjCX06zI Cc: "" , "sfc@ietf.org" Subject: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 01:59:03 -0000 Hi all, I'm now considering how to carry metadata/context in an MPLS packet. I just= noticed that draft-guichard-mpls-metadata-00 (http://tools.ietf.org/html/d= raft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/con= text in an MPLS packet (see below): "3. Metadata Channel Header Format The presence of metadata within an MPLS packet must be indicated in the encapsulation. This document defines that the G-ACh Generic Associated Channel Label (GAL) [RFC5586] with label value 13 is utilized for this purpose. The GAL label provides a method to identify that a packet contains an "Associated Channel Header (ACH)" followed by a non-service payload. [RFC5586] identifies the G-ACh Generic Associated Channel by setting the first nibble of the ACH that immediately follows the bottom label in the stack if the GAL label is present, to 0001b. Further [RFC5586] expects that the ACH not be used to carry user data traffic. This document proposes an extension to allow the first nibble of the ACH to be set to 0000b and, when following the GAL, be interpreted using the semantics defined in [I-D.guichard-metadata-header] to allow metadata to be carried through the G-ACh channel." However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]: " The GAL MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, when present, the GAL MUST NOT appear more than once in the label stack." I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a Proto= col Type (PT) field immediately after the bottom of the MPLS label stack. W= ith such PT field, any kind of future MPLS payload (e.g., metadata header o= r NSH) can be easily identified. Best regards, Xiaohu From nobody Thu Jul 17 20:18:03 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFAB1B286B; Thu, 17 Jul 2014 20:17:59 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfwJrI66UM8C; Thu, 17 Jul 2014 20:17:58 -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 1FBE31A0495; Thu, 17 Jul 2014 20:17:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH76308; Fri, 18 Jul 2014 03:17:55 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 04:17:54 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 11:17:51 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoA= Date: Fri, 18 Jul 2014 03:17:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk> In-Reply-To: <1405653056176.39234@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/sJMaeE0XFYy2tn79M8i6tjWo6VI Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:17:59 -0000 The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know. Best regards, Xiaohu > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Friday, July 18, 2014 11:11 AM > To: Xuxiaohu; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > How? A better question is "why?" >=20 > What has to be done in MPLS that cannot be done outside it? >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: mpls on behalf of Xuxiaohu > > Sent: Friday, 18 July 2014 11:58 AM > To: mpls@ietf.org > Cc: ; sfc@ietf.org > Subject: [mpls] How to carry metadata/context in an MPLS packet >=20 > Hi all, >=20 > I'm now considering how to carry metadata/context in an MPLS packet. I ju= st > noticed that draft-guichard-mpls-metadata-00 > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propo= ses > a way to carry metadata/context in an MPLS packet (see below): >=20 > "3. Metadata Channel Header Format >=20 > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. >=20 > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." >=20 > However, it seems that the special usage of the GAL as mentioned above st= ill > conflicts with the following statement quoted from [RFC5586]: >=20 > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." >=20 > I wonder whether the special usage of the GAL as proposed in the above dr= aft > would result in any backward compatibility issue. In addition, I wonder w= hether > it's worthwhile to reconsider the possibility of introducing a Protocol T= ype (PT) > field immediately after the bottom of the MPLS label stack. With such PT = field, > any kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily > identified. >=20 > Best regards, > Xiaohu >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 17 23:33:28 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C198D1B28FC; Thu, 17 Jul 2014 23:33:22 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbBcOU5Ffr7q; Thu, 17 Jul 2014 23:33:20 -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 374361B28F9; Thu, 17 Jul 2014 23:33:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH87825; Fri, 18 Jul 2014 06:33:17 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 07:33:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 14:33:10 +0800 From: Xuxiaohu To: "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVwAGdgOQ Date: Fri, 18 Jul 2014 06:33:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941BF@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> In-Reply-To: <1405653745773.33083@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/X643oJbuDxHCFln9oy824VfE10E Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:33:23 -0000 > -----Original Message----- > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > Sent: Friday, July 18, 2014 11:22 AM > To: Xuxiaohu; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > No, my "why" is "why have metadata in the MPLS header at all"? You could choose to carry the metadata context instead of the metadata itse= lf in the data packet (See section 3.5 of the following draft (http://tools= .ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8)). > Why does this have to be done inband? It doesn't have to be done inband. However, since In-band marking (see sect= ion 3.1 of the following draft (http://tools.ietf.org/html/draft-rijsman-sf= c-metadata-considerations-00#page-8)) ) is one of the approaches of metadat= a sharing, I'm just considering how to realize that in-band approach in the= MPLS case. Best regards, Xiaohu > I am questioning the basis for doing this. There is no "must" here. >=20 > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu > Sent: Friday, 18 July 2014 1:17 PM > To: Wood L Dr (Electronic Eng); mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 > The presence of metadata within an MPLS packet must be indicated in the > encapsulation. I think that's the "why" you may want to know. >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:11 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > How? A better question is "why?" > > > > What has to be done in MPLS that cannot be done outside it? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls on behalf of Xuxiaohu > > > > Sent: Friday, 18 July 2014 11:58 AM > > To: mpls@ietf.org > > Cc: ; sfc@ietf.org > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > Hi all, > > > > I'm now considering how to carry metadata/context in an MPLS packet. I > > just noticed that draft-guichard-mpls-metadata-00 > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > > proposes a way to carry metadata/context in an MPLS packet (see below): > > > > "3. Metadata Channel Header Format > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. This document defines that the G-ACh Generic > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > utilized for this purpose. The GAL label provides a method to > > identify that a packet contains an "Associated Channel Header (ACH)" > > followed by a non-service payload. > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > > the first nibble of the ACH that immediately follows the bottom labe= l > > in the stack if the GAL label is present, to 0001b. Further > > [RFC5586] expects that the ACH not be used to carry user data > > traffic. This document proposes an extension to allow the first > > nibble of the ACH to be set to 0000b and, when following the GAL, be > > interpreted using the semantics defined in > > [I-D.guichard-metadata-header] to allow metadata to be carried > > through the G-ACh channel." > > > > However, it seems that the special usage of the GAL as mentioned above > > still conflicts with the following statement quoted from [RFC5586]: > > > > " The GAL MUST NOT appear in the label stack when transporting normal > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > appear more than once in the label stack." > > > > I wonder whether the special usage of the GAL as proposed in the above > > draft would result in any backward compatibility issue. In addition, I > > wonder whether it's worthwhile to reconsider the possibility of > > introducing a Protocol Type (PT) field immediately after the bottom of > > the MPLS label stack. With such PT field, any kind of future MPLS > > payload (e.g., metadata header or NSH) can be easily identified. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 17 23:42:17 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B921B2906; Thu, 17 Jul 2014 23:42:13 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OIgelks77rO; Thu, 17 Jul 2014 23:42:11 -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 36AB11B2904; Thu, 17 Jul 2014 23:42:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKF19478; Fri, 18 Jul 2014 06:42:08 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 07:42:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 14:41:56 +0800 From: Xuxiaohu To: Xuxiaohu , "l.wood@surrey.ac.uk" , "mpls@ietf.org" Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVwAGdgOQAAB4rkA= Date: Fri, 18 Jul 2014 06:41:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941CD@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/LUdNKhCDC4emkIzPZPqC4G2SBvc Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 06:42:13 -0000 > -----Original Message----- > From: Xuxiaohu > Sent: Friday, July 18, 2014 2:33 PM > To: 'l.wood@surrey.ac.uk'; mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet >=20 >=20 >=20 > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:22 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > No, my "why" is "why have metadata in the MPLS header at all"? >=20 > You could choose to carry the metadata context instead of the metadata it= self in > the data packet (See section 3.5 of the following draft > (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#= page- > 8)). >=20 > > Why does this have to be done inband? >=20 > It doesn't have to be done inband. However, since In-band marking (see se= ction > 3.1 of the following draft > (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#= page- > 8)) ) is one of the approaches of metadata sharing, I'm just considering = how to > realize that in-band approach in the MPLS case. >=20 > Best regards, > Xiaohu >=20 > > I am questioning the basis for doing this. There is no "must" here. By the way, you are right that carrying metadata or metadata context within= data packets is optional, rather than mandatory. Best regards, Xiaohu > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu > > Sent: Friday, 18 July 2014 1:17 PM > > To: Wood L Dr (Electronic Eng); mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. I think that's the "why" you may want to know. > > > > Best regards, > > Xiaohu > > > > > -----Original Message----- > > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > Sent: Friday, July 18, 2014 11:11 AM > > > To: Xuxiaohu; mpls@ietf.org > > > Cc: spring@ietf.org; sfc@ietf.org > > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > > > How? A better question is "why?" > > > > > > What has to be done in MPLS that cannot be done outside it? > > > > > > Lloyd Wood > > > http://about.me/lloydwood > > > ________________________________________ > > > From: mpls on behalf of Xuxiaohu > > > > > > Sent: Friday, 18 July 2014 11:58 AM > > > To: mpls@ietf.org > > > Cc: ; sfc@ietf.org > > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > > > Hi all, > > > > > > I'm now considering how to carry metadata/context in an MPLS packet. > > > I just noticed that draft-guichard-mpls-metadata-00 > > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > > > proposes a way to carry metadata/context in an MPLS packet (see below= ): > > > > > > "3. Metadata Channel Header Format > > > > > > The presence of metadata within an MPLS packet must be indicated i= n > > > the encapsulation. This document defines that the G-ACh Generic > > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > > utilized for this purpose. The GAL label provides a method to > > > identify that a packet contains an "Associated Channel Header (ACH= )" > > > followed by a non-service payload. > > > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setti= ng > > > the first nibble of the ACH that immediately follows the bottom la= bel > > > in the stack if the GAL label is present, to 0001b. Further > > > [RFC5586] expects that the ACH not be used to carry user data > > > traffic. This document proposes an extension to allow the first > > > nibble of the ACH to be set to 0000b and, when following the GAL, = be > > > interpreted using the semantics defined in > > > [I-D.guichard-metadata-header] to allow metadata to be carried > > > through the G-ACh channel." > > > > > > However, it seems that the special usage of the GAL as mentioned > > > above still conflicts with the following statement quoted from [RFC55= 86]: > > > > > > " The GAL MUST NOT appear in the label stack when transporting norma= l > > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > > appear more than once in the label stack." > > > > > > I wonder whether the special usage of the GAL as proposed in the > > > above draft would result in any backward compatibility issue. In > > > addition, I wonder whether it's worthwhile to reconsider the > > > possibility of introducing a Protocol Type (PT) field immediately > > > after the bottom of the MPLS label stack. With such PT field, any > > > kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily > identified. > > > > > > Best regards, > > > Xiaohu > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Jul 18 00:26:59 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94E1A0198; Fri, 18 Jul 2014 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wW3sf9bamzH; Fri, 18 Jul 2014 00:26:53 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDA21A0195; Fri, 18 Jul 2014 00:26:53 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so4157525ieb.4 for ; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=C+M5wQkfS8QrxXgvxHCtmQjOhx6rE5hLRCsCvC4FHEs=; b=tzl3iLewdy4ZVE0aQF0TCOuPI3/c/F06+JR5dpeSpjRJjLWk5EeCtSQ+RFoaWVxyc5 4wDfkwhfX9QkkBo2EzpT2wAK69m8O6O9d0SeYYMyuIwmUHuOH5iZt13z7epWMckX2MIW q/LCAHl+QVtWInQedm9yC3MVuTVpGkE2elMkql7X1O/IwJnoD7AmUS36jLT8zi6lmWaA Hw4CdYzlf3+mS6ZjdyIIRbULZYh8ohzgLA/avPcTEOYMbUs82QV0RdK6QyB7Tw5RbORP yTsudWgEBOimXS3tQgPSdDfJ0FppQxkhv9vJFpe+s8z7mb010BxPvjBeGPQm+2/ROkc3 +C0A== MIME-Version: 1.0 X-Received: by 10.50.12.38 with SMTP id v6mr35920569igb.29.1405668412382; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 00:26:52 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 09:26:52 +0200 X-Google-Sender-Auth: iizaAMQ0lVE2RL8TC1vgTCKRyYE Message-ID: From: Robert Raszuk To: Xuxiaohu , "sfc@ietf.org" Content-Type: multipart/alternative; boundary=089e0112c39c647f9c04fe72ae95 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/A2xELdlRh0yh1c6AwRnQZVxWH20 Cc: "mpls@ietf.org" , "" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:26:55 -0000 --089e0112c39c647f9c04fe72ae95 Content-Type: text/plain; charset=UTF-8 All, Is the idea of using data plane to carry complete metadata is "the way" or "a way" of approaching the problem ? Has this been already discussed ? I would rather consider to carry metadata in control plane and only attach a reference_id (and only when it is needed) to the data plane. Rgs, R. On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introducing > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadata > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e0112c39c647f9c04fe72ae95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Is the idea of using data plane to carry complete metadata is "the way= " or "a way" of approaching the problem ? Has this been alre= ady discussed ?

I would rather consider to carry metadata in contro= l plane and only attach a reference_id (and only when it is needed) to the = data plane.=C2=A0

Rgs,
R.





On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <xuxiaohu@huawei.com&g= t; wrote:
Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propose= s a way to carry metadata/context in an MPLS packet (see below):

"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stac= k. With such PT field, any kind of future MPLS payload (e.g., metadata head= er or NSH) can be easily identified.

Best regards,
Xiaohu

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

--089e0112c39c647f9c04fe72ae95-- From nobody Fri Jul 18 00:43:51 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283AE1A031B; Fri, 18 Jul 2014 00:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n77wnU3Saj6y; Fri, 18 Jul 2014 00:43:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5857A1A0328; Fri, 18 Jul 2014 00:43:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH94291; Fri, 18 Jul 2014 07:43:37 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 08:43:09 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 15:43:06 +0800 From: Xuxiaohu To: Robert Raszuk , "sfc@ietf.org" Thread-Topic: [spring] How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltP///1YkA//95gUA= Date: Fri, 18 Jul 2014 07:43:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/TFwTWdBtTiTrK51CtgiW-Gye5iQ Cc: "mpls@ietf.org" , "" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:43:43 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJdCBzZWVtcyB0aGF0IHRoZSBjb25jZXB0IG9mIOKAnHJlZmVyZW5jZV9p ZOKAnSBsb29rcyBtdWNoIHNpbWlsYXIgd2l0aCB0aGUgY29uY2VwdCBvZiDigJxjb3JyZWxhdG9y 4oCdIGFzIGRlZmluZWQgaW4gc2VjdGlvbiAzLjMgb2YgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJpanNtYW4tc2ZjLW1ldGFkYXRhLWNvbnNpZGVyYXRpb25zLTAwI3BhZ2UtOCku IFRoYXTigJlzIHRoZSBjb250ZXh0IElEIG9mIHRoZSBtZXRhZGF0YSBJIG1lYW50Lg0KDQpJZiB0 aGF0ICDigJxyZWZlcmVuY2VfaWTigJ0gaXMgYXR0YWNoZWQgdG8gdGhlIE1QTFMgcGFja2V0LCBp dCBzZWVtcyB0aGF0IHlvdSBzdGlsbCBuZWVkIHNvbWUgd2F5IHRvIGluZGljYXRlIHRoZSBwcmVz ZW5jZSBvZiB0aGF0IOKAnHJlZmVyZW5jZV9pZOKAnSBpbiB0aGUgTVBMUyBwYWNrZXQuDQoNCkJl c3QgcmVnYXJkcywNClhpYW9odQ0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJy YXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogRnJpZGF5 LCBKdWx5IDE4LCAyMDE0IDM6MjcgUE0NClRvOiBYdXhpYW9odTsgc2ZjQGlldGYub3JnDQpDYzog bXBsc0BpZXRmLm9yZzsgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBI b3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldA0KDQpBbGwsDQoN CklzIHRoZSBpZGVhIG9mIHVzaW5nIGRhdGEgcGxhbmUgdG8gY2FycnkgY29tcGxldGUgbWV0YWRh dGEgaXMgInRoZSB3YXkiIG9yICJhIHdheSIgb2YgYXBwcm9hY2hpbmcgdGhlIHByb2JsZW0gPyBI YXMgdGhpcyBiZWVuIGFscmVhZHkgZGlzY3Vzc2VkID8NCg0KSSB3b3VsZCByYXRoZXIgY29uc2lk ZXIgdG8gY2FycnkgbWV0YWRhdGEgaW4gY29udHJvbCBwbGFuZSBhbmQgb25seSBhdHRhY2ggYSBy ZWZlcmVuY2VfaWQgKGFuZCBvbmx5IHdoZW4gaXQgaXMgbmVlZGVkKSB0byB0aGUgZGF0YSBwbGFu ZS4NCg0KUmdzLA0KUi4NCg0KDQoNCg0KT24gRnJpLCBKdWwgMTgsIDIwMTQgYXQgMzo1OCBBTSwg WHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+ PiB3cm90ZToNCkhpIGFsbCwNCg0KSSdtIG5vdyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0 YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFm dC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwI3BhZ2UtNikgcHJvcG9zZXMgYSB3YXkgdG8g Y2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldCAoc2VlIGJlbG93KToNCg0K IjMuICBNZXRhZGF0YSBDaGFubmVsIEhlYWRlciBGb3JtYXQNCg0KICAgVGhlIHByZXNlbmNlIG9m IG1ldGFkYXRhIHdpdGhpbiBhbiBNUExTIHBhY2tldCBtdXN0IGJlIGluZGljYXRlZCBpbg0KICAg dGhlIGVuY2Fwc3VsYXRpb24uICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhhdCB0aGUgRy1BQ2gg R2VuZXJpYw0KICAgQXNzb2NpYXRlZCBDaGFubmVsIExhYmVsIChHQUwpIFtSRkM1NTg2XSB3aXRo IGxhYmVsIHZhbHVlIDEzIGlzDQogICB1dGlsaXplZCBmb3IgdGhpcyBwdXJwb3NlLiAgVGhlIEdB TCBsYWJlbCBwcm92aWRlcyBhIG1ldGhvZCB0bw0KICAgaWRlbnRpZnkgdGhhdCBhIHBhY2tldCBj b250YWlucyBhbiAiQXNzb2NpYXRlZCBDaGFubmVsIEhlYWRlciAoQUNIKSINCiAgIGZvbGxvd2Vk IGJ5IGEgbm9uLXNlcnZpY2UgcGF5bG9hZC4NCg0KICAgW1JGQzU1ODZdIGlkZW50aWZpZXMgdGhl IEctQUNoIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIGJ5IHNldHRpbmcNCiAgIHRoZSBmaXJz dCBuaWJibGUgb2YgdGhlIEFDSCB0aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3MgdGhlIGJvdHRvbSBs YWJlbA0KICAgaW4gdGhlIHN0YWNrIGlmIHRoZSBHQUwgbGFiZWwgaXMgcHJlc2VudCwgdG8gMDAw MWIuICBGdXJ0aGVyDQogICBbUkZDNTU4Nl0gZXhwZWN0cyB0aGF0IHRoZSBBQ0ggbm90IGJlIHVz ZWQgdG8gY2FycnkgdXNlciBkYXRhDQogICB0cmFmZmljLiAgVGhpcyBkb2N1bWVudCBwcm9wb3Nl cyBhbiBleHRlbnNpb24gdG8gYWxsb3cgdGhlIGZpcnN0DQogICBuaWJibGUgb2YgdGhlIEFDSCB0 byBiZSBzZXQgdG8gMDAwMGIgYW5kLCB3aGVuIGZvbGxvd2luZyB0aGUgR0FMLCBiZQ0KICAgaW50 ZXJwcmV0ZWQgdXNpbmcgdGhlIHNlbWFudGljcyBkZWZpbmVkIGluDQogICBbSS1ELmd1aWNoYXJk LW1ldGFkYXRhLWhlYWRlcl0gdG8gYWxsb3cgbWV0YWRhdGEgdG8gYmUgY2FycmllZA0KICAgdGhy b3VnaCB0aGUgRy1BQ2ggY2hhbm5lbC4iDQoNCkhvd2V2ZXIsIGl0IHNlZW1zIHRoYXQgdGhlIHNw ZWNpYWwgdXNhZ2Ugb2YgdGhlIEdBTCBhcyBtZW50aW9uZWQgYWJvdmUgc3RpbGwgY29uZmxpY3Rz IHdpdGggdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgcXVvdGVkIGZyb20gW1JGQzU1ODZdOg0KDQoi ICBUaGUgR0FMIE1VU1QgTk9UIGFwcGVhciBpbiB0aGUgbGFiZWwgc3RhY2sgd2hlbiB0cmFuc3Bv cnRpbmcgbm9ybWFsDQogICB1c2VyLXBsYW5lIHBhY2tldHMuICBGdXJ0aGVybW9yZSwgd2hlbiBw cmVzZW50LCB0aGUgR0FMIE1VU1QgTk9UDQogICBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgaW4gdGhl IGxhYmVsIHN0YWNrLiINCg0KSSB3b25kZXIgd2hldGhlciB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0 aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRoZSBhYm92ZSBkcmFmdCB3b3VsZCByZXN1bHQgaW4gYW55 IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUuIEluIGFkZGl0aW9uLCBJIHdvbmRlciB3aGV0 aGVyIGl0J3Mgd29ydGh3aGlsZSB0byByZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRy b2R1Y2luZyBhIFByb3RvY29sIFR5cGUgKFBUKSBmaWVsZCBpbW1lZGlhdGVseSBhZnRlciB0aGUg Ym90dG9tIG9mIHRoZSBNUExTIGxhYmVsIHN0YWNrLiBXaXRoIHN1Y2ggUFQgZmllbGQsIGFueSBr aW5kIG9mIGZ1dHVyZSBNUExTIHBheWxvYWQgKGUuZy4sIG1ldGFkYXRhIGhlYWRlciBvciBOU0gp IGNhbiBiZSBlYXNpbHkgaWRlbnRpZmllZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFp bGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb2Jl cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IHNlZW1zIHRoYXQgdGhl IGNvbmNlcHQgb2Yg4oCccmVmZXJlbmNlX2lk4oCdIGxvb2tzIG11Y2ggc2ltaWxhciB3aXRoIHRo ZSBjb25jZXB0IG9mIOKAnGNvcnJlbGF0b3LigJ0gYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDMuMyBv ZiAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmlqc21hbi1zZmMt bWV0YWRhdGEtY29uc2lkZXJhdGlvbnMtMDAjcGFnZS04Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yaWpzbWFuLXNmYy1tZXRhZGF0YS1jb25zaWRlcmF0aW9ucy0wMCNwYWdlLTg8 L2E+KS4NCiBUaGF04oCZcyB0aGUgY29udGV4dCBJRCBvZiB0aGUgbWV0YWRhdGEgSSBtZWFudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhhdCAmbmJzcDvigJxyZWZl cmVuY2VfaWTigJ0gaXMgYXR0YWNoZWQgdG8gdGhlIE1QTFMgcGFja2V0LCBpdCBzZWVtcyB0aGF0 IHlvdSBzdGlsbCBuZWVkIHNvbWUgd2F5IHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGF0 IOKAnHJlZmVyZW5jZV9pZOKAnSBpbg0KIHRoZSBNUExTIHBhY2tldC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJy YXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE4LCAy MDE0IDM6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1OyBzZmNAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBIb3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBp biBhbiBNUExTIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbGws PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXMgdGhlIGlkZWEgb2YgdXNpbmcgZGF0YSBwbGFuZSB0 byBjYXJyeSBjb21wbGV0ZSBtZXRhZGF0YSBpcyAmcXVvdDt0aGUgd2F5JnF1b3Q7IG9yICZxdW90 O2Egd2F5JnF1b3Q7IG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRoaXMgYmVlbiBh bHJlYWR5IGRpc2N1c3NlZCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSB3b3VsZCByYXRoZXIg Y29uc2lkZXIgdG8gY2FycnkgbWV0YWRhdGEgaW4gY29udHJvbCBwbGFuZSBhbmQgb25seSBhdHRh Y2ggYSByZWZlcmVuY2VfaWQgKGFuZCBvbmx5IHdoZW4gaXQgaXMgbmVlZGVkKSB0byB0aGUgZGF0 YSBwbGFuZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZ3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ui48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gRnJpLCBKdWwgMTgsIDIwMTQgYXQgMzo1OCBBTSwgWHV4aWFvaHUgJmx0OzxhIGhy ZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVA aHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPGJyPg0KPGJyPg0KSSdtIG5v dyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBh Y2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAw ICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ndWljaGFyZC1tcGxz LW1ldGFkYXRhLTAwI3BhZ2UtNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWd1aWNoYXJkLW1wbHMtbWV0YWRhdGEtMDAjcGFnZS02PC9hPikNCiBwcm9w b3NlcyBhIHdheSB0byBjYXJyeSBtZXRhZGF0YS9jb250ZXh0IGluIGFuIE1QTFMgcGFja2V0IChz ZWUgYmVsb3cpOjxicj4NCjxicj4NCiZxdW90OzMuICZuYnNwO01ldGFkYXRhIENoYW5uZWwgSGVh ZGVyIEZvcm1hdDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgcHJlc2VuY2Ugb2YgbWV0YWRh dGEgd2l0aGluIGFuIE1QTFMgcGFja2V0IG11c3QgYmUgaW5kaWNhdGVkIGluPGJyPg0KJm5ic3A7 ICZuYnNwO3RoZSBlbmNhcHN1bGF0aW9uLiAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhh dCB0aGUgRy1BQ2ggR2VuZXJpYzxicj4NCiZuYnNwOyAmbmJzcDtBc3NvY2lhdGVkIENoYW5uZWwg TGFiZWwgKEdBTCkgW1JGQzU1ODZdIHdpdGggbGFiZWwgdmFsdWUgMTMgaXM8YnI+DQombmJzcDsg Jm5ic3A7dXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gJm5ic3A7VGhlIEdBTCBsYWJlbCBwcm92 aWRlcyBhIG1ldGhvZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtpZGVudGlmeSB0aGF0IGEgcGFja2V0 IGNvbnRhaW5zIGFuICZxdW90O0Fzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXIgKEFDSCkmcXVvdDs8 YnI+DQombmJzcDsgJm5ic3A7Zm9sbG93ZWQgYnkgYSBub24tc2VydmljZSBwYXlsb2FkLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtbUkZDNTU4Nl0gaWRlbnRpZmllcyB0aGUgRy1BQ2ggR2VuZXJp YyBBc3NvY2lhdGVkIENoYW5uZWwgYnkgc2V0dGluZzxicj4NCiZuYnNwOyAmbmJzcDt0aGUgZmly c3QgbmliYmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBib3R0b20g bGFiZWw8YnI+DQombmJzcDsgJm5ic3A7aW4gdGhlIHN0YWNrIGlmIHRoZSBHQUwgbGFiZWwgaXMg cHJlc2VudCwgdG8gMDAwMWIuICZuYnNwO0Z1cnRoZXI8YnI+DQombmJzcDsgJm5ic3A7W1JGQzU1 ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRvIGNhcnJ5IHVzZXIgZGF0YTxi cj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljLiAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGFu IGV4dGVuc2lvbiB0byBhbGxvdyB0aGUgZmlyc3Q8YnI+DQombmJzcDsgJm5ic3A7bmliYmxlIG9m IHRoZSBBQ0ggdG8gYmUgc2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBmb2xsb3dpbmcgdGhlIEdBTCwg YmU8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJwcmV0ZWQgdXNpbmcgdGhlIHNlbWFudGljcyBkZWZp bmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1tJLUQuZ3VpY2hhcmQtbWV0YWRhdGEtaGVhZGVyXSB0 byBhbGxvdyBtZXRhZGF0YSB0byBiZSBjYXJyaWVkPGJyPg0KJm5ic3A7ICZuYnNwO3Rocm91Z2gg dGhlIEctQUNoIGNoYW5uZWwuJnF1b3Q7PGJyPg0KPGJyPg0KSG93ZXZlciwgaXQgc2VlbXMgdGhh dCB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIG1lbnRpb25lZCBhYm92ZSBzdGlsbCBj b25mbGljdHMgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBxdW90ZWQgZnJvbSBbUkZDNTU4 Nl06PGJyPg0KPGJyPg0KJnF1b3Q7ICZuYnNwO1RoZSBHQUwgTVVTVCBOT1QgYXBwZWFyIGluIHRo ZSBsYWJlbCBzdGFjayB3aGVuIHRyYW5zcG9ydGluZyBub3JtYWw8YnI+DQombmJzcDsgJm5ic3A7 dXNlci1wbGFuZSBwYWNrZXRzLiAmbmJzcDtGdXJ0aGVybW9yZSwgd2hlbiBwcmVzZW50LCB0aGUg R0FMIE1VU1QgTk9UPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGVhciBtb3JlIHRoYW4gb25jZSBpbiB0 aGUgbGFiZWwgc3RhY2suJnF1b3Q7PGJyPg0KPGJyPg0KSSB3b25kZXIgd2hldGhlciB0aGUgc3Bl Y2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRoZSBhYm92ZSBkcmFmdCB3b3Vs ZCByZXN1bHQgaW4gYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUuIEluIGFkZGl0aW9u LCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgd29ydGh3aGlsZSB0byByZWNvbnNpZGVyIHRoZSBwb3Nz aWJpbGl0eSBvZiBpbnRyb2R1Y2luZyBhIFByb3RvY29sIFR5cGUgKFBUKSBmaWVsZCBpbW1lZGlh dGVseQ0KIGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIE1QTFMgbGFiZWwgc3RhY2suIFdpdGggc3Vj aCBQVCBmaWVsZCwgYW55IGtpbmQgb2YgZnV0dXJlIE1QTFMgcGF5bG9hZCAoZS5nLiwgbWV0YWRh dGEgaGVhZGVyIG9yIE5TSCkgY2FuIGJlIGVhc2lseSBpZGVudGlmaWVkLjxicj4NCjxicj4NCkJl c3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FENKGEML512MBSchi_-- From nobody Fri Jul 18 00:55:40 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8671A0A9C; Fri, 18 Jul 2014 00:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ-z_aVq8Pxe; Fri, 18 Jul 2014 00:55:29 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBE71A04B0; Fri, 18 Jul 2014 00:55:29 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so319351igb.3 for ; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T2lFwYDmBtM8+2GnMLlSibOQnppEj96MkjPN+a1CPFI=; b=SxTGhQcPMeuE7o1JX6lyu98aMgzT0iD6Q8X86UvvEdhBwz643bZ8bSoo3j9XsdAQ5k QVMuK8TfvxZVhwrTDpT8DmBzIieolDz/arykbFNzc2T+pJBUzI4qX4aSBJuU5b37Hxe0 BtpCh8UIYU56tz2RjEo0zCVnWgnxFQl+eA+8QQHjMXeBzpMPuM+S5SsJVaeKxSup80Qt 05JUt+vGGJv3KZs3CD/Cs5ubjUQNcuzAbIUB/bnzKmRDDfIoe7Cgubm1vW+lAFhXxLRn X42PCzaGqiekdbE43W4WbmF1KFDWi+7Xgm6MLeOqx5fJ2+1B8wVm2YKKsprsEDG7OKA8 VhgQ== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr6110768igx.9.1405670128377; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 00:55:28 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082941FE@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 09:55:28 +0200 X-Google-Sender-Auth: TjbOLNw2LsOYkKzlqAbWOPnETgg Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: multipart/alternative; boundary=089e0122a754ac645804fe7314bf Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7BVpfUCcHsDEWgK2Tc1WNtLfOC8 Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 07:55:34 -0000 --089e0122a754ac645804fe7314bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Xu, Yes indeed I do consider proposal from Bruno and Jerome as exact match to what I had in mind with their "correlator" to mine "reference_id". Just terminology nit. Except it is not section 3.3 but 3.5 ... "3.5. Hybrid in-band marking and out-of-band signaling Metadata can be signaled using a hybrid approach combining in-band marking and out-of-band signaling. Each data packet can carry a small fixed-length field which serves as a "correlator". An out-of-band signaling protocol can then be used to map the correlator value to the actual metadata value(s)." > If that =E2=80=9Creference_id=E2=80=9D is attached to the MPLS > packet, it seems that you still need some way to > indicate the presence of that =E2=80=9Creference_id=E2=80=9D in > the MPLS packet. I am not sure we need yet another point solution indicator. We already have two general purpose mechanism which seems like possible indicators which could be used here: * RFC 5331 - MPLS Upstream Label Assignment and Context-Specific Label Spac= e * RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labels Rgs, r. On Fri, Jul 18, 2014 at 9:43 AM, Xuxiaohu wrote: > Hi Robert, > > > > It seems that the concept of =E2=80=9Creference_id=E2=80=9D looks much si= milar with the > concept of =E2=80=9Ccorrelator=E2=80=9D as defined in section 3.3 of ( > http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#p= age-8). > That=E2=80=99s the context ID of the metadata I meant. > > > > If that =E2=80=9Creference_id=E2=80=9D is attached to the MPLS packet, i= t seems that you > still need some way to indicate the presence of that =E2=80=9Creference_i= d=E2=80=9D in the > MPLS packet. > > > > Best regards, > > Xiaohu > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Friday, July 18, 2014 3:27 PM > *To:* Xuxiaohu; sfc@ietf.org > *Cc:* mpls@ietf.org; > *Subject:* Re: [spring] How to carry metadata/context in an MPLS packet > > > > All, > > > > Is the idea of using data plane to carry complete metadata is "the way" o= r > "a way" of approaching the problem ? Has this been already discussed ? > > > > I would rather consider to carry metadata in control plane and only attac= h > a reference_id (and only when it is needed) to the data plane. > > > > Rgs, > > R. > > > > > > > > > > On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introduci= ng > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadat= a > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --089e0122a754ac645804fe7314bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Xu,
Yes indeed I do consider proposal from Bruno and Je= rome as exact match to what I had in mind with their "correlator"= to mine "reference_id". Just terminology nit.=C2=A0

Except it is not = section 3.3 but 3.5 ...

"3.5. H= ybrid in-band marking and out-of-band signaling
Metadata can be signaled using a hybrid approach combining in-= band=C2= =A0marking and out-of-band signaling.
Each data packet can carry a small fixed-length field which se= rves=C2=A0= =C2=A0used to map the correlator value to the actual metadata value(s).&quo= t;


> If that =C2=A0=E2=80=9Creference= _id=E2=80=9D is attached to the MPLS=C2=A0
> packet, it seems = that you still need some way to=C2=A0
&g= t; indicate the presence of that =E2=80=9Creference_id=E2=80=9D in=C2=A0
> the=C2=A0MPLS packet.

I am not sure we need yet another point = solution indicator.=C2=A0
We already have two general purpose mechanism which seems like= possible indicators which could be used here:
* RFC 5331 -=C2=A0MPLS Upstream Label Assignment and Context-S= pecific Label Space
* RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labe= ls

Rgs,
r.

=

On Fri, Jul 18, 2014 at 9:43 AM, Xuxiaoh= u <xuxiaohu@huawei.com> wrote:

Hi Robert,=

=C2= =A0

It seems t= hat the concept of =E2=80=9Creference_id=E2=80=9D looks much similar with t= he concept of =E2=80=9Ccorrelator=E2=80=9D as defined in section 3.3 of (http://tools.ietf.org/html/draft-rijsman-sf= c-metadata-considerations-00#page-8). That=E2=80=99s the context ID of the metadata I meant.

=C2= =A0

If that = =C2=A0=E2=80=9Creference_id=E2=80=9D is attached to the MPLS packet, it see= ms that you still need some way to indicate the presence of that =E2=80=9Cr= eference_id=E2=80=9D in the MPLS packet.

=C2= =A0

Best regar= ds,

Xiaohu<= /u>

=C2= =A0

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, July 18, 2014 3:27 PM
To: Xuxiaohu; sfc@= ietf.org
Cc: mpls@ietf.org= ; <spring@ietf.= org>
Subject: Re: [spring] How to carry metadata/context in an MPLS packe= t

=C2=A0

All,

=C2=A0

Is the idea of using data plane to carry complete metadata i= s "the way" or "a way" of approaching the problem ? Has= this been already discussed ?

=C2=A0

I would rather consider to carry metadata in control plane a= nd only attach a reference_id (and only when it is needed) to the data plan= e.=C2=A0

=C2=A0

Rgs,

R.

=C2=A0

=C2=A0

=C2=A0

= =C2=A0

On Fri, Jul 18, 2014 at 3:58 AM= , Xuxiaohu <xux= iaohu@huawei.com> wrote:

Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/context in an MPLS packet (see below):
"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stack. With such PT field, any kind of = future MPLS payload (e.g., metadata header or NSH) can be easily identified= .

Best regards,
Xiaohu

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

=C2=A0


--089e0122a754ac645804fe7314bf-- From nobody Fri Jul 18 03:32:05 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A361A02AC; Fri, 18 Jul 2014 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qKpH3Ry7bMr; Fri, 18 Jul 2014 03:32:00 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DED1A015B; Fri, 18 Jul 2014 03:32:00 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so437038igb.11 for ; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Wg8hM8zV2Lt1xr3k3QA0ORZp6KMOD4WVf7lMt5EkJRs=; b=CfVhg/jDs8r6KT/R8boqMLc8xey2jMejneELhOsteTc0vfqibmpsFii/zfVA8ypFYv 7MOuQoFkXrfyO04+nuEHf25TzLlPAx+d3mHmgGEx0eXLbJWtlAkRI/z2fEM/Kw8D4vVL qh/Ex3bV6Rxfq6r9SPieReudNRY439chcDwpshz9vbbVReOpcB3DeFv8fRtyXUv4NG+P 4Z2vSPjrKCkP30naj7VwyqEBPJnnYt5bpA9mU3U2r76mo66sTHhvg6tfZ/cnRq1j8WAn 2wJH9doSD/UMc71FZ2PE1+J1hxwiVdXaEXojzdStfr1olnhO8TyNymlcu6C9IwSmRIgK 3HcA== MIME-Version: 1.0 X-Received: by 10.50.114.194 with SMTP id ji2mr7301657igb.21.1405679519463; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 03:31:59 -0700 (PDT) In-Reply-To: <1405653745773.33083@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> <1405653745773.33083@surrey.ac.uk> Date: Fri, 18 Jul 2014 12:31:59 +0200 X-Google-Sender-Auth: 6-Ta-eolvAUYzakfS_e3j1eUdoA Message-ID: From: Robert Raszuk To: l.wood@surrey.ac.uk Content-Type: multipart/alternative; boundary=089e013a0c686d018504fe754460 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/sVBs2IDWJ_2XtFb_T5t0YX_-IA4 Cc: mpls@ietf.org, spring@ietf.org, xuxiaohu@huawei.com, sfc@ietf.org Subject: Re: [spring] [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:32:02 -0000 --089e013a0c686d018504fe754460 Content-Type: text/plain; charset=UTF-8 Hi Lloyd, I think and I do hope that we see only mpls centric proposals as this is one encapsulation used in the networks. I hope other proposals will also address v6 encapsulations and that any encapsulation will use same metadata control plane. Best, R. On Jul 18, 2014 12:23 PM, wrote: > No, my "why" is "why have metadata in the MPLS header at all"? > > Why does this have to be done inband? > > I am questioning the basis for doing this. There is no "must" here. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Xuxiaohu > Sent: Friday, 18 July 2014 1:17 PM > To: Wood L Dr (Electronic Eng); mpls@ietf.org > Cc: spring@ietf.org; sfc@ietf.org > Subject: RE: How to carry metadata/context in an MPLS packet > > The presence of metadata within an MPLS packet must be indicated in the > encapsulation. I think that's the "why" you may want to know. > > Best regards, > Xiaohu > > > -----Original Message----- > > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > Sent: Friday, July 18, 2014 11:11 AM > > To: Xuxiaohu; mpls@ietf.org > > Cc: spring@ietf.org; sfc@ietf.org > > Subject: RE: How to carry metadata/context in an MPLS packet > > > > How? A better question is "why?" > > > > What has to be done in MPLS that cannot be done outside it? > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: mpls on behalf of Xuxiaohu > > > > Sent: Friday, 18 July 2014 11:58 AM > > To: mpls@ietf.org > > Cc: ; sfc@ietf.org > > Subject: [mpls] How to carry metadata/context in an MPLS packet > > > > Hi all, > > > > I'm now considering how to carry metadata/context in an MPLS packet. I > just > > noticed that draft-guichard-mpls-metadata-00 > > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes > > a way to carry metadata/context in an MPLS packet (see below): > > > > "3. Metadata Channel Header Format > > > > The presence of metadata within an MPLS packet must be indicated in > > the encapsulation. This document defines that the G-ACh Generic > > Associated Channel Label (GAL) [RFC5586] with label value 13 is > > utilized for this purpose. The GAL label provides a method to > > identify that a packet contains an "Associated Channel Header (ACH)" > > followed by a non-service payload. > > > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > > the first nibble of the ACH that immediately follows the bottom label > > in the stack if the GAL label is present, to 0001b. Further > > [RFC5586] expects that the ACH not be used to carry user data > > traffic. This document proposes an extension to allow the first > > nibble of the ACH to be set to 0000b and, when following the GAL, be > > interpreted using the semantics defined in > > [I-D.guichard-metadata-header] to allow metadata to be carried > > through the G-ACh channel." > > > > However, it seems that the special usage of the GAL as mentioned above > still > > conflicts with the following statement quoted from [RFC5586]: > > > > " The GAL MUST NOT appear in the label stack when transporting normal > > user-plane packets. Furthermore, when present, the GAL MUST NOT > > appear more than once in the label stack." > > > > I wonder whether the special usage of the GAL as proposed in the above > draft > > would result in any backward compatibility issue. In addition, I wonder > whether > > it's worthwhile to reconsider the possibility of introducing a Protocol > Type (PT) > > field immediately after the bottom of the MPLS label stack. With such PT > field, > > any kind of future MPLS payload (e.g., metadata header or NSH) can be > easily > > identified. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --089e013a0c686d018504fe754460 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Lloyd,

I think and I do hope that we see only mpls centric proposal= s as this is one encapsulation used in the networks.

I hope other proposals will also address v6 encapsulations a= nd that any encapsulation will use same metadata control plane.

Best,
R.

On Jul 18, 2014 12:23 PM, <l.wood@surrey.ac.uk> wrote:
No, my "why" is "why have metadata in the MPLS header at all= "?

Why does this have to be done inband?

I am questioning the basis for doing this. There is no "must" her= e.

Lloyd Wood
http://about.me/llo= ydwood
________________________________________
From: Xuxiaohu <xuxiaohu@huawei.c= om>
Sent: Friday, 18 July 2014 1:17 PM
To: Wood L =C2=A0Dr (Electronic Eng); mpls= @ietf.org
Cc: spring@ietf.org; sfc@ietf.org
Subject: RE: How to carry metadata/context in an MPLS packet

The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know.
Best regards,
Xiaohu

> -----Original Message-----
> From: l.wood@surrey.ac.uk [= mailto:l.wood@surrey.ac.uk]
> Sent: Friday, July 18, 2014 11:11 AM
> To: Xuxiaohu; mpls@ietf.org
> Cc: spring@ietf.org; sfc@ietf.org
> Subject: RE: How to carry metadata/context in an MPLS packet
>
> How? A better question is "why?"
>
> What has to be done in MPLS that cannot be done outside it?
>
> Lloyd Wood
> http://about.m= e/lloydwood
> ________________________________________
> From: mpls <mpls-bounces@i= etf.org> on behalf of Xuxiaohu
> <xuxiaohu@huawei.com>=
> Sent: Friday, 18 July 2014 11:58 AM
> To: mpls@ietf.org
> Cc: <spring@ietf.org>; sfc@ietf.org
> Subject: [mpls] How to carry metadata/context in an MPLS packet
>
> Hi all,
>
> I'm now considering how to carry metadata/context in an MPLS packe= t. I just
> noticed that draft-guichard-mpls-metadata-00
> (http://tools.ietf.org/html/draft-guichard-mpls-m= etadata-00#page-6) proposes
> a way to carry metadata/context in an MPLS packet (see below):
>
> "3. =C2=A0Metadata Channel Header Format
>
> =C2=A0 =C2=A0The presence of metadata within an MPLS packet must be in= dicated in
> =C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G= -ACh Generic
> =C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value= 13 is
> =C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a= method to
> =C2=A0 =C2=A0identify that a packet contains an "Associated Chann= el Header (ACH)"
> =C2=A0 =C2=A0followed by a non-service payload.
>
> =C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel= by setting
> =C2=A0 =C2=A0the first nibble of the ACH that immediately follows the = bottom label
> =C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2= =A0Further
> =C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user = data
> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to all= ow the first
> =C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following = the GAL, be
> =C2=A0 =C2=A0interpreted using the semantics defined in
> =C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be ca= rried
> =C2=A0 =C2=A0through the G-ACh channel."
>
> However, it seems that the special usage of the GAL as mentioned above= still
> conflicts with the following statement quoted from [RFC5586]:
>
> " =C2=A0The GAL MUST NOT appear in the label stack when transport= ing normal
> =C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the = GAL MUST NOT
> =C2=A0 =C2=A0appear more than once in the label stack."
>
> I wonder whether the special usage of the GAL as proposed in the above= draft
> would result in any backward compatibility issue. In addition, I wonde= r whether
> it's worthwhile to reconsider the possibility of introducing a Pro= tocol Type (PT)
> field immediately after the bottom of the MPLS label stack. With such = PT field,
> any kind of future MPLS payload (e.g., metadata header or NSH) can be = easily
> identified.
>
> Best regards,
> Xiaohu
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
sfc mailing list
sfc@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/sfc
--089e013a0c686d018504fe754460-- From nobody Fri Jul 18 05:05:38 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28AB1B2970; Fri, 18 Jul 2014 05:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4v3_gcWK1fO; Fri, 18 Jul 2014 05:05:33 -0700 (PDT) Received: from relay.emg-ca-1.securemail.intermedia.net (relay.emg-ca-1.securemail.intermedia.net [64.78.56.32]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCCF1A0ABE; Fri, 18 Jul 2014 05:05:33 -0700 (PDT) Received: from emg-ca-1-2 (localhost [127.0.0.1]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id D3F6653E19; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) MIME-Version: 1.0 x-echoworx-emg-received: Fri, 18 Jul 2014 05:05:28.807 -0700 x-echoworx-msg-id: e780d1aa-f0b6-47f6-aee8-b5d2e1b686c1 x-echoworx-action: delivered Received: from localhost ([127.0.0.1]) by emg-ca-1-2 (JAMES SMTP Server 2.3.2) with SMTP ID 819; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) Received: from HUB021-CA-3.exch021.domain.local (unknown [10.254.4.36]) by emg-ca-1-2.localdomain (Postfix) with ESMTP id ACA6553E19; Fri, 18 Jul 2014 05:05:28 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0174.001; Fri, 18 Jul 2014 05:05:33 -0700 From: Ron Parker To: Robert Raszuk , Xuxiaohu , "sfc@ietf.org" Thread-Topic: [sfc] [spring] How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwAaH8sAAAUge5A= Date: Fri, 18 Jul 2014 12:05:32 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] x-source-routing-agent: Processed Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_" Archived-At: http://mailarchive.ietf.org/arch/msg/spring/46GfoNwOKuKboDoWMIp-vkxNTxM Cc: "mpls@ietf.org" , "" Subject: Re: [spring] [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 12:05:37 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpJbmJhbmQgaXMgb25lIHdheSAtLSBpdCBzaW1wbGlmaWVzIHRoaW5ncyBhdCB0 aGUgY29zdCBvZiBwYWNrZXQgZ3Jvd3RoLiAgIE91dC1vZi1iYW5kIChpLmUuLCBzaWduYWxpbmcp IGlzIGFub3RoZXIgd2F5IOKAkyBpdCBhZGRzIGNvbXBsZXhpdHkgYnV0IGRvZXNu4oCZdCBncm93 IHRoZSBkYXRhIHBsYW5lIHBhY2tldHMuICAgQ29uZ3J1ZW50IG91dC1vZi1iYW5kIGlzIGEgdmFy aWF0aW9uIG9uIG91dC1vZi1iYW5kIHRoYXQgbWF5IHBhcnRpYWxseSByZWR1Y2Ugb3V0LW9mLWJh bmQgY29tcGxleGl0eS4gICAgSSB0aGluayBtYW55IG9waW5pb25zIG9uIHRoZSB0aHJlYWQgaGF2 ZSBiZWVuIHRoYXQgYWxsIGFyZSBpbiBzY29wZSwgYXJjaGl0ZWN0dXJhbGx5LiAgICBEcmFmdC16 aGFuZy1zZmMtc2NoIChJIGFtIGEgY28tYXV0aG9yKSwgZm9yIGV4YW1wbGUsIGRlZmluZXMgaW5i YW5kIG1ldGFkYXRhIGV4cGxpY2l0bHksIGJ1dCBzdGF0ZXMgaW4gdGV4dCB0aGF0IG91dC1vZi1i YW5kIGlzIHBvc3NpYmxlLCB0b28uICAgIEnigJltIHN1cmUgdGhpcyB3aWxsIGJlIGEgdG9waWMg b2YgZGlzY3Vzc2lvbiB3aGVuIHdlIHN0YXJ0IGRpc2N1c3NpbmcgY29udHJvbCBwbGFuZSByZXF1 aXJlbWVudHMuDQoNCiAgIFJvbg0KDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IEZyaWRheSwgSnVseSAxOCwg MjAxNCAzOjI3IEFNDQpUbzogWHV4aWFvaHU7IHNmY0BpZXRmLm9yZw0KQ2M6IG1wbHNAaWV0Zi5v cmc7IDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gW3NwcmluZ10gSG93IHRv IGNhcnJ5IG1ldGFkYXRhL2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQNCg0KQWxsLA0KDQpJcyB0 aGUgaWRlYSBvZiB1c2luZyBkYXRhIHBsYW5lIHRvIGNhcnJ5IGNvbXBsZXRlIG1ldGFkYXRhIGlz ICJ0aGUgd2F5IiBvciAiYSB3YXkiIG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRo aXMgYmVlbiBhbHJlYWR5IGRpc2N1c3NlZCA/DQoNCkkgd291bGQgcmF0aGVyIGNvbnNpZGVyIHRv IGNhcnJ5IG1ldGFkYXRhIGluIGNvbnRyb2wgcGxhbmUgYW5kIG9ubHkgYXR0YWNoIGEgcmVmZXJl bmNlX2lkIChhbmQgb25seSB3aGVuIGl0IGlzIG5lZWRlZCkgdG8gdGhlIGRhdGEgcGxhbmUuDQoN ClJncywNClIuDQoNCg0KDQoNCk9uIEZyaSwgSnVsIDE4LCAyMDE0IGF0IDM6NTggQU0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSBhbGwsDQoNCkknbSBub3cgY29uc2lkZXJpbmcgaG93IHRvIGNhcnJ5IG1ldGFkYXRh L2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQuIEkganVzdCBub3RpY2VkIHRoYXQgZHJhZnQtZ3Vp Y2hhcmQtbXBscy1tZXRhZGF0YS0wMCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Z3VpY2hhcmQtbXBscy1tZXRhZGF0YS0wMCNwYWdlLTYpIHByb3Bvc2VzIGEgd2F5IHRvIGNhcnJ5 IG1ldGFkYXRhL2NvbnRleHQgaW4gYW4gTVBMUyBwYWNrZXQgKHNlZSBiZWxvdyk6DQoNCiIzLiAg TWV0YWRhdGEgQ2hhbm5lbCBIZWFkZXIgRm9ybWF0DQoNCiAgIFRoZSBwcmVzZW5jZSBvZiBtZXRh ZGF0YSB3aXRoaW4gYW4gTVBMUyBwYWNrZXQgbXVzdCBiZSBpbmRpY2F0ZWQgaW4NCiAgIHRoZSBl bmNhcHN1bGF0aW9uLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoYXQgdGhlIEctQUNoIEdlbmVy aWMNCiAgIEFzc29jaWF0ZWQgQ2hhbm5lbCBMYWJlbCAoR0FMKSBbUkZDNTU4Nl0gd2l0aCBsYWJl bCB2YWx1ZSAxMyBpcw0KICAgdXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gIFRoZSBHQUwgbGFi ZWwgcHJvdmlkZXMgYSBtZXRob2QgdG8NCiAgIGlkZW50aWZ5IHRoYXQgYSBwYWNrZXQgY29udGFp bnMgYW4gIkFzc29jaWF0ZWQgQ2hhbm5lbCBIZWFkZXIgKEFDSCkiDQogICBmb2xsb3dlZCBieSBh IG5vbi1zZXJ2aWNlIHBheWxvYWQuDQoNCiAgIFtSRkM1NTg2XSBpZGVudGlmaWVzIHRoZSBHLUFD aCBHZW5lcmljIEFzc29jaWF0ZWQgQ2hhbm5lbCBieSBzZXR0aW5nDQogICB0aGUgZmlyc3Qgbmli YmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBmb2xsb3dzIHRoZSBib3R0b20gbGFiZWwN CiAgIGluIHRoZSBzdGFjayBpZiB0aGUgR0FMIGxhYmVsIGlzIHByZXNlbnQsIHRvIDAwMDFiLiAg RnVydGhlcg0KICAgW1JGQzU1ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRv IGNhcnJ5IHVzZXIgZGF0YQ0KICAgdHJhZmZpYy4gIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4g ZXh0ZW5zaW9uIHRvIGFsbG93IHRoZSBmaXJzdA0KICAgbmliYmxlIG9mIHRoZSBBQ0ggdG8gYmUg c2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBmb2xsb3dpbmcgdGhlIEdBTCwgYmUNCiAgIGludGVycHJl dGVkIHVzaW5nIHRoZSBzZW1hbnRpY3MgZGVmaW5lZCBpbg0KICAgW0ktRC5ndWljaGFyZC1tZXRh ZGF0YS1oZWFkZXJdIHRvIGFsbG93IG1ldGFkYXRhIHRvIGJlIGNhcnJpZWQNCiAgIHRocm91Z2gg dGhlIEctQUNoIGNoYW5uZWwuIg0KDQpIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZSBzcGVjaWFs IHVzYWdlIG9mIHRoZSBHQUwgYXMgbWVudGlvbmVkIGFib3ZlIHN0aWxsIGNvbmZsaWN0cyB3aXRo IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IHF1b3RlZCBmcm9tIFtSRkM1NTg2XToNCg0KIiAgVGhl IEdBTCBNVVNUIE5PVCBhcHBlYXIgaW4gdGhlIGxhYmVsIHN0YWNrIHdoZW4gdHJhbnNwb3J0aW5n IG5vcm1hbA0KICAgdXNlci1wbGFuZSBwYWNrZXRzLiAgRnVydGhlcm1vcmUsIHdoZW4gcHJlc2Vu dCwgdGhlIEdBTCBNVVNUIE5PVA0KICAgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIGluIHRoZSBsYWJl bCBzdGFjay4iDQoNCkkgd29uZGVyIHdoZXRoZXIgdGhlIHNwZWNpYWwgdXNhZ2Ugb2YgdGhlIEdB TCBhcyBwcm9wb3NlZCBpbiB0aGUgYWJvdmUgZHJhZnQgd291bGQgcmVzdWx0IGluIGFueSBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IGlzc3VlLiBJbiBhZGRpdGlvbiwgSSB3b25kZXIgd2hldGhlciBp dCdzIHdvcnRod2hpbGUgdG8gcmVjb25zaWRlciB0aGUgcG9zc2liaWxpdHkgb2YgaW50cm9kdWNp bmcgYSBQcm90b2NvbCBUeXBlIChQVCkgZmllbGQgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIGJvdHRv bSBvZiB0aGUgTVBMUyBsYWJlbCBzdGFjay4gV2l0aCBzdWNoIFBUIGZpZWxkLCBhbnkga2luZCBv ZiBmdXR1cmUgTVBMUyBwYXlsb2FkIChlLmcuLCBtZXRhZGF0YSBoZWFkZXIgb3IgTlNIKSBjYW4g YmUgZWFzaWx5IGlkZW50aWZpZWQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcg bGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvYmVydCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkluYmFuZCBpcyBvbmUgd2F5IC0tIGl0IHNpbXBsaWZpZXMgdGhpbmdzIGF0IHRo ZSBjb3N0IG9mIHBhY2tldCBncm93dGguJm5ic3A7Jm5ic3A7IE91dC1vZi1iYW5kIChpLmUuLCBz aWduYWxpbmcpIGlzIGFub3RoZXIgd2F5IOKAkyBpdCBhZGRzIGNvbXBsZXhpdHkgYnV0IGRvZXNu 4oCZdCBncm93DQogdGhlIGRhdGEgcGxhbmUgcGFja2V0cy4mbmJzcDsmbmJzcDsgQ29uZ3J1ZW50 IG91dC1vZi1iYW5kIGlzIGEgdmFyaWF0aW9uIG9uIG91dC1vZi1iYW5kIHRoYXQgbWF5IHBhcnRp YWxseSByZWR1Y2Ugb3V0LW9mLWJhbmQgY29tcGxleGl0eS4mbmJzcDsmbmJzcDsmbmJzcDsgSSB0 aGluayBtYW55IG9waW5pb25zIG9uIHRoZSB0aHJlYWQgaGF2ZSBiZWVuIHRoYXQgYWxsIGFyZSBp biBzY29wZSwgYXJjaGl0ZWN0dXJhbGx5LiZuYnNwOyZuYnNwOyZuYnNwOyBEcmFmdC16aGFuZy1z ZmMtc2NoIChJIGFtIGEgY28tYXV0aG9yKSwNCiBmb3IgZXhhbXBsZSwgZGVmaW5lcyBpbmJhbmQg bWV0YWRhdGEgZXhwbGljaXRseSwgYnV0IHN0YXRlcyBpbiB0ZXh0IHRoYXQgb3V0LW9mLWJhbmQg aXMgcG9zc2libGUsIHRvby4mbmJzcDsmbmJzcDsmbmJzcDsgSeKAmW0gc3VyZSB0aGlzIHdpbGwg YmUgYSB0b3BpYyBvZiBkaXNjdXNzaW9uIHdoZW4gd2Ugc3RhcnQgZGlzY3Vzc2luZyBjb250cm9s IHBsYW5lIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBKdWx5IDE4LCAyMDE0IDM6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IFh1 eGlhb2h1OyBzZmNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7ICZsdDtz cHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2ZjXSBbc3ByaW5n XSBIb3cgdG8gY2FycnkgbWV0YWRhdGEvY29udGV4dCBpbiBhbiBNUExTIHBhY2tldDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SXMgdGhlIGlkZWEgb2YgdXNpbmcgZGF0 YSBwbGFuZSB0byBjYXJyeSBjb21wbGV0ZSBtZXRhZGF0YSBpcyAmcXVvdDt0aGUgd2F5JnF1b3Q7 IG9yICZxdW90O2Egd2F5JnF1b3Q7IG9mIGFwcHJvYWNoaW5nIHRoZSBwcm9ibGVtID8gSGFzIHRo aXMgYmVlbiBhbHJlYWR5IGRpc2N1c3NlZCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgd291bGQgcmF0aGVyIGNvbnNpZGVyIHRvIGNhcnJ5 IG1ldGFkYXRhIGluIGNvbnRyb2wgcGxhbmUgYW5kIG9ubHkgYXR0YWNoIGEgcmVmZXJlbmNlX2lk IChhbmQgb25seSB3aGVuIGl0IGlzIG5lZWRlZCkgdG8gdGhlIGRhdGEgcGxhbmUuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJncyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDE4LCAyMDE0 IGF0IDM6NTggQU0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGws PGJyPg0KPGJyPg0KSSdtIG5vdyBjb25zaWRlcmluZyBob3cgdG8gY2FycnkgbWV0YWRhdGEvY29u dGV4dCBpbiBhbiBNUExTIHBhY2tldC4gSSBqdXN0IG5vdGljZWQgdGhhdCBkcmFmdC1ndWljaGFy ZC1tcGxzLW1ldGFkYXRhLTAwICg8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1ndWljaGFyZC1tcGxzLW1ldGFkYXRhLTAwI3BhZ2UtNiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWd1aWNoYXJkLW1wbHMtbWV0YWRhdGEtMDAj cGFnZS02PC9hPikNCiBwcm9wb3NlcyBhIHdheSB0byBjYXJyeSBtZXRhZGF0YS9jb250ZXh0IGlu IGFuIE1QTFMgcGFja2V0IChzZWUgYmVsb3cpOjxicj4NCjxicj4NCiZxdW90OzMuICZuYnNwO01l dGFkYXRhIENoYW5uZWwgSGVhZGVyIEZvcm1hdDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUg cHJlc2VuY2Ugb2YgbWV0YWRhdGEgd2l0aGluIGFuIE1QTFMgcGFja2V0IG11c3QgYmUgaW5kaWNh dGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO3RoZSBlbmNhcHN1bGF0aW9uLiAmbmJzcDtUaGlzIGRv Y3VtZW50IGRlZmluZXMgdGhhdCB0aGUgRy1BQ2ggR2VuZXJpYzxicj4NCiZuYnNwOyAmbmJzcDtB c3NvY2lhdGVkIENoYW5uZWwgTGFiZWwgKEdBTCkgW1JGQzU1ODZdIHdpdGggbGFiZWwgdmFsdWUg MTMgaXM8YnI+DQombmJzcDsgJm5ic3A7dXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZS4gJm5ic3A7 VGhlIEdBTCBsYWJlbCBwcm92aWRlcyBhIG1ldGhvZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtpZGVu dGlmeSB0aGF0IGEgcGFja2V0IGNvbnRhaW5zIGFuICZxdW90O0Fzc29jaWF0ZWQgQ2hhbm5lbCBI ZWFkZXIgKEFDSCkmcXVvdDs8YnI+DQombmJzcDsgJm5ic3A7Zm9sbG93ZWQgYnkgYSBub24tc2Vy dmljZSBwYXlsb2FkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtbUkZDNTU4Nl0gaWRlbnRpZmll cyB0aGUgRy1BQ2ggR2VuZXJpYyBBc3NvY2lhdGVkIENoYW5uZWwgYnkgc2V0dGluZzxicj4NCiZu YnNwOyAmbmJzcDt0aGUgZmlyc3QgbmliYmxlIG9mIHRoZSBBQ0ggdGhhdCBpbW1lZGlhdGVseSBm b2xsb3dzIHRoZSBib3R0b20gbGFiZWw8YnI+DQombmJzcDsgJm5ic3A7aW4gdGhlIHN0YWNrIGlm IHRoZSBHQUwgbGFiZWwgaXMgcHJlc2VudCwgdG8gMDAwMWIuICZuYnNwO0Z1cnRoZXI8YnI+DQom bmJzcDsgJm5ic3A7W1JGQzU1ODZdIGV4cGVjdHMgdGhhdCB0aGUgQUNIIG5vdCBiZSB1c2VkIHRv IGNhcnJ5IHVzZXIgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljLiAmbmJzcDtUaGlzIGRv Y3VtZW50IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiB0byBhbGxvdyB0aGUgZmlyc3Q8YnI+DQombmJz cDsgJm5ic3A7bmliYmxlIG9mIHRoZSBBQ0ggdG8gYmUgc2V0IHRvIDAwMDBiIGFuZCwgd2hlbiBm b2xsb3dpbmcgdGhlIEdBTCwgYmU8YnI+DQombmJzcDsgJm5ic3A7aW50ZXJwcmV0ZWQgdXNpbmcg dGhlIHNlbWFudGljcyBkZWZpbmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwO1tJLUQuZ3VpY2hhcmQt bWV0YWRhdGEtaGVhZGVyXSB0byBhbGxvdyBtZXRhZGF0YSB0byBiZSBjYXJyaWVkPGJyPg0KJm5i c3A7ICZuYnNwO3Rocm91Z2ggdGhlIEctQUNoIGNoYW5uZWwuJnF1b3Q7PGJyPg0KPGJyPg0KSG93 ZXZlciwgaXQgc2VlbXMgdGhhdCB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIG1lbnRp b25lZCBhYm92ZSBzdGlsbCBjb25mbGljdHMgd2l0aCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBx dW90ZWQgZnJvbSBbUkZDNTU4Nl06PGJyPg0KPGJyPg0KJnF1b3Q7ICZuYnNwO1RoZSBHQUwgTVVT VCBOT1QgYXBwZWFyIGluIHRoZSBsYWJlbCBzdGFjayB3aGVuIHRyYW5zcG9ydGluZyBub3JtYWw8 YnI+DQombmJzcDsgJm5ic3A7dXNlci1wbGFuZSBwYWNrZXRzLiAmbmJzcDtGdXJ0aGVybW9yZSwg d2hlbiBwcmVzZW50LCB0aGUgR0FMIE1VU1QgTk9UPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGVhciBt b3JlIHRoYW4gb25jZSBpbiB0aGUgbGFiZWwgc3RhY2suJnF1b3Q7PGJyPg0KPGJyPg0KSSB3b25k ZXIgd2hldGhlciB0aGUgc3BlY2lhbCB1c2FnZSBvZiB0aGUgR0FMIGFzIHByb3Bvc2VkIGluIHRo ZSBhYm92ZSBkcmFmdCB3b3VsZCByZXN1bHQgaW4gYW55IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg aXNzdWUuIEluIGFkZGl0aW9uLCBJIHdvbmRlciB3aGV0aGVyIGl0J3Mgd29ydGh3aGlsZSB0byBy ZWNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRyb2R1Y2luZyBhIFByb3RvY29sIFR5cGUg KFBUKSBmaWVsZCBpbW1lZGlhdGVseQ0KIGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIE1QTFMgbGFi ZWwgc3RhY2suIFdpdGggc3VjaCBQVCBmaWVsZCwgYW55IGtpbmQgb2YgZnV0dXJlIE1QTFMgcGF5 bG9hZCAoZS5nLiwgbWV0YWRhdGEgaGVhZGVyIG9yIE5TSCkgY2FuIGJlIGVhc2lseSBpZGVudGlm aWVkLjxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A8BC971MBX021W3CA2exch_-- From nobody Fri Jul 18 06:02:41 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1591A0422; Thu, 17 Jul 2014 20:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGCejJ-K_QkV; Thu, 17 Jul 2014 20:11:01 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02191A0417; Thu, 17 Jul 2014 20:11:00 -0700 (PDT) Received: from [85.158.137.99:58985] by server-3.bemta-3.messagelabs.com id BC/A8-08876-24098C35; Fri, 18 Jul 2014 03:10:58 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-15.tower-217.messagelabs.com!1405653058!22628557!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22524 invoked from network); 18 Jul 2014 03:10:58 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2014 03:10:58 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 18 Jul 2014 04:10:58 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 18 Jul 2014 04:10:57 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) with Microsoft SMTP Server (TLS) id 15.0.985.8; Fri, 18 Jul 2014 03:10:57 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0985.008; Fri, 18 Jul 2014 03:10:57 +0000 From: To: , Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZj Date: Fri, 18 Jul 2014 03:10:56 +0000 Message-ID: <1405653056176.39234@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(53754006)(377454003)(199002)(189002)(107046002)(54356999)(46102001)(19580395003)(50986999)(4396001)(95666004)(74482001)(99396002)(66066001)(86362001)(19580405001)(15395725005)(81342001)(81542001)(105586002)(76482001)(15975445006)(36756003)(20776003)(31966008)(85306003)(74502001)(92566001)(83072002)(83322001)(77982001)(15198665003)(85852003)(79102001)(64706001)(80022001)(74662001)(101416001)(76176999)(21056001)(15202345003)(2656002)(106356001)(87936001)(92726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB438; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB438.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/spring/TRfkeRiqACjPs3M7pnEyAX3wx98 X-Mailman-Approved-At: Fri, 18 Jul 2014 06:02:37 -0700 Cc: spring@ietf.org, sfc@ietf.org Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:11:03 -0000 How? A better question is "why?"=0A= =0A= What has to be done in MPLS that cannot be done outside it?=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: mpls on behalf of Xuxiaohu =0A= Sent: Friday, 18 July 2014 11:58 AM=0A= To: mpls@ietf.org=0A= Cc: ; sfc@ietf.org=0A= Subject: [mpls] How to carry metadata/context in an MPLS packet=0A= =0A= Hi all,=0A= =0A= I'm now considering how to carry metadata/context in an MPLS packet. I just= noticed that draft-guichard-mpls-metadata-00 (http://tools.ietf.org/html/d= raft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/con= text in an MPLS packet (see below):=0A= =0A= "3. Metadata Channel Header Format=0A= =0A= The presence of metadata within an MPLS packet must be indicated in=0A= the encapsulation. This document defines that the G-ACh Generic=0A= Associated Channel Label (GAL) [RFC5586] with label value 13 is=0A= utilized for this purpose. The GAL label provides a method to=0A= identify that a packet contains an "Associated Channel Header (ACH)"=0A= followed by a non-service payload.=0A= =0A= [RFC5586] identifies the G-ACh Generic Associated Channel by setting=0A= the first nibble of the ACH that immediately follows the bottom label=0A= in the stack if the GAL label is present, to 0001b. Further=0A= [RFC5586] expects that the ACH not be used to carry user data=0A= traffic. This document proposes an extension to allow the first=0A= nibble of the ACH to be set to 0000b and, when following the GAL, be=0A= interpreted using the semantics defined in=0A= [I-D.guichard-metadata-header] to allow metadata to be carried=0A= through the G-ACh channel."=0A= =0A= However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:=0A= =0A= " The GAL MUST NOT appear in the label stack when transporting normal=0A= user-plane packets. Furthermore, when present, the GAL MUST NOT=0A= appear more than once in the label stack."=0A= =0A= I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a Proto= col Type (PT) field immediately after the bottom of the MPLS label stack. W= ith such PT field, any kind of future MPLS payload (e.g., metadata header o= r NSH) can be easily identified.=0A= =0A= Best regards,=0A= Xiaohu=0A= =0A= _______________________________________________=0A= mpls mailing list=0A= mpls@ietf.org=0A= https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Fri Jul 18 06:02:49 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8611B286B; Thu, 17 Jul 2014 20:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYvBqc935G2I; Thu, 17 Jul 2014 20:22:31 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.150]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777A41A0418; Thu, 17 Jul 2014 20:22:30 -0700 (PDT) Received: from [195.245.231.67:51838] by server-14.bemta-5.messagelabs.com id 1C/47-11783-5F298C35; Fri, 18 Jul 2014 03:22:29 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1405653747!39396238!6 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5082 invoked from network); 18 Jul 2014 03:22:28 -0000 Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jul 2014 03:22:28 -0000 Received: from EXHY011V.surrey.ac.uk (131.227.200.103) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 18 Jul 2014 04:22:27 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 18 Jul 2014 04:22:26 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.985.8; Fri, 18 Jul 2014 03:22:26 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0985.008; Fri, 18 Jul 2014 03:22:26 +0000 From: To: , Thread-Topic: How to carry metadata/context in an MPLS packet Thread-Index: Ac+iK9IiUw61Lt1oTZi1TxTMkTltPwACfNZjAAAtuoAAADRSVw== Date: Fri, 18 Jul 2014 03:22:26 +0000 Message-ID: <1405653745773.33083@surrey.ac.uk> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> <1405653056176.39234@surrey.ac.uk>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294173@NKGEML512-MBS.china.huawei.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.200.59.30] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51444003)(53754006)(51704005)(13464003)(199002)(189002)(377454003)(83322001)(64706001)(66066001)(20776003)(76176999)(87936001)(15975445006)(50986999)(19580405001)(95666004)(54356999)(101416001)(105586002)(85306003)(107046002)(76482001)(46102001)(92566001)(36756003)(15395725005)(19580395003)(77982001)(74662001)(79102001)(86362001)(74502001)(4396001)(2656002)(106356001)(31966008)(92726001)(85852003)(81542001)(83072002)(81342001)(21056001)(15202345003)(99396002)(74482001)(15198665003)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY011v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY011v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/spring/CKYjz0k6mwqRnOmJXt4Jw20LItU X-Mailman-Approved-At: Fri, 18 Jul 2014 06:02:37 -0700 Cc: spring@ietf.org, sfc@ietf.org Subject: Re: [spring] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 03:22:33 -0000 No, my "why" is "why have metadata in the MPLS header at all"?=0A= =0A= Why does this have to be done inband?=0A= =0A= I am questioning the basis for doing this. There is no "must" here.=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: Xuxiaohu =0A= Sent: Friday, 18 July 2014 1:17 PM=0A= To: Wood L Dr (Electronic Eng); mpls@ietf.org=0A= Cc: spring@ietf.org; sfc@ietf.org=0A= Subject: RE: How to carry metadata/context in an MPLS packet=0A= =0A= The presence of metadata within an MPLS packet must be indicated in the enc= apsulation. I think that's the "why" you may want to know.=0A= =0A= Best regards,=0A= Xiaohu=0A= =0A= > -----Original Message-----=0A= > From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]=0A= > Sent: Friday, July 18, 2014 11:11 AM=0A= > To: Xuxiaohu; mpls@ietf.org=0A= > Cc: spring@ietf.org; sfc@ietf.org=0A= > Subject: RE: How to carry metadata/context in an MPLS packet=0A= >=0A= > How? A better question is "why?"=0A= >=0A= > What has to be done in MPLS that cannot be done outside it?=0A= >=0A= > Lloyd Wood=0A= > http://about.me/lloydwood=0A= > ________________________________________=0A= > From: mpls on behalf of Xuxiaohu=0A= > =0A= > Sent: Friday, 18 July 2014 11:58 AM=0A= > To: mpls@ietf.org=0A= > Cc: ; sfc@ietf.org=0A= > Subject: [mpls] How to carry metadata/context in an MPLS packet=0A= >=0A= > Hi all,=0A= >=0A= > I'm now considering how to carry metadata/context in an MPLS packet. I ju= st=0A= > noticed that draft-guichard-mpls-metadata-00=0A= > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) propo= ses=0A= > a way to carry metadata/context in an MPLS packet (see below):=0A= >=0A= > "3. Metadata Channel Header Format=0A= >=0A= > The presence of metadata within an MPLS packet must be indicated in=0A= > the encapsulation. This document defines that the G-ACh Generic=0A= > Associated Channel Label (GAL) [RFC5586] with label value 13 is=0A= > utilized for this purpose. The GAL label provides a method to=0A= > identify that a packet contains an "Associated Channel Header (ACH)"= =0A= > followed by a non-service payload.=0A= >=0A= > [RFC5586] identifies the G-ACh Generic Associated Channel by setting= =0A= > the first nibble of the ACH that immediately follows the bottom label= =0A= > in the stack if the GAL label is present, to 0001b. Further=0A= > [RFC5586] expects that the ACH not be used to carry user data=0A= > traffic. This document proposes an extension to allow the first=0A= > nibble of the ACH to be set to 0000b and, when following the GAL, be= =0A= > interpreted using the semantics defined in=0A= > [I-D.guichard-metadata-header] to allow metadata to be carried=0A= > through the G-ACh channel."=0A= >=0A= > However, it seems that the special usage of the GAL as mentioned above st= ill=0A= > conflicts with the following statement quoted from [RFC5586]:=0A= >=0A= > " The GAL MUST NOT appear in the label stack when transporting normal=0A= > user-plane packets. Furthermore, when present, the GAL MUST NOT=0A= > appear more than once in the label stack."=0A= >=0A= > I wonder whether the special usage of the GAL as proposed in the above dr= aft=0A= > would result in any backward compatibility issue. In addition, I wonder w= hether=0A= > it's worthwhile to reconsider the possibility of introducing a Protocol T= ype (PT)=0A= > field immediately after the bottom of the MPLS label stack. With such PT = field,=0A= > any kind of future MPLS payload (e.g., metadata header or NSH) can be eas= ily=0A= > identified.=0A= >=0A= > Best regards,=0A= > Xiaohu=0A= >=0A= > _______________________________________________=0A= > mpls mailing list=0A= > mpls@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/mpls=0A= From nobody Fri Jul 18 06:02:50 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BFC1A0191; Fri, 18 Jul 2014 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE9uPfGK0I17; Fri, 18 Jul 2014 03:26:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5AA1A0145; Fri, 18 Jul 2014 03:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4284; q=dns/txt; s=iport; t=1405679207; x=1406888807; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8NMaZACDXrznUwvN1bRNPQMd4OTz00GP+BebVjsgXpw=; b=F9WmcIN0jnuWVafDzEqw/R7RtIgrUfwuMIz+4NYU7mUHlkt2koZzVDT9 r+v1DkykYAQCoCS3RKlGmtg17cvZO2cEAMBNyhHFZRuoXKKihU47FD7H0 lBYARxpzUWT8LopBOjmVhaiJUWhYhrcqLOupeEcK/vt2dRgL4cVxeevOs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAAz2yFOtJV2P/2dsb2JhbABPCg6DAFJTBATEZAqHQ4EIFnaEAwEBAQQBAQE3LQcLDAYBCBEEAQEfCS4LFAkKBAENBYhCCAXEBReJfoRxXA2EQAWbIIFMjEeGGYMCQmyBRQ X-IronPort-AV: E=Sophos;i="5.01,684,1400025600"; d="scan'208";a="61946817" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 18 Jul 2014 10:26:46 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6IAQk32021073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Jul 2014 10:26:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 18 Jul 2014 05:26:46 -0500 From: "Jim Guichard (jguichar)" To: "l.wood@surrey.ac.uk" , "xuxiaohu@huawei.com" , "mpls@ietf.org" Thread-Topic: [sfc] How to carry metadata/context in an MPLS packet Thread-Index: AQHPonLGRVDkgTbu6E6nM2i0L/u3EQ== Date: Fri, 18 Jul 2014 10:26:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <79D924AD1CCAF24D944C4B91646872F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/uNMmt3IKSeNk8xiW9xCnVttl1f4 X-Mailman-Approved-At: Fri, 18 Jul 2014 06:02:37 -0700 Cc: "spring@ietf.org" , "sfc@ietf.org" Subject: Re: [spring] [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:26:49 -0000 Hi Lloyd, I believe that Xiaohu means that we need a way to *indicate* that metadata follows the bottom of the MPLS label stack. There are multiple ways to do that and as Robert quite rightly pointed out some mechanisms already exist such as reserved labels, special-purpose labels, context labels, my old draft (which FYI has expired) etc. On 7/17/14, 11:22 PM, "l.wood@surrey.ac.uk" wrote: >No, my "why" is "why have metadata in the MPLS header at all"? > >Why does this have to be done inband? > >I am questioning the basis for doing this. There is no "must" here. > >Lloyd Wood >http://about.me/lloydwood >________________________________________ >From: Xuxiaohu >Sent: Friday, 18 July 2014 1:17 PM >To: Wood L Dr (Electronic Eng); mpls@ietf.org >Cc: spring@ietf.org; sfc@ietf.org >Subject: RE: How to carry metadata/context in an MPLS packet > >The presence of metadata within an MPLS packet must be indicated in the >encapsulation. I think that's the "why" you may want to know. > >Best regards, >Xiaohu > >> -----Original Message----- >> From: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] >> Sent: Friday, July 18, 2014 11:11 AM >> To: Xuxiaohu; mpls@ietf.org >> Cc: spring@ietf.org; sfc@ietf.org >> Subject: RE: How to carry metadata/context in an MPLS packet >> >> How? A better question is "why?" >> >> What has to be done in MPLS that cannot be done outside it? >> >> Lloyd Wood >> http://about.me/lloydwood >> ________________________________________ >> From: mpls on behalf of Xuxiaohu >> >> Sent: Friday, 18 July 2014 11:58 AM >> To: mpls@ietf.org >> Cc: ; sfc@ietf.org >> Subject: [mpls] How to carry metadata/context in an MPLS packet >> >> Hi all, >> >> I'm now considering how to carry metadata/context in an MPLS packet. I >>just >> noticed that draft-guichard-mpls-metadata-00 >> (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) >>proposes >> a way to carry metadata/context in an MPLS packet (see below): >> >> "3. Metadata Channel Header Format >> >> The presence of metadata within an MPLS packet must be indicated in >> the encapsulation. This document defines that the G-ACh Generic >> Associated Channel Label (GAL) [RFC5586] with label value 13 is >> utilized for this purpose. The GAL label provides a method to >> identify that a packet contains an "Associated Channel Header (ACH)" >> followed by a non-service payload. >> >> [RFC5586] identifies the G-ACh Generic Associated Channel by setting >> the first nibble of the ACH that immediately follows the bottom label >> in the stack if the GAL label is present, to 0001b. Further >> [RFC5586] expects that the ACH not be used to carry user data >> traffic. This document proposes an extension to allow the first >> nibble of the ACH to be set to 0000b and, when following the GAL, be >> interpreted using the semantics defined in >> [I-D.guichard-metadata-header] to allow metadata to be carried >> through the G-ACh channel." >> >> However, it seems that the special usage of the GAL as mentioned above >>still >> conflicts with the following statement quoted from [RFC5586]: >> >> " The GAL MUST NOT appear in the label stack when transporting normal >> user-plane packets. Furthermore, when present, the GAL MUST NOT >> appear more than once in the label stack." >> >> I wonder whether the special usage of the GAL as proposed in the above >>draft >> would result in any backward compatibility issue. In addition, I wonder >>whether >> it's worthwhile to reconsider the possibility of introducing a Protocol >>Type (PT) >> field immediately after the bottom of the MPLS label stack. With such >>PT field, >> any kind of future MPLS payload (e.g., metadata header or NSH) can be >>easily >> identified. >> >> Best regards, >> Xiaohu >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jul 18 07:43:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8811B29E0; Fri, 18 Jul 2014 07:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7JyERbXbMa3; Fri, 18 Jul 2014 07:43:31 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D291B29CE; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so4580563iec.17 for ; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UIrzvOQ2YUHjM0nbyOoriIY/J2pVyExkHxhyGNm2Mac=; b=rRoUMIS2vhZhjdbRik8myrWAYQR8q3Ox+Ob50Xh0INwZSlBH+vEd3SPOdXhe9Kabsn RK6XWpI4wLUTAMew0Ye//Y89dn5uFeXDCDEqmWTEbUit4J5el1EvMZdqg6GPNDeZXWML 8xER4qh23wY5edp4tsZJ76aNC2ybtYXkx1FVUrtDksA9mj0kGmjVHdK7ZnnXXHcmw7+t 1JV33p1qb6wxun4cTdrHGTYQiLtiVXDC3KUO3cYOkXBw9wKZolFh7SgOUA1KS0IZp1HY Qxv0zbTovaWU3WLTlfRH4KcqQuTf4oMJjazyPiD+MTX/3AlKkuEBvS/0W1mZaxhDb8Lm z9NA== MIME-Version: 1.0 X-Received: by 10.42.154.132 with SMTP id q4mr8214426icw.4.1405694610197; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.89.38 with HTTP; Fri, 18 Jul 2014 07:43:30 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08294118@NKGEML512-MBS.china.huawei.com> Date: Fri, 18 Jul 2014 16:43:30 +0200 X-Google-Sender-Auth: nd42Y6V-GFoxs1lLKAjCXHLW2kI Message-ID: From: Robert Raszuk To: Ron Parker Content-Type: multipart/alternative; boundary=90e6ba6e87a6e7528504fe78c708 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/1T1pTH2JpV3TqJzX_vSXthpI5iQ Cc: "mpls@ietf.org" , Xuxiaohu , "" , "sfc@ietf.org" Subject: Re: [spring] [sfc] How to carry metadata/context in an MPLS packet X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:43:34 -0000 --90e6ba6e87a6e7528504fe78c708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ron, I would be very very carefull to place matadata inband (ie embed it in customer data packets) of data plane. Few reasons for consideration: - Adding anything over hundred bytes may become pretty overwhelming for small size customer packets - Adding anything over already maxed size packet may cause MTU issues and fragmentation (which in many cases is not possible in the middle of the network). Keep in mind also encrypted data. - Anything which is variable length in the data plane and which is opaque to the data plane causes additional data plane requirements which a lot of hardware may have a hard time to deal with - Inband transport provides no option to pre-populate the state at the backup devices / backup paths where no active traffic is traversing before any network event affecting primary path - A lot of appliances may not be able to be transparent to opaque variable length metadata resulting in metadata information loss. For all of the above reasons (and I am sure many more not listed above) I would keep customer data packets alone and when needed limit only insertion of a pointer to metadata context learned out-of-band. (Out-of-band is a bit misleading term here as metadata can happily travel via the same set of links as customer data. What it really means is out-of-customer-data-packets). Best regards, R. On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker wrote: > Robert, > > > > Inband is one way -- it simplifies things at the cost of packet growth. > Out-of-band (i.e., signaling) is another way =E2=80=93 it adds complexity= but > doesn=E2=80=99t grow the data plane packets. Congruent out-of-band is a= variation > on out-of-band that may partially reduce out-of-band complexity. I thi= nk > many opinions on the thread have been that all are in scope, > architecturally. Draft-zhang-sfc-sch (I am a co-author), for example, > defines inband metadata explicitly, but states in text that out-of-band i= s > possible, too. I=E2=80=99m sure this will be a topic of discussion whe= n we start > discussing control plane requirements. > > > > Ron > > > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Robert Raszuk > > *Sent:* Friday, July 18, 2014 3:27 AM > *To:* Xuxiaohu; sfc@ietf.org > *Cc:* mpls@ietf.org; > *Subject:* Re: [sfc] [spring] How to carry metadata/context in an MPLS > packet > > > > All, > > > > Is the idea of using data plane to carry complete metadata is "the way" o= r > "a way" of approaching the problem ? Has this been already discussed ? > > > > I would rather consider to carry metadata in control plane and only attac= h > a reference_id (and only when it is needed) to the data plane. > > > > Rgs, > > R. > > > > > > > > > > On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu wrote: > > Hi all, > > I'm now considering how to carry metadata/context in an MPLS packet. I > just noticed that draft-guichard-mpls-metadata-00 ( > http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) > proposes a way to carry metadata/context in an MPLS packet (see below): > > "3. Metadata Channel Header Format > > The presence of metadata within an MPLS packet must be indicated in > the encapsulation. This document defines that the G-ACh Generic > Associated Channel Label (GAL) [RFC5586] with label value 13 is > utilized for this purpose. The GAL label provides a method to > identify that a packet contains an "Associated Channel Header (ACH)" > followed by a non-service payload. > > [RFC5586] identifies the G-ACh Generic Associated Channel by setting > the first nibble of the ACH that immediately follows the bottom label > in the stack if the GAL label is present, to 0001b. Further > [RFC5586] expects that the ACH not be used to carry user data > traffic. This document proposes an extension to allow the first > nibble of the ACH to be set to 0000b and, when following the GAL, be > interpreted using the semantics defined in > [I-D.guichard-metadata-header] to allow metadata to be carried > through the G-ACh channel." > > However, it seems that the special usage of the GAL as mentioned above > still conflicts with the following statement quoted from [RFC5586]: > > " The GAL MUST NOT appear in the label stack when transporting normal > user-plane packets. Furthermore, when present, the GAL MUST NOT > appear more than once in the label stack." > > I wonder whether the special usage of the GAL as proposed in the above > draft would result in any backward compatibility issue. In addition, I > wonder whether it's worthwhile to reconsider the possibility of introduci= ng > a Protocol Type (PT) field immediately after the bottom of the MPLS label > stack. With such PT field, any kind of future MPLS payload (e.g., metadat= a > header or NSH) can be easily identified. > > Best regards, > Xiaohu > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --90e6ba6e87a6e7528504fe78c708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ron,

I would be very very carefull to place matadata inband (ie embed it in cust= omer data packets) of data plane.=C2=A0

Few reasons for consideration:

-= Adding anything over hundred bytes may become pretty overwhelming for smal= l size customer packets

- Adding anything over already maxed = size packet may cause MTU issues and fragmentation (which in many cases is = not possible in the middle of the network). Keep in mind also encrypted dat= a.

- Anything which is variable length i= n the data plane and which is opaque to the data plane causes additional da= ta plane requirements which a lot of hardware may have a hard time to deal = with

- Inband transport provides no option= to pre-populate the state at the backup devices / backup paths where no ac= tive traffic is traversing before any network event affecting primary path<= /div>

- A lot of appliances may not be able= to be transparent to opaque variable length metadata resulting in metadata= information loss.=C2=A0

For all of the above reasons (and I a= m sure many more not listed above) I would keep customer data packets alone= and when needed limit only insertion of a pointer to metadata context lear= ned out-of-band. (Out-of-band is a bit misleading term here as metadata can= happily travel via the same set of links as customer data. What it really = means is out-of-customer-data-packets).=C2=A0

Best regards,
R.



On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker <Ron_Parker@affirmednetworks.com> wrote:

Robert,

=C2=A0

Inband is one way -- it s= implifies things at the cost of packet growth.=C2=A0=C2=A0 Out-of-band (i.e= ., signaling) is another way =E2=80=93 it adds complexity but doesn=E2=80= =99t grow the data plane packets.=C2=A0=C2=A0 Congruent out-of-band is a variation o= n out-of-band that may partially reduce out-of-band complexity.=C2=A0=C2=A0= =C2=A0 I think many opinions on the thread have been that all are in scope,= architecturally.=C2=A0=C2=A0=C2=A0 Draft-zhang-sfc-sch (I am a co-author), for example, defines inband metadata explicitly, but states in text that o= ut-of-band is possible, too.=C2=A0=C2=A0=C2=A0 I=E2=80=99m sure this will b= e a topic of discussion when we start discussing control plane requirements= .

=C2=A0

=C2=A0=C2=A0 Ron

=C2=A0

From: sfc [m= ailto:sfc-bounces= @ietf.org] On Behalf Of Robert Raszuk


Sent: Friday, July 18, 2014 3:27 AM
To: Xuxiaohu; sfc@= ietf.org
Cc: mpls@ietf.org= ; <spring@ietf.= org>
Subject: Re: [sfc] [spring] How to carry metadata/context in a= n MPLS packet

=C2=A0

= All,

= =C2=A0

= Is the idea of using data plane to carry complete metadata is "the way= " or "a way" of approaching the problem ? Has this been alre= ady discussed ?

= =C2=A0

= I would rather consider to carry metadata in control plane and only attach = a reference_id (and only when it is needed) to the data plane.=C2=A0=

= =C2=A0

= Rgs,

= R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0<= /p>

On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <xuxiaohu@huawei.com&= gt; wrote:

Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I = just noticed that draft-guichard-mpls-metadata-00 (htt= p://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/context in an MPLS packet (see below):
"3. =C2=A0Metadata Channel Header Format

=C2=A0 =C2=A0The presence of metadata within an MPLS packet must be indicat= ed in
=C2=A0 =C2=A0the encapsulation. =C2=A0This document defines that the G-ACh = Generic
=C2=A0 =C2=A0Associated Channel Label (GAL) [RFC5586] with label value 13 i= s
=C2=A0 =C2=A0utilized for this purpose. =C2=A0The GAL label provides a meth= od to
=C2=A0 =C2=A0identify that a packet contains an "Associated Channel He= ader (ACH)"
=C2=A0 =C2=A0followed by a non-service payload.

=C2=A0 =C2=A0[RFC5586] identifies the G-ACh Generic Associated Channel by s= etting
=C2=A0 =C2=A0the first nibble of the ACH that immediately follows the botto= m label
=C2=A0 =C2=A0in the stack if the GAL label is present, to 0001b. =C2=A0Furt= her
=C2=A0 =C2=A0[RFC5586] expects that the ACH not be used to carry user data<= br> =C2=A0 =C2=A0traffic. =C2=A0This document proposes an extension to allow th= e first
=C2=A0 =C2=A0nibble of the ACH to be set to 0000b and, when following the G= AL, be
=C2=A0 =C2=A0interpreted using the semantics defined in
=C2=A0 =C2=A0[I-D.guichard-metadata-header] to allow metadata to be carried=
=C2=A0 =C2=A0through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above stil= l conflicts with the following statement quoted from [RFC5586]:

" =C2=A0The GAL MUST NOT appear in the label stack when transporting n= ormal
=C2=A0 =C2=A0user-plane packets. =C2=A0Furthermore, when present, the GAL M= UST NOT
=C2=A0 =C2=A0appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draf= t would result in any backward compatibility issue. In addition, I wonder w= hether it's worthwhile to reconsider the possibility of introducing a P= rotocol Type (PT) field immediately after the bottom of the MPLS label stack. With such PT field, any kind of = future MPLS payload (e.g., metadata header or NSH) can be easily identified= .

Best regards,
Xiaohu

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

=C2=A0


--90e6ba6e87a6e7528504fe78c708-- From nobody Sun Jul 20 18:10:46 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A721B2AAB; Sun, 20 Jul 2014 18:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsOTH_QVZJUx; Sun, 20 Jul 2014 18:10:41 -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 4FA3E1B2A85; Sun, 20 Jul 2014 18:10:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKH74618; Mon, 21 Jul 2014 01:10:38 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 02:10:37 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 09:10:31 +0800 From: Lizhenbin To: "spring@ietf.org" , "idr@ietf.org" Thread-Topic: Comments on draft-filsfils-spring-segment-routing-central-epe-02 Thread-Index: Ac+kfIRNjOwQX0bwRNmv2wgtR0D8ZQ== Date: Mon, 21 Jul 2014 01:10:31 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.163.73] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/75pUvAjtrbvDd4X8ZmzL5NMpS0U Subject: [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:10:44 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycywNCg0KVGhlIHVzZWNhc2UgcHJvcG9zZWQgYnkgdGhlIGRyYWZ0IGlzIHVzZWZ1 bCBhbmQgd29ydGggcmVzZWFyY2guIFdlIHJldmlldyB0aGUgZHJhZnQgYW5kIGZpbmQgdGhlcmUg bWF5IGJlIHNvbWUgZXJyb3JzIGFib3V0IHRoZSBwcm9jZXNzIGRlc2NyaXB0aW9uIGluIFNlYyA1 LjMgYW5kIDUuNC4gUGxlYXNlIHJlZmVyIHRvIG91ciBhdHRjaGVkIGRldGFpbGVkIGNvbW1lbnRz IGlsbHVzdHJhdGVkIChpZGVudGlmaWVkIGJ5ICJDb21tZW50cyBCZWdpbiIgYW5kICJDb21tZW50 cyBFbmQiKS4gVGhlIHN1bW1hcnkgb2YgdGhlIGNvbW1lbnRzIGlzIGFzIGZvbGxvd3M6DQoNCi0t IFJlZ2FyZGluZyBJbnRlci1BUyBPcHRpb24tQyB1c2luZyBSRkMgMzEwNywgaXQgc2hvdWxkIGFk dmVydGlzZSB0aGUgbGFiZWwgc3RhY2sgaW4gdGhlIGluZ3Jlc3MgUEUgdGhyb3VnaCBCR1AgZXh0 ZW5zaW9ucyBpbnN0ZWFkIG9mIG9ubHkgdGhlIHN0ZWVyaW5nIGxhYmVsIGZvciBFUEU7DQoNCi0t IFJlZ2FyZGluZyBJbnRlci1BUyBPcHRpb24tQiwgaWYgIm5leHQgaG9wIHNlbGYiIGlzIG5vdCBl bmFibGVkIGluIHRoZSBBU0JSIGluIHRoZSBsb2NhbCBBUywgaXQgc2hvdWxkIGFsc28gYWR2ZXJ0 aXNlIHRoZSBsYWJlbCBzdGFjayBpbiB0aGUgaW5ncmVzcyBQRSB0aHJvdWdoIEJHUCBleHRlbnNp b25zIGluc3RlYWQgb2Ygb25seSB0aGUgc3RlZXJpbmcgbGFiZWwgZm9yIEVQRTsNCg0KV2UgcHJv cG9zZWQgbW9yZSB1c2UgY2FzZXMgd2hpY2ggbmVlZHMgdG8gYWR2ZXJ0aXNlIHRoZSBsYWJlbCBz dGFjayB0aHJvdWdoIEJHUCBleHRlbnNpb25zIGluIHRoZSBjZW50cmFsIGNvbnRyb2wgZW52aXJv bm1lbnQgaW4gZHJhZnQtbGktc3ByaW5nLW1wbHMtcGF0aC1wcm9ncmFtbWluZy0wMCBhbmQgdGhl IGNvcnJlc3BvbmRpbmcgQkdQIGV4dGVuc2lvbnMgYXJlIHByb3Bvc2VkIGluIHRoZSBkcmFmdC1s aS1pZHItbXBscy1wYXRoLXByb2dyYW1taW5nLTAwIHRvIGFkdmVydGlzZSB0aGUgbGFiZWwgc3Rh Y2sgYWxvbmcgd2l0aCB0aGUgYWR2ZXJ0aXNlZCBwcmVmaXguIEl0IGlzIGZvciB5b3VyIHJlZmVy ZW5jZS4NCg0KQmVzaWRlcyBhYm92ZSwgUmVnYXJkaW5nICI1LjIuICBBdCBhIHJvdXRlciAtIFNS IFRyYWZmaWMgRW5naW5lZXJpbmcgdHVubmVsIiwgd2UgdGhpbmsgaXQgaXMgYmV0dGVyIHRoYXQg dGhlIHN0ZWVyaW5nIGxhYmVsIGZvciBFUEUgKGUuZy4gMTA0Mikgc2hvdWxkIGJlIGFkdmVydGlz ZWQgdGhyb3VnaCBCR1AgZXh0ZW5zaW9ucyBSRkMgMzEwNyBpbnN0ZWFkIG9mIFBDUEUgc2luY2Ug dGhlIHN0ZWVyaW5nIHNlcnZpY2UgaXMgcGVyIHNlcnZpY2UgaW5zdGVhZCBvZiBwZXIgdHVubmVs IGFuZCB0aGUgcHJvY2VzcyBjYW4gYmUgdW5pZmllZCB3aXRoIG90aGVyIHByb2Nlc3MgaW4gU2Vj IDUuMyBhbmQgNS40LiBUaGF0IGlzLCBhbGwgb2YgdGhlbSBhcmUgYmFzZWQgb24gQkdQIGV4dGVu c2lvbnMgdG8gYWR2ZXJ0aXNlIHRoZSBzdGVlcmluZyBsYWJlbCB3aXRoIHRoZSBwcmVmaXguDQoN Cg0KDQoNCg0KUmVnYXJkcywNCg0KWmhlbmJpbihSb2JpbikNCg0KDQoNCkF0dGFjaGVkIGNvbW1l bnRzOg0KDQoNCg0KNS4zLiAgQXQgYSBSb3V0ZXIgLSBCR1AzMTA3IHBvbGljeSByb3V0ZQ0KDQog ICBUaGUgRVBFIENvbnRyb2xsZXIgY291bGQgYnVpbGQgYSBCR1AzMTA3IChbUkZDMzEwN10pIHJv dXRlIChmcm9tDQogICBzY3JhdGNoKSBhbmQgc2VuZCBpdCB0byB0aGUgaW5ncmVzcyByb3V0ZXI6 DQoNCiAgIG8gIE5MUkk6IHRoZSBkZXN0aW5hdGlvbiBwcmVmaXggdG8gZW5naW5lZXI6IGUuZy4g IEwvOC4NCg0KICAgbyAgTmV4dC1Ib3A6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgYm9yZGVyIHJvdXRl cjogQy4NCg0KICAgbyAgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCg0K ICAgbyAgQVMgcGF0aDogcmVmbGVjdGluZyB0aGUgdmFsaWQgQVMgcGF0aCBvZiB0aGUgc2VsZWN0 ZWQuDQoNCiAgIG8gIFNvbWUgQkdQIHBvbGljeSB0byBlbnN1cmUgaXQgYmUgc2VsZWN0ZWQgYXMg YmVzdCBieSB0aGUgaW5ncmVzcw0KICAgICAgcm91dGVyLg0KDQogICBUaGlzIEJHUDMxMDcgcG9s aWN5IHJvdXRlICJvdmVyd3JpdGVzIiBhbiBlcXVpdmFsZW50IG9yIGxlc3Mtc3BlY2lmaWMNCiAg ICJiZXN0IHBhdGgiLiAgQXMgdGhlIGJlc3QtcGF0aCBpcyBjaGFuZ2VkLCB0aGlzIEVQRSBpbnB1 dCBwb2xpY3kNCiAgIG9wdGlvbiBpbmZsdWVuY2VzIHRoZSBwYXRoIHByb3BhZ2F0ZWQgdG8gdGhl IHVwc3RyZWFtIHBlZXIvY3VzdG9tZXJzLg0KDQogICA9PT1Db21tZW50cyBCZWdpbj09PQ0KICAg QnVpbGRpbmcgQkdQIExTUHMgd2l0aCByZWZlcmVuY2UgdG8gdGhlICJSZWZlcmVuY2UgRGlhZ3Jh bSIgc2hvd24gaW4NCiAgIFtJLUQuZmlsc2ZpbHMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1jZW50 cmFsLWVwZV0uIFRoZSBkZXN0aW5hdGlvbg0KICAgcHJlZml4IGlzIEwvOCwgdGhlIGluZ3Jlc3Mg cm91dGVyIGlzIEEuDQoNCiAgICstLS0tLS0tLS0rICAgICAgKy0tLS0tLSsNCiAgIHwgICAgICAg ICB8ICAgICAgfCAgICAgIHwNCiAgIHwgICAgSCAgICBCLS0tLS0tRCAgICAgIEcNCiAgIHwgICAg ICAgICB8ICstLS0vfCBBUyAyIHxcICArLS0tLS0tKw0KICAgfCAgICAgICAgIHwvICAgICArLS0t LS0tKyBcIHwgICAgICB8LS0tTC84DQogICBBICAgQVMxICAgQy0tLSsgICAgICAgICAgICBcfCAg ICAgIHwNCiAgIHwgICAgICAgICB8XFwgIFwgICstLS0tLS0rIC98IEFTIDQgfC0tLU0vOA0KICAg fCAgICAgICAgIHwgXFwgICstRSAgICAgIHwvICstLS0tLS0rDQogICB8ICAgIFggICAgfCAgXFwg ICB8ICAgICAgSw0KICAgfCAgICAgICAgIHwgICArPT09RiBBUyAzIHwNCiAgICstLS0tLS0tLS0r ICAgICAgICstLS0tLS0rDQoNCiAgIEZvciBJbnRlci1BUyBkZXBsb3lpbmcgc2NlbmFyaW8sIHRo ZSByb3V0ZXIgSywgRiBhbmQgQyB3aWxsIHVzZSB0aGUNCiAgIG5leHQtaG9wLXNlbGYgbWV0aG9k IHRvIGNoYW5nZSBpdHNlbGYgYXMgdGhlIE5leHQtaG9wIGZvciB0aGUNCiAgIGRlc3RpbmF0aW9u IHByZWZpeCBMLzguDQoNCiAgIFRoZSByb3V0ZXIgSyBpbiBBUyAzIHdpbGwgY2hhbmdlIGl0c2Vs ZiBhcyB0aGUgTmV4dC1ob3AgYW5kIGFsbG9jYXRlDQogICBhIG5ldyBCR1AgbGFiZWwgZm9yIHRo ZSBkZXN0aW5hdGlvbiBwcmVmaXggTC84LCB0aGVuIHNlbmQgaXQgdG8gdGhlDQogICByb3V0ZXIg RiwgZWcuLCB1c2luZyBhIG5ldyBsYWJlbDogNTAwMQ0KDQogICBUaGUgcm91dGVyIEYgaW4gQVMg MyB3aWxsIGNoYW5nZSBpdHNlbGYgYXMgdGhlIE5leHQtaG9wIGFuZCBhbGxvY2F0ZQ0KICAgYSBu ZXcgQkdQIGxhYmVsIGZvciB0aGUgZGVzdGluYXRpb24gcHJlZml4IEwvOCwgdGhlbiBzZW5kIGl0 IHRvIHRoZQ0KICAgcm91dGVyIEMsIGVnLiwgdXNpbmcgYSBuZXcgbGFiZWw6IDUwMDINCg0KICAg VGhlIEVQRSBDb250cm9sbGVyIGNvdWxkIGJ1aWxkIGEgQkdQMzEwNyAoW1JGQzMxMDddKSByb3V0 ZSAoZnJvbQ0KICAgc2NyYXRjaCkgYW5kIHNlbmQgaXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVyOg0K DQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24gcHJlZml4IHRvIGVuZ2luZWVyOiBlLmcuICBM LzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2VsZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0ZXI6 IEMuDQoNCiAgIG8gIExhYmVscyhTSE9VTEQgYmUgYSBsYWJlbCBzdGFjayk6DQogICAgICBUaGUg Zmlyc3QgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCiAgICAgIFRoZSBz ZWNvbmQgTGFiZWw6IHRoZSBMYWJlbCB0aGF0IHRoZSByb3V0ZXIgRiBzZW5kcyB0byB0aGUgcm91 dGVyDQogICAgICBDOiA1MDAyDQoNCiAgICAgIChBIHBhY2tldCBjb21lcyBpbnRvIHRoZSBpbmdy ZXNzIHJvdXRlciBBLCB3aWxsIHB1c2ggMyBsYWJlbHM6DQogICAgICBMYWJlbCBvZiBOb2RlIEMn cyBTZWdtZW50LCAxMDQyLCA1MDAyOyApDQoNCiAgIG8gIEFTIHBhdGg6IHJlZmxlY3RpbmcgdGhl IHZhbGlkIEFTIHBhdGggb2YgdGhlIHNlbGVjdGVkLg0KDQogICBvICBTb21lIEJHUCBwb2xpY3kg dG8gZW5zdXJlIGl0IGJlIHNlbGVjdGVkIGFzIGJlc3QgYnkgdGhlIGluZ3Jlc3MNCiAgICAgIHJv dXRlci4NCg0KICAgUGFja2V0IFdhbGt0aHJvdWdoOg0KICAgMSkgQSBwYWNrZXQgZGVzdGluYXRp bmcgdG8gTC84IGNvbWVzIGludG8gdGhlIGluZ3Jlc3Mgcm91dGVyIEE7DQogICAyKSBUaGUgcm91 dGVyIEEgd2lsbCBQVVNIIDMgbGFiZWxzIGluIHR1cm46IDUwMDIsIDEwNDIsIHRoZSBsYWJlbCBv Zg0KICAgICAgdGhlIE5vZGUgU2VnbWVudCBvZiBDLCB0aGVuIHNlbmQgdGhlIHBhY2tldCB0byB0 aGUgcm91dGVyIEM7DQogICAzKSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEMs IHRoZSBhY3Rpb25zIGFyZSBjYXJyaWVkIG91dA0KICAgICAgYnkgdGhlIHJvdXRlciBDOiBmaXJz dGx5LCBQT1BzIHRoZSBsYWJlbCBvZiB0aGUgTm9kZSBTZWdtZW50IG9mIEM7DQogICAgICBzZWNv bmRseSwgUE9QcyB0aGUgbGFiZWwgMTA0MiBhbmQgZmluZHMgb3V0IHRoZSBvdXRnb2luZyBpbnRl cmZhY2UNCiAgICAgIHRvIHRoZSByb3V0ZXIgRiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGxhYmVs IDEwNDI7DQogICA0KSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEYsIHRoZSBy b3V0ZXIgRiB3aWxsIHNlZSB0aGUgYmdwDQogICAgICBsYWJlbCA1MDAyIGFuZCBjYW4gU1dBUCB0 aGUgYmdwIGxhYmVsIDUwMDIgdG8gdGhlIGJncCBsYWJlbCA1MDAxLA0KICAgICAgdGhlbiBzZW5k IHRoZSBwYWNrZXQgdG8gdGhlIHJvdXRlciBLLg0KICAgPT09Q29tbWVudHMgRW5kPT09DQoNCjUu NC4gIEF0IGEgUm91dGVyIC0gVlBOIHBvbGljeSByb3V0ZQ0KDQogICBUaGUgRVBFIENvbnRyb2xs ZXIgY291bGQgYnVpbGQgYSBWUE52NCByb3V0ZSAoZnJvbSBzY3JhdGNoKSBhbmQgc2VuZA0KICAg aXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVyOg0KDQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24g cHJlZml4IHRvIGVuZ2luZWVyOiBlLmcuICBMLzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2Vs ZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0ZXI6IEMuDQoNCiAgIG8gIExhYmVsOiB0aGUgc2VsZWN0 ZWQgZWdyZXNzIHBlZXI6IDEwNDIuDQoNCiAgIG8gIFJvdXRlLVRhcmdldDogc2VsZWN0aW5nIHRo ZSBhcHByb3ByaWF0ZSBWUkYgYXQgdGhlIGluZ3Jlc3Mgcm91dGVyLg0KDQogICBvICBBUyBwYXRo OiByZWZsZWN0aW5nIHRoZSB2YWxpZCBBUyBwYXRoIG9mIHRoZSBzZWxlY3RlZC4NCg0KICAgbyAg U29tZSBCR1AgcG9saWN5IHRvIGVuc3VyZSBpdCBiZSBzZWxlY3RlZCBhcyBiZXN0IGJ5IHRoZSBp bmdyZXNzDQogICAgICByb3V0ZXIgaW4gdGhlIHJlbGF0ZWQgVlJGLg0KDQogICBUaGUgcmVsYXRl ZCBWUkYgbXVzdCBiZSBwcmUtY29uZmlndXJlZC4gIEEgVlJGIGZhbGwtYmFjayBpbnRvIG1haW4N CiAgIEZJQiBtaWdodCBiZSBiZW5lZmljaWFsIHRvIGF2b2lkIHJlcGxpY2F0aW5nIGFsbCB0aGUg Im5vcm1hbCINCiAgIGludGVybmV0IHBhdGhzIGluIGVhY2ggVlJGLg0KDQogICA9PT1Db21tZW50 cyBCZWdpbj09PQ0KICAgRGVwbG95aW5nIEludGVyLUFTIEwzVlBOIE9wdGlvbiBCIFNlcnZpY2Vz IHdpdGggcmVmZXJlbmNlIHRvIHRoZQ0KICAgIlJlZmVyZW5jZSBEaWFncmFtIiBzaG93biBpbiBb SS1ELmZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJhbC1lcGVdLg0KDQogICBQ RTEoQSkgQVNCUjEoQikgQVNCUjMoRCkNCiAgICstLS0tLS0tLS0rICAgICAgKy0tLS0tLSsNCiAg IHwgICAgICAgICB8ICAgICAgfCAgICAgIHwNCiAgIHwgICAgSCAgICBCLS0tLS0tRCAgICAgIEcg KFBFMikNCiAgIHwgICAgICAgICB8ICstLS0vfCBBUyAyIHxcICArLS0tLS0tKw0KICAgfCAgICAg ICAgIHwvICAgICArLS0tLS0tKyBcIHwgICAgICB8LS0tTC84DQogICBBICAgQVMxICAgQy0tLSsg ICAgICAgICAgICBcfCAgICAgIHwNCiAgIHwgICAgICAgICB8XFwgIFwgICstLS0tLS0rIC98IEFT IDQgfC0tLU0vOA0KICAgfCAgICAgICAgIHwgXFwgICstRSAgICAgIHwvICstLS0tLS0rDQogICB8 ICAgIFggICAgfCAgXFwgICB8ICAgICAgSyAoUEUzKQ0KICAgfCAgICAgICAgIHwgICArPT09RiBB UyAzIHwNCiAgICstLS0tLS0tLS0rICAgICAgICstLS0tLS0rDQogICAgICAgICAgQVNCUjIoQykg IEFTQlI0KEUpDQogICAgICAgICAgICAgICAgICAgIEFTQlI1KEYpDQoNCiAgIEZvciBJbnRlci1B UyBMM1ZQTiBPcHRpb24gQjoNCiAgIFBFMyhLKSB3aWxsIGFsbG9jYXRlIGEgVlBOIGxhYmVsIChl ZywgNjAwMSkgZm9yIHRoZSBkZXN0aW5hdGlvbiBwcmVmaXggTC84LA0KICAgYW5kIHNlbmQgaXQg dG8gdGhlIHJvdXRlciBGIHZpYSBhIFZQTnY0IHJvdXRlOw0KDQogICBBU0JSNShGKSBhbmQgQVNC UjIoQykgd2lsbCBlc3RhYmxpc2ggYW4gRUJHUCBzZXNzaW9uIGFuZCBleGNoYW5nZQ0KICAgVlBO djQgcm91dGVzLCBlZy4gQVNCUjUoRikgd2lsbCBhbGxvY2F0ZSBhIG5ldyBWUE4gTGFiZWwgKGVn LiA2MDAyKSBmb3IgdGhlDQogICBkZXN0aW5hdGlvbiBwcmVmaXggTC84IGFuZCBzZW5kIGl0IHRv IEFTQlIyKEMpOw0KDQogICBUaGUgRVBFIENvbnRyb2xsZXIgY291bGQgYnVpbGQgYSBWUE52NCBy b3V0ZSAoZnJvbSBzY3JhdGNoKSBhbmQgc2VuZA0KICAgaXQgdG8gdGhlIGluZ3Jlc3Mgcm91dGVy Og0KDQogICBvICBOTFJJOiB0aGUgZGVzdGluYXRpb24gcHJlZml4IHRvIGVuZ2luZWVyOiBlLmcu ICBMLzguDQoNCiAgIG8gIE5leHQtSG9wOiB0aGUgc2VsZWN0ZWQgZWdyZXNzIGJvcmRlciByb3V0 ZXI6IEMuDQoNCiAgIG8gIExhYmVscyhTSE9VTEQgYmUgYSBsYWJlbCBzdGFjayk6DQogICAgICBU aGUgZmlyc3QgTGFiZWw6IHRoZSBzZWxlY3RlZCBlZ3Jlc3MgcGVlcjogMTA0Mi4NCiAgICAgIFRo ZSBzZWNvbmQgTGFiZWw6IHRoZSBWUE4gTGFiZWwgdGhhdCB0aGUgcm91dGVyIEYgc2VuZHMgdG8g dGhlIHJvdXRlcg0KICAgICAgQzogNjAwMg0KDQogICBvICBSb3V0ZS1UYXJnZXQ6IHNlbGVjdGlu ZyB0aGUgYXBwcm9wcmlhdGUgVlJGIGF0IHRoZSBpbmdyZXNzIHJvdXRlci4NCg0KICAgbyAgQVMg cGF0aDogcmVmbGVjdGluZyB0aGUgdmFsaWQgQVMgcGF0aCBvZiB0aGUgc2VsZWN0ZWQuDQoNCiAg IG8gIFNvbWUgQkdQIHBvbGljeSB0byBlbnN1cmUgaXQgYmUgc2VsZWN0ZWQgYXMgYmVzdCBieSB0 aGUgaW5ncmVzcw0KICAgICAgcm91dGVyIGluIHRoZSByZWxhdGVkIFZSRi4NCg0KICAgUGFja2V0 IFdhbGt0aHJvdWdoOg0KICAgMSkgQSBwYWNrZXQgZGVzdGluYXRpbmcgdG8gTC84IGNvbWVzIGlu dG8gdGhlIGluZ3Jlc3Mgcm91dGVyIEE7DQogICAyKSBUaGUgcm91dGVyIEEgd2lsbCBQVVNIIDMg bGFiZWxzIGluIHR1cm46IDYwMDIsIDEwNDIsIHRoZSBsYWJlbCBvZg0KICAgICAgdGhlIE5vZGUg U2VnbWVudCBvZiBDLCB0aGVuIHNlbmQgdGhlIHBhY2tldCB0byB0aGUgcm91dGVyIEM7DQogICAz KSBXaGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEMsIHRoZSBhY3Rpb25zIGFyZSBj YXJyaWVkIG91dA0KICAgICAgYnkgdGhlIHJvdXRlciBDOiBmaXJzdGx5LCBQT1BzIHRoZSBsYWJl bCBvZiB0aGUgTm9kZSBTZWdtZW50IG9mIEM7DQogICAgICBzZWNvbmRseSwgUE9QcyB0aGUgbGFi ZWwgMTA0MiBhbmQgZmluZHMgb3V0IHRoZSBvdXRnb2luZyBpbnRlcmZhY2UNCiAgICAgIHRvIHRo ZSByb3V0ZXIgRiBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGxhYmVsIDEwNDI7DQogICA0KSBXaGVu IHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgcm91dGVyIEYsIHRoZSByb3V0ZXIgRiB3aWxsIHNlZSB0 aGUgdnBuDQogICAgICBsYWJlbCA2MDAyIGFuZCBjYW4gU1dBUCB0aGUgdnBuIGxhYmVsIDYwMDIg dG8gdGhlIHZwbiBsYWJlbCA2MDAxLA0KICAgICAgdGhlbiBzZW5kIHRoZSBwYWNrZXQgdG8gdGhl IHJvdXRlciBLLg0KICAgPT09Q29tbWVudHMgRW5kPT09DQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi authors,

The usecase proposed by the draft is useful and worth research. We revie= w the draft and find there may be some errors about the process description= in Sec 5.3 and 5.4. Please refer to our attched detailed comments illustra= ted (identified by "Comments Begin" and "Comments End"). The summary of the comments is as follows:<= /p>

-- Regarding Inter-AS Option-C using RFC 3107, it should advertise the l= abel stack in the ingress PE through BGP extensions instead of only the ste= ering label for EPE;

-- Regarding Inter-AS Option-B, if "next hop self" is not enab= led in the ASBR in the local AS, it should also advertise the label st= ack in the ingress PE through BGP extensions instead of only the steering l= abel for EPE;

We proposed more use cases which needs to advertise the label stack thro= ugh BGP extensions in the central control environment in draft-li-spring-mp= ls-path-programming-00 and the corresponding BGP extensions are proposed in= the draft-li-idr-mpls-path-programming-00 to advertise the label stack along with the advertised prefix. It is = for your reference.

Besides above, Regarding "5.2.  At a router - SR Traffic Engin= eering tunnel", we think it is better that the steering label for= EPE (e.g. 1042) should be advertised through BGP extensions RFC 3107 = instead of PCPE since the steering service is per service instead of per tunnel and the process can be unified with other process in= Sec 5.3 and 5.4. That is, all of them are based on BGP extensions to adver= tise the steering label with the prefix.

 

 

Regards,

Zhenbin(Robin)


 

Attached comments:

 

5.3.  At a Router - BGP3107 policy route

   The EPE Controller could build a BGP3107 ([RFC3107]) route = (from
   scratch) and send it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Label: the selected egress peer: 1042.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router.

   This BGP3107 policy route "overwrites" an equival= ent or less-specific
   "best path".  As the best-path is changed, this= EPE input policy
   option influences the path propagated to the upstream peer/cus= tomers.

   =3D=3D=3DComments Begin=3D=3D=3D
   Building BGP LSPs with reference to the "Reference Diagra= m" shown in
   [I-D.filsfils-spring-segment-routing-central-epe]. The destina= tion
   prefix is L/8, the ingress router is A.
   
   +---------+      +------&= #43;
   |         |  = ;    |      |
   |    H    B------D  &n= bsp;   G
   |         | +---/|= AS 2 |\  +------+
   |         |/ &nbs= p;   +------+ \ |      |---L/8    A   AS1   C---+    = ;        \|     = ; |
   |         |\\  \&= nbsp; +------+ /| AS 4 |---M/8
   |         | \\  &= #43;-E      |/ +------+
   |    X    |  \\  = |      K
   |         |  = ; +=3D=3D=3DF AS 3 |
   +---------+       +-= -----+

   For Inter-AS deploying scenario, the router K, F and C will= use the
   next-hop-self method to change itself as the Next-hop for the =
   destination prefix L/8.
    
   The router K in AS 3 will change itself as the Next-hop and al= locate
   a new BGP label for the destination prefix L/8, then send it t= o the
   router F, eg., using a new label: 5001
  
   The router F in AS 3 will change itself as the Next-hop and al= locate
   a new BGP label for the destination prefix L/8, then send it t= o the
   router C, eg., using a new label: 5002
  
   The EPE Controller could build a BGP3107 ([RFC3107]) route (fr= om
   scratch) and send it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Labels(SHOULD be a label stack):
      The first Label: the selected egress peer: 1= 042.
      The second Label: the Label that the router = F sends to the router
      C: 5002 
     
      (A packet comes into the ingress router A, w= ill push 3 labels:
      Label of Node C's Segment, 1042, 5002; )
     
   o  AS path: reflecting the valid AS path of the selected.=

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router.
     
   Packet Walkthrough:
   1) A packet destinating to L/8 comes into the ingress router A= ;
   2) The router A will PUSH 3 labels in turn: 5002, 1042, the la= bel of
      the Node Segment of C, then send the packet = to the router C;
   3) When the packet reaches the router C, the actions are carri= ed out
      by the router C: firstly, POPs the label of = the Node Segment of C;
      secondly, POPs the label 1042 and finds out = the outgoing interface
      to the router F in accordance with the label= 1042;
   4) When the packet reaches the router F, the router F will see= the bgp
      label 5002 and can SWAP the bgp label 5002 t= o the bgp label 5001,
      then send the packet to the router K. &= nbsp;           &nbs= p;            &= nbsp; 
   =3D=3D=3DComments End=3D=3D=3D     &n= bsp;            = ;   

5.4.  At a Router - VPN policy route

   The EPE Controller could build a VPNv4 route (from scratch)= and send
   it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Label: the selected egress peer: 1042.

   o  Route-Target: selecting the appropriate VRF at the = ingress router.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router in the related VRF.

   The related VRF must be pre-configured.  A VRF fall-ba= ck into main
   FIB might be beneficial to avoid replicating all the "nor= mal"
   internet paths in each VRF.
  
   =3D=3D=3DComments Begin=3D=3D=3D
   Deploying Inter-AS L3VPN Option B Services with reference to t= he
   "Reference Diagram" shown in [I-D.filsfils-spring-se= gment-routing-central-epe].
  
   PE1(A) ASBR1(B) ASBR3(D)     
   +---------+      +------&= #43;
   |         |  = ;    |      |
   |    H    B------D  &n= bsp;   G (PE2)
   |         | +---/|= AS 2 |\  +------+
   |         |/ &nbs= p;   +------+ \ |      |---L/8    A   AS1   C---+    = ;        \|     = ; |
   |         |\\  \&= nbsp; +------+ /| AS 4 |---M/8
   |         | \\  &= #43;-E      |/ +------+
   |    X    |  \\  = |      K (PE3)
   |         |  = ; +=3D=3D=3DF AS 3 |
   +---------+       +-= -----+
          ASBR2(C)  ASBR4= (E)
            &nb= sp;       ASBR5(F)    &nb= sp;            =   
  
   For Inter-AS L3VPN Option B:
   PE3(K) will allocate a VPN label (eg, 6001) for the destinatio= n prefix L/8,
   and send it to the router F via a VPNv4 route;
  
   ASBR5(F) and ASBR2(C) will establish an EBGP session and excha= nge
   VPNv4 routes, eg. ASBR5(F) will allocate a new VPN Label (eg. = 6002) for the
   destination prefix L/8 and send it to ASBR2(C);
  
   The EPE Controller could build a VPNv4 route (from scratch) an= d send
   it to the ingress router:

   o  NLRI: the destination prefix to engineer: e.g. = ; L/8.

   o  Next-Hop: the selected egress border router: C.

   o  Labels(SHOULD be a label stack):
      The first Label: the selected egress peer: 1= 042.
      The second Label: the VPN Label that the rou= ter F sends to the router
      C: 6002 

   o  Route-Target: selecting the appropriate VRF at the = ingress router.

   o  AS path: reflecting the valid AS path of the select= ed.

   o  Some BGP policy to ensure it be selected as best by= the ingress
      router in the related VRF.
     
   Packet Walkthrough:
   1) A packet destinating to L/8 comes into the ingress router A= ;
   2) The router A will PUSH 3 labels in turn: 6002, 1042, the la= bel of
      the Node Segment of C, then send the packet = to the router C;
   3) When the packet reaches the router C, the actions are carri= ed out
      by the router C: firstly, POPs the label of = the Node Segment of C;
      secondly, POPs the label 1042 and finds out = the outgoing interface
      to the router F in accordance with the label= 1042;
   4) When the packet reaches the router F, the router F will see= the vpn
      label 6002 and can SWAP the vpn label 6002 t= o the vpn label 6001,
      then send the packet to the router K. &= nbsp;           &nbs= p;      
   =3D=3D=3DComments End=3D=3D=3D

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07nkgeml506mbxchi_-- From nobody Mon Jul 21 00:21:01 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4571B2D9A; Mon, 21 Jul 2014 00:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3b_1LCFLh9x; Mon, 21 Jul 2014 00:20:58 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1F331B2D76; Mon, 21 Jul 2014 00:20:57 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id rl12so6317485iec.24 for ; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qjROYu9fN+RhJfHIVvn/i3r7ew4GaEVtmKe6/fyUjes=; b=Ui28P0sWKUj0Yrf2fAhN+AERAzcA7EiyJIN1eKFizzxE975h6XaCgXsK4sGmCcUszr iscIOxFmauaTFoKENSx9ZxUvi98/2k0RKMJVB6BOnl//Q5bp6Jys+RoRfAsTfOF7f6O2 mYyXYtpt6u/+Hy2KLxhZxIfPsOxCQ1UzhiLDpofcFBrsQLZdD3MrWUPJMKZeCGpANgSs PHRyM49l8AOWE87AbXO/pRNR6nr6HN99ezHx5o3+l6dFo837rEfR5cmcZ5Gylo4S2PX6 AWtF9Ms3m7wkf7PQI24WbM889iFnUEdHkJYGReZXWmJHXqrCPzYNKQL7GNMqhCfIcNeX 2Rrw== MIME-Version: 1.0 X-Received: by 10.50.62.80 with SMTP id w16mr1893593igr.21.1405927256750; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 21 Jul 2014 00:20:56 -0700 (PDT) In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> Date: Mon, 21 Jul 2014 09:20:56 +0200 X-Google-Sender-Auth: Fg2tmQKkvpPE_NIL7F-24a_km-E Message-ID: From: Robert Raszuk To: Lizhenbin Content-Type: multipart/alternative; boundary=047d7bdc0aeab8020204feaef2bb Archived-At: http://mailarchive.ietf.org/arch/msg/spring/-j8467Du1IJXZRbx9EZZfIXKV5w Cc: "idr@ietf.org" , "spring@ietf.org" Subject: Re: [spring] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 07:20:59 -0000 --047d7bdc0aeab8020204feaef2bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Robin,=E2=80=8B +---------+ +------+ > | | | | > | H B------D G > | | +---/| AS 2 |\ +------+ > | |/ +------+ \ | |---L/8 > A AS1 C---+ \| | > | |\\ \ +------+ /| AS 4 |---M/8 > | | \\ +-E |/ +------+ > | X | \\ | K > | | +=3D=3D=3DF AS 3 | > +---------+ +------+ > > > The router F in AS 3 will change itself as the Next-hop and allocate a ne= w > BGP label for the destination prefix L/8, then send it to the router C, > eg., using a new label: 5002 > =E2=80=8BNot quite right. Router F is not a MPLS router. It just uses plain IPv4/IPv6 forwarding. Please read this in the draft: "o The solution MUST apply to the Internet use-case where the Internet routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.=E2=80=8B" =E2=80=8BThe entire EPE solution as described in the draft is contained to = AS1. AS 2..4 are for illustration of the bigger picture only. - - - =3D=3D=3DComments Begin=3D=3D=3D > Deploying Inter-AS L3VPN Option B Services with reference to the > =E2=80=8BLet me clarify that the EPE draft does not talk about VPN service. It only uses L3VPN VPN mechanism within AS1 to distribute EPE =E2=80=8Binstrumentation data perhaps "VPN policy route" is a bit misleadin= g term. It really means that SAFI 128 is used for EPE steering labels distribution. It is still only IPv4/IPv6 Internet service. Said this your suggestion of using EPE within VPN service and specifically at EPE enhanced option B peering is valid. However if you would like to focus on using EPE for VPN service it seems that new separate proposal may be required. There is few issues associated with this unique to such use case. It can very well serve as parallel draft to Internet EPE use case. Thx, R. --047d7bdc0aeab8020204feaef2bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Robin,=E2=80=8B

=C2=A0 =C2=A0+---------+=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 H=C2=A0=C2=A0=C2=A0 B------D=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 G
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | +---/| AS = 2 |\=C2=A0 +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |/=C2=A0=C2= =A0=C2=A0=C2=A0 +------+ \ |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---L/8
=C2=A0=C2=A0 A=C2=A0=C2=A0 AS1=C2=A0=C2=A0 C---+=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= br> =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |\\=C2=A0 \= =C2=A0 +------+ /| AS 4 |---M/8
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | \\=C2=A0 += -E=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |/ +------+
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 X=C2=A0=C2=A0=C2=A0 |=C2=A0 \\=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 K
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0 +=3D=3D=3DF AS 3 |
=C2=A0=C2=A0 +---------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +------+


The router F in AS 3 will chan= ge itself as the Next-hop and allocate a new BGP label for the destination = prefix L/8, then send it to the router C, eg., using a new label: 5002


=E2=80=8BNot quite right. Router F is not a MPLS router. It just uses = plain IPv4/IPv6 forwarding. Please read this in the draft:

"o =C2=A0The solution MUST a= pply to the Internet use-case where the Internet routes are assumed to use = IPv4 unlabeled or IPv6 unlabeled.=E2=80=8B"

=E2=80=8BThe entire EPE solution as = described in the draft is contained to AS1. AS 2..4 are for illustration of= the bigger picture only.=C2=A0

- - -=C2= =A0

=3D=3D=3DComments Begin=3D=3D=3DDeploying Inter-AS L3VPN Option B Services with reference to the


=E2=80=8BLet me clarify that the EPE draft does not talk about VPN service.= =C2=A0

It only uses L3VPN VPN mechanism within AS1 to distribute EPE =E2=80=8Binst= rumentation data perhaps "VPN policy route" is a bit misleading t= erm. It really means that SAFI 128 is used for EPE steering labels distribu= tion. It is still only IPv4/IPv6 Internet service.=C2=A0

Said this your su= ggestion of using EPE within VPN service and specifically at EPE enhanced o= ption B peering is valid.=C2=A0

However if= you would like to focus on using EPE for VPN service it seems that new sep= arate proposal may be required. There is few issues associated with this un= ique to such use case.=C2=A0

It can very well = serve as parallel draft to Internet EPE use case.

Thx,
R.=

--047d7bdc0aeab8020204feaef2bb-- From nobody Mon Jul 21 06:41:27 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6E1B2C00; Mon, 21 Jul 2014 06:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ-_qFdOg4IZ; Mon, 21 Jul 2014 06:40:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58B81B2C02; Mon, 21 Jul 2014 06:37:20 -0700 (PDT) Received: from juniper.net (66.129.239.11) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 13:37:17 +0000 Date: Mon, 21 Jul 2014 15:37:10 +0200 From: Hannes Gredler To: Robert Raszuk Message-ID: <20140721133709.GA19995@juniper.net> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [66.129.239.11] X-ClientProxiedBy: BY2PR03CA043.namprd03.prod.outlook.com (10.141.249.16) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0279B3DD0D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(189002)(199002)(23726002)(80022001)(92566001)(81156004)(83506001)(15975445006)(74502001)(97756001)(4396001)(77982001)(76482001)(79102001)(81342001)(83072002)(107046002)(74662001)(86362001)(33656002)(47776003)(46406003)(66066001)(102836001)(85852003)(31966008)(106356001)(92726001)(64706001)(20776003)(105586002)(69596002)(42186005)(36756003)(87976001)(77096002)(33026002)(19580395003)(99396002)(81542001)(76176999)(110136001)(21056001)(50986999)(46102001)(50466002)(19580405001)(83322001)(95666004)(85306003)(54356999)(101416001)(579124003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:juniper.net; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/JjgcvCYLNmOLXnZ_eFfNjB9yLQM Cc: "idr@ietf.org" , "spring@ietf.org" , Lizhenbin Subject: Re: [spring] [Idr] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:41:06 -0000 X-List-Received-Date: Mon, 21 Jul 2014 13:41:06 -0000 hi robert, why does it matter wether router 'F' is MPLS enabled or not ? IMO all that is required is that router 'C' 'generates' a labeled route for router 'F' (NH: router C) as soon as the BGP session between C and F comes up. - i.e. just local router C implementation - no new protocol extensions required for making this work at all. tx, /hannes On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote: | *Hi Robin,* | | +---------+ +------+ | | | | | | | H B------D G | | | +---/| AS 2 |\ +------+ | | |/ +------+ \ | |---L/8 | A AS1 C---+ \| | | | |\\ \ +------+ /| AS 4 |---M/8 | | | \\ +-E |/ +------+ | | X | \\ | K | | | +===F AS 3 | | +---------+ +------+ | | The router F in AS 3 will change itself as the Next-hop and allocate a | new BGP label for the destination prefix L/8, then send it to the router | C, eg., using a new label: 5002 | | *Not quite right. Router F is not a MPLS router. It just uses plain | IPv4/IPv6 forwarding. Please read this in the draft: | "o The solution MUST apply to the Internet use-case where the Internet | routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*" | *The entire EPE solution as described in the draft is contained to AS1. AS | 2..4 are for illustration of the bigger picture only. | - - - | | ===Comments Begin=== | Deploying Inter-AS L3VPN Option B Services with reference to the | | *Let me clarify that the EPE draft does not talk about VPN service. | It only uses L3VPN VPN mechanism within AS1 to distribute EPE | *instrumentation data perhaps "VPN policy route" is a bit misleading term. | It really means that SAFI 128 is used for EPE steering labels | distribution. It is still only IPv4/IPv6 Internet service. | Said this your suggestion of using EPE within VPN service and specifically | at EPE enhanced option B peering is valid. | However if you would like to focus on using EPE for VPN service it seems | that new separate proposal may be required. There is few issues associated | with this unique to such use case. | It can very well serve as parallel draft to Internet EPE use case. | Thx, | R. | _______________________________________________ | Idr mailing list | Idr@ietf.org | https://www.ietf.org/mailman/listinfo/idr From nobody Mon Jul 21 07:38:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1346E1A00F1 for ; Mon, 21 Jul 2014 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RouifFknwte5 for ; Mon, 21 Jul 2014 07:38:32 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22901A00A8 for ; Mon, 21 Jul 2014 07:38:26 -0700 (PDT) Received: from [2001:67c:370:176:c975:8fee:4dcf:475] (helo=wireless-a-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9EjO-0005L4-Ee; Mon, 21 Jul 2014 15:38:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Rob Shakir Date: Mon, 21 Jul 2014 10:38:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> To: spring@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/uZyaCa2Oldl8Uj5dAg-OC2WJFOg Cc: draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:38:34 -0000 Hi SPRING, draft-kini=85 authors, I have a few comments on the discussion within this draft =97 and a = quick question on the intention around the document. - I feel that it would be useful to provide some clarification as to = where we expect entropy to be required for load-sharing in the draft. The = current wording (to me) could be read to say that where Adj-SID is used, then = there is no requirement to consider placement for EL since there will be no load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in draft-filsfils-spring-segment-routing-04), or the underlying transport = for an IGP adjacency can be multi-path (e.g., an aggregated Ethernet link) this is not true unless a head-end PE can guarantee that a particular adjacency is made up of a transport that has only 1 path (i.e., = explicitly requires no load-balancing). I'm not sure how the iLER would actually = determine this, short of the definition of new per-adjacency advertisement = capabilities. Even if it were able to, then it seems the result is very likely to be = that an approach that requires per-hop entropy labels to be injected is going = to guarantee label stack depth >=3D 3*[number of path SIDs]. I think that the above means that the current draft under-estimates = the depth of the stack when considering an EL per tunnel (=A73.2), which might = amplify some of the concerns raised for this option.=20 - =A73.4 - I am not clear how we would really implement this option. If = we learn midpoint capabilities, and then tune our placement of the EL based on = these, then it seems like the only viable approach is really to consider = _all_ midpoints, and tune the placement according to the "shallowest" = midpoint in the network. This is because, whilst we might expect that there is = routing via some particular path, this might change if there is ECMP between = mid-points nodes where some paths have different capabilities than others, and = equally might change whilst re-routing occurs. In terms of discovery of the capabilities of a mid-point -- do we need = to consider how, in a multi-area network, we discover the capabilities of = a mid-point which might not have information about it leaked between = areas? =20 - Finally, it'd be good to determine what the intention of the authors = for this document is. Do we expect that we make a recommendation as to what = equipment vendors who are going to support SR-MPLS should optimise for? At the = moment, the document is good at classifying the different approaches that = _could_ be=20 taken, but potentially requires an operator/vendor to consider = optimisation for both a) reading very deep into the stack when acting as an LSR, b) = pushing very deep stacks when acting as iLER, c) potentially implementing more = complex swap() operations, whereby some reshuffling of the EL is required.=20 My feeling is that it would be very useful for this document to be = able to make a clear recommendation as to which of these approaches should be optimised for, and hence we should debate their technical efficacy. = It'd be good to understand whether the authors are intending to do this, or = rather classify the approaches. Cheers, r. From nobody Mon Jul 21 07:47:03 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11891A008D; Mon, 21 Jul 2014 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypfr1vgsgfyq; Mon, 21 Jul 2014 07:46:51 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6574D1A002E; Mon, 21 Jul 2014 07:46:49 -0700 (PDT) Received: from [2001:67c:370:176:c975:8fee:4dcf:475] (helo=wireless-a-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9ErX-0005MG-Oc; Mon, 21 Jul 2014 15:46:47 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> Date: Mon, 21 Jul 2014 10:46:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> To: spring@ietf.org, mpls@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/0595NxJiu2GWOjyS4hzB2xSvUVY Cc: draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:47:01 -0000 Adding the MPLS wg to this discussion. [Apologies for the spam.] r. On 21 Jul 2014, at 10:38, Rob Shakir wrote: > Hi SPRING, draft-kini=85 authors, >=20 > I have a few comments on the discussion within this draft =97 and a = quick question > on the intention around the document. >=20 > - I feel that it would be useful to provide some clarification as to = where we > expect entropy to be required for load-sharing in the draft. The = current > wording (to me) could be read to say that where Adj-SID is used, then = there > is no requirement to consider placement for EL since there will be no > load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 = in > draft-filsfils-spring-segment-routing-04), or the underlying = transport for an > IGP adjacency can be multi-path (e.g., an aggregated Ethernet link) > this is not true unless a head-end PE can guarantee that a particular > adjacency is made up of a transport that has only 1 path (i.e., = explicitly > requires no load-balancing). I'm not sure how the iLER would actually = determine > this, short of the definition of new per-adjacency advertisement = capabilities. > Even if it were able to, then it seems the result is very likely to = be that an > approach that requires per-hop entropy labels to be injected is going = to > guarantee label stack depth >=3D 3*[number of path SIDs]. >=20 > I think that the above means that the current draft under-estimates = the depth > of the stack when considering an EL per tunnel (=A73.2), which might = amplify > some of the concerns raised for this option.=20 >=20 > - =A73.4 - I am not clear how we would really implement this option. = If we learn > midpoint capabilities, and then tune our placement of the EL based on = these, > then it seems like the only viable approach is really to consider = _all_ > midpoints, and tune the placement according to the "shallowest" = midpoint in > the network. This is because, whilst we might expect that there is = routing via > some particular path, this might change if there is ECMP between = mid-points > nodes where some paths have different capabilities than others, and = equally > might change whilst re-routing occurs. >=20 > In terms of discovery of the capabilities of a mid-point -- do we = need to > consider how, in a multi-area network, we discover the capabilities = of a > mid-point which might not have information about it leaked between = areas? >=20 > - Finally, it'd be good to determine what the intention of the authors = for this > document is. Do we expect that we make a recommendation as to what = equipment > vendors who are going to support SR-MPLS should optimise for? At the = moment, > the document is good at classifying the different approaches that = _could_ be=20 > taken, but potentially requires an operator/vendor to consider = optimisation > for both a) reading very deep into the stack when acting as an LSR, = b) pushing > very deep stacks when acting as iLER, c) potentially implementing = more complex > swap() operations, whereby some reshuffling of the EL is required.=20 >=20 > My feeling is that it would be very useful for this document to be = able to > make a clear recommendation as to which of these approaches should be > optimised for, and hence we should debate their technical efficacy. = It'd be > good to understand whether the authors are intending to do this, or = rather > classify the approaches. >=20 > Cheers, > r. >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 21 07:57:13 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C121A017D; Mon, 21 Jul 2014 07:57:08 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dENgbQzh19kq; Mon, 21 Jul 2014 07:57:05 -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 1FA9C1A012D; Mon, 21 Jul 2014 07:57:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ38704; Mon, 21 Jul 2014 14:57:02 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 15:57:02 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 22:56:55 +0800 From: Xuxiaohu To: Rob Shakir , "spring@ietf.org" , "mpls@ietf.org" Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPG60J2/V/fu6kuL32lhjiOWm5uqFS+AgACHrg0= Date: Mon, 21 Jul 2014 14:56:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C29@NKGEML512-MBS.china.huawei.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh>, <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> In-Reply-To: <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/cnsPWhSsGxlIPDZI6pXv_PzOl08 Cc: "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:57:08 -0000 Hi Rob, > In terms of discovery of the capabilities of a mid-point -- do we need t= o > consider how, in a multi-area network, we discover the capabilities of a > mid-point which might not have information about it leaked between areas= ? Did you mean that when propagating the capabilities TLV/sub-TLV of a given = node across areas, the information (e.g., IP address) of the originator of = that capability TLV/sub-TLV is lost? Best regards, Xiaohu= From nobody Mon Jul 21 08:05:05 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC601A019A; Mon, 21 Jul 2014 08:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNctGYN3J0Ci; Mon, 21 Jul 2014 08:04:59 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622D71A01E0; Mon, 21 Jul 2014 08:04:19 -0700 (PDT) Received: from [2001:67c:370:176:c975:8fee:4dcf:475] (helo=wireless-a-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9F8S-0005Of-KO; Mon, 21 Jul 2014 16:04:16 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C29@NKGEML512-MBS.china.huawei.com> Date: Mon, 21 Jul 2014 11:04:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77CEA301-8C51-4694-8B22-9ADDE19389CE@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh>, <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C29@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/eaRyckKneRJvAOV3ARpwbxIg4e8 Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:05:02 -0000 Hi Xiaohu, On 21 Jul 2014, at 10:56, Xuxiaohu wrote: >> In terms of discovery of the capabilities of a mid-point -- do we = need to >> consider how, in a multi-area network, we discover the capabilities = of a >> mid-point which might not have information about it leaked between = areas? >=20 > Did you mean that when propagating the capabilities TLV/sub-TLV of a = given node across areas, the information (e.g., IP address) of the = originator of that capability TLV/sub-TLV is lost? I was more considering the case that the information is simply not = propagated into the =93downstream=94 area. There is no clear requirement = to me that we need propagate capabilities and/or prefix SIDs for = non-endpoint nodes across area boundaries, and hence we may not have = visibility of each mid-point on the path. r.= From nobody Mon Jul 21 08:13:44 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D5B1A0162; Mon, 21 Jul 2014 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.748 X-Spam-Level: * X-Spam-Status: No, score=1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqk8-allzfkP; Mon, 21 Jul 2014 08:13:38 -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 4598D1A0137; Mon, 21 Jul 2014 08:13:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKJ39989; Mon, 21 Jul 2014 15:13:35 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Jul 2014 16:13:35 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 21 Jul 2014 23:13:29 +0800 From: Xuxiaohu To: Rob Shakir Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPG60J2/V/fu6kuL32lhjiOWm5uqFS+AgACHrg3//30zgIAAiAAs Date: Mon, 21 Jul 2014 15:13:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C73@NKGEML512-MBS.china.huawei.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh>, <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C29@NKGEML512-MBS.china.huawei.com>, <77CEA301-8C51-4694-8B22-9ADDE19389CE@rob.sh> In-Reply-To: <77CEA301-8C51-4694-8B22-9ADDE19389CE@rob.sh> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.178] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/enDdSLHydrNghmTacIfdLFiUj9w Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: [spring] =?gb2312?b?tPC4tDogIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExh?= =?gb2312?b?YmVs?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:13:39 -0000 SGkgUm9iLA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+ yMs6IHNwcmluZyBbc3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9iIFNoYWtpciBbcmpz QHJvYi5zaF0NCreiy83KsbzkOiAyMDE0xOo31MIyMcjVIDIzOjA0DQrK1bz+yMs6IFh1eGlhb2h1 DQqzrcvNOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1z cHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIFNQ UklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCkhpIFhpYW9odSwNCg0KT24gMjEgSnVsIDIw MTQsIGF0IDEwOjU2LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj4+ IEluIHRlcm1zIG9mIGRpc2NvdmVyeSBvZiB0aGUgY2FwYWJpbGl0aWVzIG9mIGEgbWlkLXBvaW50 IC0tIGRvIHdlIG5lZWQgdG8NCj4+IGNvbnNpZGVyIGhvdywgaW4gYSBtdWx0aS1hcmVhIG5ldHdv cmssIHdlIGRpc2NvdmVyIHRoZSBjYXBhYmlsaXRpZXMgb2YgYQ0KPj4gbWlkLXBvaW50IHdoaWNo IG1pZ2h0IG5vdCBoYXZlIGluZm9ybWF0aW9uIGFib3V0IGl0IGxlYWtlZCBiZXR3ZWVuIGFyZWFz Pw0KPg0KPiBEaWQgeW91IG1lYW4gdGhhdCB3aGVuIHByb3BhZ2F0aW5nIHRoZSBjYXBhYmlsaXRp ZXMgVExWL3N1Yi1UTFYgb2YgYSBnaXZlbiBub2RlIGFjcm9zcyBhcmVhcywgdGhlIGluZm9ybWF0 aW9uIChlLmcuLCBJUCBhZGRyZXNzKSBvZiB0aGUgb3JpZ2luYXRvciBvZiB0aGF0IGNhcGFiaWxp dHkgVExWL3N1Yi1UTFYgaXMgbG9zdD8NCg0KSSB3YXMgbW9yZSBjb25zaWRlcmluZyB0aGUgY2Fz ZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBpcyBzaW1wbHkgbm90IHByb3BhZ2F0ZWQgaW50byB0aGUg obBkb3duc3RyZWFtobEgYXJlYS4gVGhlcmUgaXMgbm8gY2xlYXIgcmVxdWlyZW1lbnQgdG8gbWUg dGhhdCB3ZSBuZWVkIHByb3BhZ2F0ZSBjYXBhYmlsaXRpZXMgYW5kL29yIHByZWZpeCBTSURzIGZv ciBub24tZW5kcG9pbnQgbm9kZXMgYWNyb3NzIGFyZWEgYm91bmRhcmllcywgYW5kIGhlbmNlIHdl IG1heSBub3QgaGF2ZSB2aXNpYmlsaXR5IG9mIGVhY2ggbWlkLXBvaW50IG9uIHRoZSBwYXRoLg0K DQpbWGlhb2h1XSBJZiB3ZSBuZWVkIHZpc2liaWxpdHkgb2YgZWFjaCBtaWQtcG9pbnQgb24gdGhl IHBhdGggaW5kZWVkLCBkb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2FwYWJpbGl0eSBvZiBlYWNoIG1p ZC1wb2ludCBzaG91bGQgYmUgcHJvcGFnYXRlZCBhY3Jvc3MgYXJlYSBib3VuZGFyaWVzPw0KDQpC ZXN0IHJlZ2FyZHMNClhpYW9odQ0KDQpyLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc= From nobody Mon Jul 21 08:17:43 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E11A02CF; Mon, 21 Jul 2014 08:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e14XMMfQFSx4; Mon, 21 Jul 2014 08:17:28 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3D51A0178; Mon, 21 Jul 2014 08:17:11 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so6688817ieb.7 for ; Mon, 21 Jul 2014 08:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yRiifvRrsC53ElcugIR7GHZr4Z6pIfm72vgygIDnvAQ=; b=cepGerXCuTVUgAzfsGG2hRoBoEaTIcxM2Naxr5+mHV6GHG0pkkMM1ELWOUr32pss8t TivqdW2jSfdH/pZwI6eIgKvXXRZekOSRuQiKRsDDegbliUy7zn0w2RBN8yunGfKFUDE/ Qj7khVXOYuMUFiEDQ2SyqiOCdQw6gcJEGXE/aF8BlU5whuw0GKJAoYpWjmpTzot3zkw+ uUdj3cv8LkthHqRrsqRjbsHNg0VbCkGHLfqylflvH6KRno3WNicyMs1il4mNbrJk8qex CVsPGRxkDOkZDWAu64rFKEHN4EbnLqU+lcWiTasv8PQyXedj9CBD+RtXurFjqjHIWswg L1xw== MIME-Version: 1.0 X-Received: by 10.43.139.203 with SMTP id ix11mr13813391icc.72.1405955830918; Mon, 21 Jul 2014 08:17:10 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 21 Jul 2014 08:17:10 -0700 (PDT) In-Reply-To: <20140721133709.GA19995@juniper.net> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08231B07@nkgeml506-mbx.china.huawei.com> <20140721133709.GA19995@juniper.net> Date: Mon, 21 Jul 2014 17:17:10 +0200 X-Google-Sender-Auth: 5Js-wy0-SKtjeiJ06qBC48HvFIk Message-ID: From: Robert Raszuk To: Hannes Gredler Content-Type: multipart/alternative; boundary=001a11c2e654df34df04feb5990b Archived-At: http://mailarchive.ietf.org/arch/msg/spring/lh1Z1XzLdv-dpKuHsk9KXkTDNaA Cc: "idr@ietf.org" , "spring@ietf.org" , Lizhenbin Subject: Re: [spring] [Idr] Comments on draft-filsfils-spring-segment-routing-central-epe-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:17:33 -0000 --001a11c2e654df34df04feb5990b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, On Mon, Jul 21, 2014 at 3:37 PM, Hannes Gredler wrote: > hi robert, > > why does it matter wether router 'F' is MPLS enabled or not ? > =E2=80=8BIt does not. Where did I say it matters for EPE ? However it matters for what Robin is suggesting as his entire suggestion is to carry F's label =E2=80=8Bfrom AS1 controller to ingress points. > IMO all that is required is that router 'C' 'generates' > a labeled route for router 'F' (NH: router C) as soon as the > BGP session between C and F comes up. - > =E2=80=8BThat's true. =E2=80=8BModulo the option B case Robin has suggested= in his second part. While that may also not need protocol extension how you signal this around depends on your choice of signalling channel between controller and ingress points. Best, r. > i.e. just local router C implementation - > no new protocol extensions required for making this work at all. > > tx, > > /hannes > > On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote: > | *Hi Robin,* > | > | +---------+ +------+ > | | | | | > | | H B------D G > | | | +---/| AS 2 |\ +------+ > | | |/ +------+ \ | |---L/8 > | A AS1 C---+ \| | > | | |\\ \ +------+ /| AS 4 |---M/8 > | | | \\ +-E |/ +------+ > | | X | \\ | K > | | | +=3D=3D=3DF AS 3 | > | +---------+ +------+ > | > | The router F in AS 3 will change itself as the Next-hop and > allocate a > | new BGP label for the destination prefix L/8, then send it to the > router > | C, eg., using a new label: 5002 > | > | *Not quite right. Router F is not a MPLS router. It just uses plain > | IPv4/IPv6 forwarding. Please read this in the draft: > | "o The solution MUST apply to the Internet use-case where the > Internet > | routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*" > | *The entire EPE solution as described in the draft is contained to > AS1. AS > | 2..4 are for illustration of the bigger picture only. > | - - - > | > | =3D=3D=3DComments Begin=3D=3D=3D > | Deploying Inter-AS L3VPN Option B Services with reference to the > | > | *Let me clarify that the EPE draft does not talk about VPN service. > | It only uses L3VPN VPN mechanism within AS1 to distribute EPE > | *instrumentation data perhaps "VPN policy route" is a bit misleading > term. > | It really means that SAFI 128 is used for EPE steering labels > | distribution. It is still only IPv4/IPv6 Internet service. > | Said this your suggestion of using EPE within VPN service and > specifically > | at EPE enhanced option B peering is valid. > | However if you would like to focus on using EPE for VPN service it > seems > | that new separate proposal may be required. There is few issues > associated > | with this unique to such use case. > | It can very well serve as parallel draft to Internet EPE use case. > | Thx, > | R. > > | _______________________________________________ > | Idr mailing list > | Idr@ietf.org > | https://www.ietf.org/mailman/listinfo/idr > > --001a11c2e654df34df04feb5990b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hannes,
<= br>
On Mon, Jul 21, 2014 at 3:37 PM, Hannes G= redler <hannes@juniper.net> wrote:
hi robert,

why does it matter wether router 'F' is MPLS enabled or not ?

=E2=80=8BIt does not= . Where did I say it matters for EPE ?=C2=A0

However it matter= s for what Robin is suggesting as his entire suggestion is to carry F's= label =E2=80=8Bfrom AS1 controller to ingress points.=C2=A0
=C2=A0
IMO all that is required is that router 'C' 'generates'
a labeled route for router 'F' (NH: router C) as soon as the
BGP session between C and F comes up. -

=E2=80=8BThat's true. =E2=80=8BModulo the opti= on B case Robin has suggested in his second part. While that may also not n= eed protocol extension how you signal this around depends on your choice of= signalling channel between controller and ingress points.

Best,
r.




i.e. just local router C implementation -
no new protocol extensions required for making this work at all.

tx,

/hannes

On Mon, Jul 21, 2014 at 09:20:56AM +0200, Robert Raszuk wrote:
| =C2=A0 =C2=A0*Hi Robin,*
|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+ =C2=A0 =C2=A0 =C2=A0+------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0| =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0H =C2=A0 =C2=A0B------D =C2=A0= =C2=A0 =C2=A0G
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | +---/| AS 2 |= \ =C2=A0+------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |/ =C2=A0 =C2= =A0 +------+ \ | =C2=A0 =C2=A0 =C2=A0|---L/8
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 A =C2=A0 AS1 =C2=A0 C---+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0\| =C2=A0 =C2=A0 =C2=A0|
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |\\ =C2=A0\ =C2= =A0+------+ /| AS 4 |---M/8
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | \\ =C2=A0+-E = =C2=A0 =C2=A0 =C2=A0|/ +------+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0X =C2=A0 =C2=A0| =C2=A0\\ =C2= =A0 | =C2=A0 =C2=A0 =C2=A0K
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 +=3D= =3D=3DF AS 3 |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------+ =C2=A0 =C2=A0 =C2=A0 +------+
|
| =C2=A0 =C2=A0 =C2=A0The router F in AS 3 will chang= e itself as the Next-hop and allocate a
| =C2=A0 =C2=A0 =C2=A0new BGP label for the destination prefix L/8, then se= nd it to the router
| =C2=A0 =C2=A0 =C2=A0C, eg., using a new label: 5002
|
| =C2=A0 =C2=A0*Not quite right. Router F is not a MPLS router. It ju= st uses plain
| =C2=A0 =C2=A0IPv4/IPv6 forwarding. Please read this in the draft:
| =C2=A0 =C2=A0"o =C2=A0The solution MUST apply to the Internet use-ca= se where the Internet
| =C2=A0 =C2=A0routes are assumed to use IPv4 unlabeled or IPv6 unlabeled.*= "
| =C2=A0 =C2=A0*The entire EPE solution as described in the draft is contai= ned to AS1. AS
| =C2=A0 =C2=A02..4 are for illustration of the bigger picture only.
| =C2=A0 =C2=A0- - -
|
| =C2=A0 =C2=A0 =C2=A0=3D=3D=3DComments Begin=3D=3D=3D
| =C2=A0 =C2=A0 =C2=A0Deploying Inter-AS L3VPN Option B Services with refer= ence to the
|
| =C2=A0 =C2=A0*Let me clarify that the EPE draft does not talk about= VPN service.
| =C2=A0 =C2=A0It only uses L3VPN VPN mechanism within AS1 to distribute EP= E
| =C2=A0 =C2=A0*instrumentation data perhaps "VPN policy route" i= s a bit misleading term.
| =C2=A0 =C2=A0It really means that SAFI 128 is used for EPE steering label= s
| =C2=A0 =C2=A0distribution. It is still only IPv4/IPv6 Internet service. | =C2=A0 =C2=A0Said this your suggestion of using EPE within VPN service an= d specifically
| =C2=A0 =C2=A0at EPE enhanced option B peering is valid.
| =C2=A0 =C2=A0However if you would like to focus on using EPE for VPN serv= ice it seems
| =C2=A0 =C2=A0that new separate proposal may be required. There is few iss= ues associated
| =C2=A0 =C2=A0with this unique to such use case.
| =C2=A0 =C2=A0It can very well serve as parallel draft to Internet EPE use= case.
| =C2=A0 =C2=A0Thx,
| =C2=A0 =C2=A0R.

| _______________________________________________
| Idr mailing list
| Idr@ietf.org
| h= ttps://www.ietf.org/mailman/listinfo/idr


--001a11c2e654df34df04feb5990b-- From nobody Mon Jul 21 08:21:55 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560771A00AE; Mon, 21 Jul 2014 08:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlbSxkupaiIK; Mon, 21 Jul 2014 08:21:44 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0932E1A002C; Mon, 21 Jul 2014 08:21:43 -0700 (PDT) Received: from [2001:67c:370:176:c975:8fee:4dcf:475] (helo=wireless-a-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9FPI-0005Qi-Mv; Mon, 21 Jul 2014 16:21:40 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=GB2312 From: Rob Shakir In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C73@NKGEML512-MBS.china.huawei.com> Date: Mon, 21 Jul 2014 11:21:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <936EB71F-CBD2-4547-9A07-1C55F40B4314@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh>, <8D8AAE60-11B2-489A-877A-D315B8050D95@rob.sh> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C29@NKGEML512-MBS.china.huawei.com>, <77CEA301-8C51-4694-8B22-9ADDE19389CE@rob.sh> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295C73@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/gc7px8ZbliFeBPGJ9skpmrdKXt0 Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:21:45 -0000 On 21 Jul 2014, at 11:13, Xuxiaohu wrote: > [Xiaohu] If we need visibility of each mid-point on the path indeed, = does it mean that the capability of each mid-point should be propagated = across area boundaries? This could be one solution. One could observe that if we need to = propagate mid-point information across area boundaries, then we are = beginning to reduce any (perceived) benefit of running multiple areas.=20= Please note, I am not trying to state the need for any solution to this = issue, just note that there are challenges with such an approach to the = authors of the draft. If the intention of the draft is to recommend an = approach to the SPRING+EL issue, then potentially such considerations = should be taken into account when considering the technical efficacy of = each of the options described in the document. Cheers, r.=20 From nobody Mon Jul 21 19:52:46 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3AF1A0251 for ; Mon, 21 Jul 2014 19:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzA1D9s0NDic for ; Mon, 21 Jul 2014 19:52:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787AB1A0383 for ; Mon, 21 Jul 2014 19:52:42 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C05C62ADB41; Tue, 22 Jul 2014 04:52:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id A1E4C384049; Tue, 22 Jul 2014 04:52:37 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 04:52:37 +0200 From: To: Rob Shakir , "spring@ietf.org" Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGzFOMOyOFpYEWM2i7SQsHvQpurYA2g Date: Tue, 22 Jul 2014 02:52:36 +0000 Message-ID: <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> In-Reply-To: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.22118 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/pghlRxoZvxBSm1ILymom8bntiXs Cc: "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 02:52:45 -0000 Hi Rob, Many thanks to raise this important subject back on the table. Entropy label in SPRING is mainly a matter of what are the current capabili= ties of our favorite vendor's current HW ... Unfortunately, I think we are = touching something quite "secret" and vendors would not share their issues= publicly :) I think some options may also introduce some "HW capability" issues : - reusable EL and EL top of the stack : need multiple MPLS operation , so = it may require forwarding feedback loops on some HWs reducing the forwardin= g capacity Personally, I don't like (hate :) ), the multiple EL/ELI (at each tunnel le= vel or at specific point of insertion) because it would again reduce the av= ailable MTU for the customer jumbo frames. IMHO, I would be in favor of doing nothing if all vendors can publicly conf= irm that their current generation of HW are able to inspect between 10/15 l= abels :) Otherwise reusable EL and even EL at top of the stack sounds good = to me. EL at top of the stack may make some MPLS people crazy, but I person= ally found this kind of forwarding straightforward compared to reusable EL = (I like it also). EL at top of the stack may be compared to a MPLS router = alert label at top of the stack ...=20 We may also need to deal with cases where some SPRING nodes are not ELC on = the transit path, do we want to loose the EL or just try to avoid the non E= LC node(s) by reinserting ELI/EL at a position it could be reused further i= n the path on the next ELC capable SPRING node. Anyway as I said at the beginning, unfortunately for us (Service Providers)= , the technical solution is at more than 80% a vendor discussion ... Thanks again for bringing this back on the table :) Best regards, Stephane -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rob Shakir Sent: Monday, July 21, 2014 10:38 To: spring@ietf.org Cc: draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: [spring] SPRING MPLS and Entropy Label Hi SPRING, draft-kini. authors, I have a few comments on the discussion within this draft - and a quick que= stion on the intention around the document. - I feel that it would be useful to provide some clarification as to where = we expect entropy to be required for load-sharing in the draft. The current wording (to me) could be read to say that where Adj-SID is used, then the= re is no requirement to consider placement for EL since there will be no load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in draft-filsfils-spring-segment-routing-04), or the underlying transport fo= r an IGP adjacency can be multi-path (e.g., an aggregated Ethernet link) this is not true unless a head-end PE can guarantee that a particular adjacency is made up of a transport that has only 1 path (i.e., explicitly requires no load-balancing). I'm not sure how the iLER would actually det= ermine this, short of the definition of new per-adjacency advertisement capabili= ties. Even if it were able to, then it seems the result is very likely to be th= at an approach that requires per-hop entropy labels to be injected is going to guarantee label stack depth >=3D 3*[number of path SIDs]. I think that the above means that the current draft under-estimates the d= epth of the stack when considering an EL per tunnel (=A73.2), which might ampl= ify some of the concerns raised for this option.=20 - =A73.4 - I am not clear how we would really implement this option. If we = learn midpoint capabilities, and then tune our placement of the EL based on the= se, then it seems like the only viable approach is really to consider _all_ midpoints, and tune the placement according to the "shallowest" midpoint = in the network. This is because, whilst we might expect that there is routin= g via some particular path, this might change if there is ECMP between mid-poin= ts nodes where some paths have different capabilities than others, and equal= ly might change whilst re-routing occurs. In terms of discovery of the capabilities of a mid-point -- do we need to consider how, in a multi-area network, we discover the capabilities of a mid-point which might not have information about it leaked between areas? =20=20=20=20 - Finally, it'd be good to determine what the intention of the authors for = this document is. Do we expect that we make a recommendation as to what equipm= ent vendors who are going to support SR-MPLS should optimise for? At the mome= nt, the document is good at classifying the different approaches that _could_= be taken, but potentially requires an operator/vendor to consider optimisati= on for both a) reading very deep into the stack when acting as an LSR, b) pu= shing very deep stacks when acting as iLER, c) potentially implementing more co= mplex swap() operations, whereby some reshuffling of the EL is required.=20 My feeling is that it would be very useful for this document to be able to make a clear recommendation as to which of these approaches should be optimised for, and hence we should debate their technical efficacy. It'd = be good to understand whether the authors are intending to do this, or rather classify the approaches. Cheers, r. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 22 07:22:59 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE591A001B; Tue, 22 Jul 2014 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjDlcgee8hBr; Tue, 22 Jul 2014 07:22:53 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BF41B28DE; Tue, 22 Jul 2014 07:22:51 -0700 (PDT) Received: from [31.133.179.3] (helo=dhcp-b303.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9axt-0002Ya-9g; Tue, 22 Jul 2014 15:22:49 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Tue, 22 Jul 2014 10:22:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> To: "" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/s-NzbpVv0Qt1EkasB_CK0KO4K34 Cc: mpls@ietf.org, "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:22:56 -0000 Hi Stephane, On 21 Jul 2014, at 22:52, = wrote: > Hi Rob, >=20 > Many thanks to raise this important subject back on the table. > Entropy label in SPRING is mainly a matter of what are the current = capabilities of our favorite vendor's current HW ... Unfortunately, I = think we are touching something quite "secret" and vendors would not = share their issues publicly :) There are two things that we need to achieve w.r.t SR/MPLS and EL from = my perspective: 1) How do we exploit EL with *today=92s* hardware such that SR LSPs can = be efficiently load shared? 2) Going forward, which of the approaches that this draft identifies for = dealing with deep label stacks produced by SR/MPLS should we optimise = for? So, yes, I agree that there=92s something around current capabilities = that we need to figure out =97 but equally, I=92d like to visit question = (2), such that we can see whether the WG thinks that it is possible that = we can reach a recommendation and hence future hardware revisions can = potentially focus on optimising for one particular SR/MPLS + EL = approach.=20 > I think some options may also introduce some "HW capability" issues : > - reusable EL and EL top of the stack : need multiple MPLS operation = , so it may require forwarding feedback loops on some HWs reducing the = forwarding capacity >=20 > Personally, I don't like (hate :) ), the multiple EL/ELI (at each = tunnel level or at specific point of insertion) because it would again = reduce the available MTU for the customer jumbo frames. ACK =97 this is one of the reasons that I would like to understand the = author=92s intentions on this draft. At the moment, the draft is a = taxonomy of the approaches, but rather stops short of making any = recommendations. It sounds like you=92d be supportive of asking the = authors to extend this draft to making a recommendation? :-) Cheers, r. From nobody Tue Jul 22 07:27:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0481B2919; Tue, 22 Jul 2014 07:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFowUO1ZtdBj; Tue, 22 Jul 2014 07:27:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A3B1B290E; Tue, 22 Jul 2014 07:27:30 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id ABC0A3B4332; Tue, 22 Jul 2014 16:27:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 88E2D35C074; Tue, 22 Jul 2014 16:27:28 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 16:27:28 +0200 From: To: Rob Shakir Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGzFOMOyOFpYEWM2i7SQsHvQpurYA2ggAClVgCAACK8cA== Date: Tue, 22 Jul 2014 14:27:27 +0000 Message-ID: <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh> In-Reply-To: <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.100920 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/_1MfoKRZghs7jiJzlyEkm1eSE2I Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:27:36 -0000 > It sounds like you'd be supportive of asking the authors to extend this d= raft to making a recommendation? :-) Completely right :) -----Original Message----- From: Rob Shakir [mailto:rjs@rob.sh]=20 Sent: Tuesday, July 22, 2014 10:23 To: LITKOWSKI Stephane SCE/IBNF Cc: spring@ietf.org; draft-kini-mpls-spring-entropy-label@tools.ietf.org; m= pls@ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label Hi Stephane, On 21 Jul 2014, at 22:52, wrote: > Hi Rob, >=20 > Many thanks to raise this important subject back on the table. > Entropy label in SPRING is mainly a matter of what are the current capabi= lities of our favorite vendor's current HW ... Unfortunately, I think we ar= e touching something quite "secret" and vendors would not share their issu= es publicly :) There are two things that we need to achieve w.r.t SR/MPLS and EL from my p= erspective: 1) How do we exploit EL with *today's* hardware such that SR LSPs can be ef= ficiently load shared? 2) Going forward, which of the approaches that this draft identifies for de= aling with deep label stacks produced by SR/MPLS should we optimise for? So, yes, I agree that there's something around current capabilities that we= need to figure out - but equally, I'd like to visit question (2), such tha= t we can see whether the WG thinks that it is possible that we can reach a = recommendation and hence future hardware revisions can potentially focus on= optimising for one particular SR/MPLS + EL approach.=20 > I think some options may also introduce some "HW capability" issues : > - reusable EL and EL top of the stack : need multiple MPLS operation , s= o it may require forwarding feedback loops on some HWs reducing the forward= ing capacity >=20 > Personally, I don't like (hate :) ), the multiple EL/ELI (at each tunnel = level or at specific point of insertion) because it would again reduce the = available MTU for the customer jumbo frames. ACK - this is one of the reasons that I would like to understand the author= 's intentions on this draft. At the moment, the draft is a taxonomy of the = approaches, but rather stops short of making any recommendations. It sounds= like you'd be supportive of asking the authors to extend this draft to mak= ing a recommendation? :-) Cheers, r. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jul 22 07:39:17 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6119F1B288E; Tue, 22 Jul 2014 07:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bMhpIpuPizo; Tue, 22 Jul 2014 07:39:14 -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 D3F0C1B2886; Tue, 22 Jul 2014 07:39:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKK37638; Tue, 22 Jul 2014 14:39:11 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 15:39:10 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 22 Jul 2014 22:39:05 +0800 From: Xuxiaohu To: "stephane.litkowski@orange.com" , "Rob Shakir" Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpbkqcvy6UadNakKtgoaxQFrlmpusJ9pg Date: Tue, 22 Jul 2014 14:39:04 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh>, <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.44] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/11xMhkukwJO1r3zvE-F5aw-L4AQ Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:39:15 -0000 SSBwZXJzb25hbGx5IGRvbid0IGJlbGlldmUgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IG9mIG1h a2luZyB0aGF0IHJlY29tbWVuZGF0aW9uIGF0IHByZXNlbnQgc2luY2UgZWFjaCBvcHRpb24gaXMg b25seSBhcHBsaWNhbGJlIGluIGEgY2VydGFpbiBjb25kaXRpb24uIA0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogc3ByaW5nIFtzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbSBbc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21dDQq3osvNyrG85Dog MjAxNMTqN9TCMjLI1SAyMjoyNw0KytW8/sjLOiBSb2IgU2hha2lyDQqzrcvNOiBtcGxzQGlldGYu b3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJl bEB0b29scy5pZXRmLm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRy b3B5IExhYmVsDQoNCj4gSXQgc291bmRzIGxpa2UgeW91J2QgYmUgc3VwcG9ydGl2ZSBvZiBhc2tp bmcgdGhlIGF1dGhvcnMgdG8gZXh0ZW5kIHRoaXMgZHJhZnQgdG8gbWFraW5nIGEgcmVjb21tZW5k YXRpb24/IDotKQ0KDQpDb21wbGV0ZWx5IHJpZ2h0IDopDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFJvYiBTaGFraXIgW21haWx0bzpyanNAcm9iLnNoXQ0KU2VudDogVHVl c2RheSwgSnVseSAyMiwgMjAxNCAxMDoyMw0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJO Rg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxh YmVsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10g U1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0KSGkgU3RlcGhhbmUsDQoNCk9uIDIxIEp1 bCAyMDE0LCBhdCAyMjo1MiwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPiA8c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+IHdyb3RlOg0KDQo+IEhpIFJvYiwNCj4NCj4gTWFueSB0 aGFua3MgdG8gcmFpc2UgdGhpcyBpbXBvcnRhbnQgc3ViamVjdCBiYWNrIG9uIHRoZSB0YWJsZS4N Cj4gRW50cm9weSBsYWJlbCBpbiBTUFJJTkcgaXMgbWFpbmx5IGEgbWF0dGVyIG9mIHdoYXQgYXJl IHRoZSBjdXJyZW50IGNhcGFiaWxpdGllcyBvZiBvdXIgZmF2b3JpdGUgdmVuZG9yJ3MgY3VycmVu dCBIVyAuLi4gVW5mb3J0dW5hdGVseSwgSSB0aGluayB3ZSBhcmUgdG91Y2hpbmcgc29tZXRoaW5n IHF1aXRlICJzZWNyZXQiICBhbmQgdmVuZG9ycyB3b3VsZCBub3Qgc2hhcmUgdGhlaXIgaXNzdWVz IHB1YmxpY2x5IDopDQoNClRoZXJlIGFyZSB0d28gdGhpbmdzIHRoYXQgd2UgbmVlZCB0byBhY2hp ZXZlIHcuci50IFNSL01QTFMgYW5kIEVMIGZyb20gbXkgcGVyc3BlY3RpdmU6DQoNCjEpIEhvdyBk byB3ZSBleHBsb2l0IEVMIHdpdGggKnRvZGF5J3MqIGhhcmR3YXJlIHN1Y2ggdGhhdCBTUiBMU1Bz IGNhbiBiZSBlZmZpY2llbnRseSBsb2FkIHNoYXJlZD8NCjIpIEdvaW5nIGZvcndhcmQsIHdoaWNo IG9mIHRoZSBhcHByb2FjaGVzIHRoYXQgdGhpcyBkcmFmdCBpZGVudGlmaWVzIGZvciBkZWFsaW5n IHdpdGggZGVlcCBsYWJlbCBzdGFja3MgcHJvZHVjZWQgYnkgU1IvTVBMUyBzaG91bGQgd2Ugb3B0 aW1pc2UgZm9yPw0KDQpTbywgeWVzLCBJIGFncmVlIHRoYXQgdGhlcmUncyBzb21ldGhpbmcgYXJv dW5kIGN1cnJlbnQgY2FwYWJpbGl0aWVzIHRoYXQgd2UgbmVlZCB0byBmaWd1cmUgb3V0IC0gYnV0 IGVxdWFsbHksIEknZCBsaWtlIHRvIHZpc2l0IHF1ZXN0aW9uICgyKSwgc3VjaCB0aGF0IHdlIGNh biBzZWUgd2hldGhlciB0aGUgV0cgdGhpbmtzIHRoYXQgaXQgaXMgcG9zc2libGUgdGhhdCB3ZSBj YW4gcmVhY2ggYSByZWNvbW1lbmRhdGlvbiBhbmQgaGVuY2UgZnV0dXJlIGhhcmR3YXJlIHJldmlz aW9ucyBjYW4gcG90ZW50aWFsbHkgZm9jdXMgb24gb3B0aW1pc2luZyBmb3Igb25lIHBhcnRpY3Vs YXIgU1IvTVBMUyArIEVMIGFwcHJvYWNoLg0KDQo+IEkgdGhpbmsgc29tZSBvcHRpb25zIG1heSBh bHNvIGludHJvZHVjZSBzb21lICJIVyBjYXBhYmlsaXR5IiBpc3N1ZXMgOg0KPiAtIHJldXNhYmxl IEVMIGFuZCBFTCB0b3Agb2YgdGhlIHN0YWNrICA6IG5lZWQgbXVsdGlwbGUgTVBMUyBvcGVyYXRp b24gLCBzbyBpdCBtYXkgcmVxdWlyZSBmb3J3YXJkaW5nIGZlZWRiYWNrIGxvb3BzIG9uIHNvbWUg SFdzIHJlZHVjaW5nIHRoZSBmb3J3YXJkaW5nIGNhcGFjaXR5DQo+DQo+IFBlcnNvbmFsbHksIEkg ZG9uJ3QgbGlrZSAoaGF0ZSA6KSApLCB0aGUgbXVsdGlwbGUgRUwvRUxJIChhdCBlYWNoIHR1bm5l bCBsZXZlbCBvciBhdCBzcGVjaWZpYyBwb2ludCBvZiBpbnNlcnRpb24pIGJlY2F1c2UgaXQgd291 bGQgYWdhaW4gcmVkdWNlIHRoZSBhdmFpbGFibGUgTVRVIGZvciB0aGUgY3VzdG9tZXIganVtYm8g ZnJhbWVzLg0KDQpBQ0sgLSB0aGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB0aGF0IEkgd291bGQg bGlrZSB0byB1bmRlcnN0YW5kIHRoZSBhdXRob3IncyBpbnRlbnRpb25zIG9uIHRoaXMgZHJhZnQu IEF0IHRoZSBtb21lbnQsIHRoZSBkcmFmdCBpcyBhIHRheG9ub215IG9mIHRoZSBhcHByb2FjaGVz LCBidXQgcmF0aGVyIHN0b3BzIHNob3J0IG9mIG1ha2luZyBhbnkgcmVjb21tZW5kYXRpb25zLiBJ dCBzb3VuZHMgbGlrZSB5b3UnZCBiZSBzdXBwb3J0aXZlIG9mIGFza2luZyB0aGUgYXV0aG9ycyB0 byBleHRlbmQgdGhpcyBkcmFmdCB0byBtYWtpbmcgYSByZWNvbW1lbmRhdGlvbj8gOi0pDQoNCkNo ZWVycywNCnIuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc= From nobody Tue Jul 22 07:52:04 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F801B2955; Tue, 22 Jul 2014 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LTnTKSjrfrP; Tue, 22 Jul 2014 07:51:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284291B293A; Tue, 22 Jul 2014 07:51:42 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D6F8D18C19C; Tue, 22 Jul 2014 16:51:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7CD3335C076; Tue, 22 Jul 2014 16:51:40 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 16:51:40 +0200 From: To: Xuxiaohu , Rob Shakir Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGzFOMOyOFpYEWM2i7SQsHvQpurYA2ggAClVgCAACK8cP//4dUAgAAk5RA= Date: Tue, 22 Jul 2014 14:51:39 +0000 Message-ID: <26288_1406040700_53CE7A7C_26288_2992_3_9E32478DFA9976438E7A22F69B08FF920441CB@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh>, <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.100920 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/-Q8Xe8-4J1RmU-aRdCtbQ7ZCnqU Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:51:54 -0000 U28gbGV0J3MgZmluZCB0aGUgYmVzdCBjb21wcm9taXNlIC4uLiBidXQgd2UgY2FuJ3Qgc3RheSBz dHVjayAuLi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjIsIDIw MTQgMTA6MzkNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IFJvYiBTaGFraXINCkNj OiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmct ZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNQUklO RyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCkkgcGVyc29uYWxseSBkb24ndCBiZWxpZXZlIHRo ZXJlIGlzIGFueSBwb3NzaWJpbGl0eSBvZiBtYWtpbmcgdGhhdCByZWNvbW1lbmRhdGlvbiBhdCBw cmVzZW50IHNpbmNlIGVhY2ggb3B0aW9uIGlzIG9ubHkgYXBwbGljYWxiZSBpbiBhIGNlcnRhaW4g Y29uZGl0aW9uLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHNwcmluZyBbc3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmddILT6se0gc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gW3N0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjIyyNUgMjI6MjcNCsrVvP7Iyzog Um9iIFNoYWtpcg0Ks63LzTogbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBkcmFmdC1r aW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6IFJlOiBb c3ByaW5nXSBTUFJJTkcgTVBMUyBhbmQgRW50cm9weSBMYWJlbA0KDQo+IEl0IHNvdW5kcyBsaWtl IHlvdSdkIGJlIHN1cHBvcnRpdmUgb2YgYXNraW5nIHRoZSBhdXRob3JzIHRvIGV4dGVuZCANCj4g dGhpcyBkcmFmdCB0byBtYWtpbmcgYSByZWNvbW1lbmRhdGlvbj8gOi0pDQoNCkNvbXBsZXRlbHkg cmlnaHQgOikNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iIFNoYWtp ciBbbWFpbHRvOnJqc0Byb2Iuc2hdDQpTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDEwOjIz DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogc3ByaW5nQGlldGYub3JnOyBk cmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc7IG1wbHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTUFJJTkcgTVBMUyBhbmQgRW50cm9weSBM YWJlbA0KDQpIaSBTdGVwaGFuZSwNCg0KT24gMjEgSnVsIDIwMTQsIGF0IDIyOjUyLCA8c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+IDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4g d3JvdGU6DQoNCj4gSGkgUm9iLA0KPg0KPiBNYW55IHRoYW5rcyB0byByYWlzZSB0aGlzIGltcG9y dGFudCBzdWJqZWN0IGJhY2sgb24gdGhlIHRhYmxlLg0KPiBFbnRyb3B5IGxhYmVsIGluIFNQUklO RyBpcyBtYWlubHkgYSBtYXR0ZXIgb2Ygd2hhdCBhcmUgdGhlIGN1cnJlbnQgDQo+IGNhcGFiaWxp dGllcyBvZiBvdXIgZmF2b3JpdGUgdmVuZG9yJ3MgY3VycmVudCBIVyAuLi4gVW5mb3J0dW5hdGVs eSwgSSANCj4gdGhpbmsgd2UgYXJlIHRvdWNoaW5nIHNvbWV0aGluZyBxdWl0ZSAic2VjcmV0IiAg YW5kIHZlbmRvcnMgd291bGQgbm90IA0KPiBzaGFyZSB0aGVpciBpc3N1ZXMgcHVibGljbHkgOikN Cg0KVGhlcmUgYXJlIHR3byB0aGluZ3MgdGhhdCB3ZSBuZWVkIHRvIGFjaGlldmUgdy5yLnQgU1Iv TVBMUyBhbmQgRUwgZnJvbSBteSBwZXJzcGVjdGl2ZToNCg0KMSkgSG93IGRvIHdlIGV4cGxvaXQg RUwgd2l0aCAqdG9kYXkncyogaGFyZHdhcmUgc3VjaCB0aGF0IFNSIExTUHMgY2FuIGJlIGVmZmlj aWVudGx5IGxvYWQgc2hhcmVkPw0KMikgR29pbmcgZm9yd2FyZCwgd2hpY2ggb2YgdGhlIGFwcHJv YWNoZXMgdGhhdCB0aGlzIGRyYWZ0IGlkZW50aWZpZXMgZm9yIGRlYWxpbmcgd2l0aCBkZWVwIGxh YmVsIHN0YWNrcyBwcm9kdWNlZCBieSBTUi9NUExTIHNob3VsZCB3ZSBvcHRpbWlzZSBmb3I/DQoN ClNvLCB5ZXMsIEkgYWdyZWUgdGhhdCB0aGVyZSdzIHNvbWV0aGluZyBhcm91bmQgY3VycmVudCBj YXBhYmlsaXRpZXMgdGhhdCB3ZSBuZWVkIHRvIGZpZ3VyZSBvdXQgLSBidXQgZXF1YWxseSwgSSdk IGxpa2UgdG8gdmlzaXQgcXVlc3Rpb24gKDIpLCBzdWNoIHRoYXQgd2UgY2FuIHNlZSB3aGV0aGVy IHRoZSBXRyB0aGlua3MgdGhhdCBpdCBpcyBwb3NzaWJsZSB0aGF0IHdlIGNhbiByZWFjaCBhIHJl Y29tbWVuZGF0aW9uIGFuZCBoZW5jZSBmdXR1cmUgaGFyZHdhcmUgcmV2aXNpb25zIGNhbiBwb3Rl bnRpYWxseSBmb2N1cyBvbiBvcHRpbWlzaW5nIGZvciBvbmUgcGFydGljdWxhciBTUi9NUExTICsg RUwgYXBwcm9hY2guDQoNCj4gSSB0aGluayBzb21lIG9wdGlvbnMgbWF5IGFsc28gaW50cm9kdWNl IHNvbWUgIkhXIGNhcGFiaWxpdHkiIGlzc3VlcyA6DQo+IC0gcmV1c2FibGUgRUwgYW5kIEVMIHRv cCBvZiB0aGUgc3RhY2sgIDogbmVlZCBtdWx0aXBsZSBNUExTIG9wZXJhdGlvbiANCj4gLCBzbyBp dCBtYXkgcmVxdWlyZSBmb3J3YXJkaW5nIGZlZWRiYWNrIGxvb3BzIG9uIHNvbWUgSFdzIHJlZHVj aW5nIHRoZSANCj4gZm9yd2FyZGluZyBjYXBhY2l0eQ0KPg0KPiBQZXJzb25hbGx5LCBJIGRvbid0 IGxpa2UgKGhhdGUgOikgKSwgdGhlIG11bHRpcGxlIEVML0VMSSAoYXQgZWFjaCB0dW5uZWwgbGV2 ZWwgb3IgYXQgc3BlY2lmaWMgcG9pbnQgb2YgaW5zZXJ0aW9uKSBiZWNhdXNlIGl0IHdvdWxkIGFn YWluIHJlZHVjZSB0aGUgYXZhaWxhYmxlIE1UVSBmb3IgdGhlIGN1c3RvbWVyIGp1bWJvIGZyYW1l cy4NCg0KQUNLIC0gdGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCBJIHdvdWxkIGxpa2Ug dG8gdW5kZXJzdGFuZCB0aGUgYXV0aG9yJ3MgaW50ZW50aW9ucyBvbiB0aGlzIGRyYWZ0LiBBdCB0 aGUgbW9tZW50LCB0aGUgZHJhZnQgaXMgYSB0YXhvbm9teSBvZiB0aGUgYXBwcm9hY2hlcywgYnV0 IHJhdGhlciBzdG9wcyBzaG9ydCBvZiBtYWtpbmcgYW55IHJlY29tbWVuZGF0aW9ucy4gSXQgc291 bmRzIGxpa2UgeW91J2QgYmUgc3VwcG9ydGl2ZSBvZiBhc2tpbmcgdGhlIGF1dGhvcnMgdG8gZXh0 ZW5kIHRoaXMgZHJhZnQgdG8gbWFraW5nIGEgcmVjb21tZW5kYXRpb24/IDotKQ0KDQpDaGVlcnMs DQpyLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwg T3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVk LCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmlu Z0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1l cmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Tue Jul 22 08:05:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F9F1B288C; Tue, 22 Jul 2014 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoVKoxBJV_Ui; Tue, 22 Jul 2014 08:05:19 -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 BF7991A0AE5; Tue, 22 Jul 2014 08:05:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM36909; Tue, 22 Jul 2014 15:05:17 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Jul 2014 16:05:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 22 Jul 2014 23:05:09 +0800 From: Xuxiaohu To: "stephane.litkowski@orange.com" , "Rob Shakir" Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpbkqcvy6UadNakKtgoaxQFrlmpusJ9pg//9/eYCAAIjjDw== Date: Tue, 22 Jul 2014 15:05:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296047@NKGEML512-MBS.china.huawei.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh>, <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com>, <26288_1406040700_53CE7A7C_26288_2992_3_9E32478DFA9976438E7A22F69B08FF920441CB@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: <26288_1406040700_53CE7A7C_26288_2992_3_9E32478DFA9976438E7A22F69B08FF920441CB@OPEXCLILM34.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.44] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/MfVF9Swt63vBFa7AWsBJk2QPNOQ Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:05:22 -0000 SXQgbWFrZXMgbm8gc2Vuc2Ugb2YgbWFraW5nIHRoYXQgY29tcHJvbWlzZSwgSU1ITy4gSXQgc2Vl bXMgdGhhdCB0aGUgbW9zdCBmZWFzaWJsZSB3YXkgaXMgdG8gYWxsb3cgb3BlcmF0b3JzIHRoZW1z ZWx2ZXMgdG8gbWFrZSB0aGUgY2hvaWNlIGFtb25nIHRoZXNlIG9wdGlvbnMgYWNjb3JkaW5nIHRv IHRoZWlyIG5ldHdvcmsgY29uZGl0aW9ucy4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzogc3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb20gW3N0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tXQ0Kt6LL zcqxvOQ6IDIwMTTE6jfUwjIyyNUgMjI6NTENCsrVvP7IyzogWHV4aWFvaHU7IFJvYiBTaGFraXIN CrOty806IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQta2luaS1tcGxzLXNw cmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnDQrW98ziOiBSRTogW3NwcmluZ10gU1BS SU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0KU28gbGV0J3MgZmluZCB0aGUgYmVzdCBjb21w cm9taXNlIC4uLiBidXQgd2UgY2FuJ3Qgc3RheSBzdHVjayAuLi4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29t XQ0KU2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCAxMDozOQ0KVG86IExJVEtPV1NLSSBTdGVw aGFuZSBTQ0UvSUJORjsgUm9iIFNoYWtpcg0KQ2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRm Lm9yZzsgZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0K SSBwZXJzb25hbGx5IGRvbid0IGJlbGlldmUgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IG9mIG1h a2luZyB0aGF0IHJlY29tbWVuZGF0aW9uIGF0IHByZXNlbnQgc2luY2UgZWFjaCBvcHRpb24gaXMg b25seSBhcHBsaWNhbGJlIGluIGEgY2VydGFpbiBjb25kaXRpb24uDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjL OiBzcHJpbmcgW3NwcmluZy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAy MDE0xOo31MIyMsjVIDIyOjI3DQrK1bz+yMs6IFJvYiBTaGFraXINCrOty806IG1wbHNAaWV0Zi5v cmc7IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVs QHRvb2xzLmlldGYub3JnDQrW98ziOiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJv cHkgTGFiZWwNCg0KPiBJdCBzb3VuZHMgbGlrZSB5b3UnZCBiZSBzdXBwb3J0aXZlIG9mIGFza2lu ZyB0aGUgYXV0aG9ycyB0byBleHRlbmQNCj4gdGhpcyBkcmFmdCB0byBtYWtpbmcgYSByZWNvbW1l bmRhdGlvbj8gOi0pDQoNCkNvbXBsZXRlbHkgcmlnaHQgOikNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUm9iIFNoYWtpciBbbWFpbHRvOnJqc0Byb2Iuc2hdDQpTZW50OiBU dWVzZGF5LCBKdWx5IDIyLCAyMDE0IDEwOjIzDQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9J Qk5GDQpDYzogc3ByaW5nQGlldGYub3JnOyBkcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHkt bGFiZWxAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5n XSBTUFJJTkcgTVBMUyBhbmQgRW50cm9weSBMYWJlbA0KDQpIaSBTdGVwaGFuZSwNCg0KT24gMjEg SnVsIDIwMTQsIGF0IDIyOjUyLCA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IDxzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj4gSGkgUm9iLA0KPg0KPiBNYW55 IHRoYW5rcyB0byByYWlzZSB0aGlzIGltcG9ydGFudCBzdWJqZWN0IGJhY2sgb24gdGhlIHRhYmxl Lg0KPiBFbnRyb3B5IGxhYmVsIGluIFNQUklORyBpcyBtYWlubHkgYSBtYXR0ZXIgb2Ygd2hhdCBh cmUgdGhlIGN1cnJlbnQNCj4gY2FwYWJpbGl0aWVzIG9mIG91ciBmYXZvcml0ZSB2ZW5kb3IncyBj dXJyZW50IEhXIC4uLiBVbmZvcnR1bmF0ZWx5LCBJDQo+IHRoaW5rIHdlIGFyZSB0b3VjaGluZyBz b21ldGhpbmcgcXVpdGUgInNlY3JldCIgIGFuZCB2ZW5kb3JzIHdvdWxkIG5vdA0KPiBzaGFyZSB0 aGVpciBpc3N1ZXMgcHVibGljbHkgOikNCg0KVGhlcmUgYXJlIHR3byB0aGluZ3MgdGhhdCB3ZSBu ZWVkIHRvIGFjaGlldmUgdy5yLnQgU1IvTVBMUyBhbmQgRUwgZnJvbSBteSBwZXJzcGVjdGl2ZToN Cg0KMSkgSG93IGRvIHdlIGV4cGxvaXQgRUwgd2l0aCAqdG9kYXkncyogaGFyZHdhcmUgc3VjaCB0 aGF0IFNSIExTUHMgY2FuIGJlIGVmZmljaWVudGx5IGxvYWQgc2hhcmVkPw0KMikgR29pbmcgZm9y d2FyZCwgd2hpY2ggb2YgdGhlIGFwcHJvYWNoZXMgdGhhdCB0aGlzIGRyYWZ0IGlkZW50aWZpZXMg Zm9yIGRlYWxpbmcgd2l0aCBkZWVwIGxhYmVsIHN0YWNrcyBwcm9kdWNlZCBieSBTUi9NUExTIHNo b3VsZCB3ZSBvcHRpbWlzZSBmb3I/DQoNClNvLCB5ZXMsIEkgYWdyZWUgdGhhdCB0aGVyZSdzIHNv bWV0aGluZyBhcm91bmQgY3VycmVudCBjYXBhYmlsaXRpZXMgdGhhdCB3ZSBuZWVkIHRvIGZpZ3Vy ZSBvdXQgLSBidXQgZXF1YWxseSwgSSdkIGxpa2UgdG8gdmlzaXQgcXVlc3Rpb24gKDIpLCBzdWNo IHRoYXQgd2UgY2FuIHNlZSB3aGV0aGVyIHRoZSBXRyB0aGlua3MgdGhhdCBpdCBpcyBwb3NzaWJs ZSB0aGF0IHdlIGNhbiByZWFjaCBhIHJlY29tbWVuZGF0aW9uIGFuZCBoZW5jZSBmdXR1cmUgaGFy ZHdhcmUgcmV2aXNpb25zIGNhbiBwb3RlbnRpYWxseSBmb2N1cyBvbiBvcHRpbWlzaW5nIGZvciBv bmUgcGFydGljdWxhciBTUi9NUExTICsgRUwgYXBwcm9hY2guDQoNCj4gSSB0aGluayBzb21lIG9w dGlvbnMgbWF5IGFsc28gaW50cm9kdWNlIHNvbWUgIkhXIGNhcGFiaWxpdHkiIGlzc3VlcyA6DQo+ IC0gcmV1c2FibGUgRUwgYW5kIEVMIHRvcCBvZiB0aGUgc3RhY2sgIDogbmVlZCBtdWx0aXBsZSBN UExTIG9wZXJhdGlvbg0KPiAsIHNvIGl0IG1heSByZXF1aXJlIGZvcndhcmRpbmcgZmVlZGJhY2sg bG9vcHMgb24gc29tZSBIV3MgcmVkdWNpbmcgdGhlDQo+IGZvcndhcmRpbmcgY2FwYWNpdHkNCj4N Cj4gUGVyc29uYWxseSwgSSBkb24ndCBsaWtlIChoYXRlIDopICksIHRoZSBtdWx0aXBsZSBFTC9F TEkgKGF0IGVhY2ggdHVubmVsIGxldmVsIG9yIGF0IHNwZWNpZmljIHBvaW50IG9mIGluc2VydGlv bikgYmVjYXVzZSBpdCB3b3VsZCBhZ2FpbiByZWR1Y2UgdGhlIGF2YWlsYWJsZSBNVFUgZm9yIHRo ZSBjdXN0b21lciBqdW1ibyBmcmFtZXMuDQoNCkFDSyAtIHRoaXMgaXMgb25lIG9mIHRoZSByZWFz b25zIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIGF1dGhvcidzIGludGVudGlv bnMgb24gdGhpcyBkcmFmdC4gQXQgdGhlIG1vbWVudCwgdGhlIGRyYWZ0IGlzIGEgdGF4b25vbXkg b2YgdGhlIGFwcHJvYWNoZXMsIGJ1dCByYXRoZXIgc3RvcHMgc2hvcnQgb2YgbWFraW5nIGFueSBy ZWNvbW1lbmRhdGlvbnMuIEl0IHNvdW5kcyBsaWtlIHlvdSdkIGJlIHN1cHBvcnRpdmUgb2YgYXNr aW5nIHRoZSBhdXRob3JzIHRvIGV4dGVuZCB0aGlzIGRyYWZ0IHRvIG1ha2luZyBhIHJlY29tbWVu ZGF0aW9uPyA6LSkNCg0KQ2hlZXJzLA0Kci4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3Uu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJp bmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3Uu From nobody Tue Jul 22 08:20:18 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3471B297B; Tue, 22 Jul 2014 08:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCYz-iE2Pr1X; Tue, 22 Jul 2014 08:20:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636D31B2949; Tue, 22 Jul 2014 08:20:10 -0700 (PDT) Received: from [31.133.179.3] (helo=dhcp-b303.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9brL-0002fI-2I; Tue, 22 Jul 2014 16:20:07 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=gb18030 From: Rob Shakir In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296047@NKGEML512-MBS.china.huawei.com> Date: Tue, 22 Jul 2014 11:20:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh>, <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com>, <26288_1406040700_53CE7A7C_26288_2992_3_9E32478DFA9976438E7A22F69B08FF920441CB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296047@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3IvFddHXUJWDuk-EsQB27TYEGFk Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:20:16 -0000 On 22 Jul 2014, at 11:05, Xuxiaohu wrote: > It makes no sense of making that compromise, IMHO. It seems that the = most feasible way is to allow operators themselves to make the choice = among these options according to their network conditions. Such a recommendation does not have to say that this is the ONLY = solution that can be used. However, it is very likely that a number of = operators have a common set of limitations (given that we know there are = commonalities in deployed h/w). IMVHO, the thing that we should avoid is = that e.g., Stephane asks to support solution 1, and I ask for support = for solution 2 =A1=AA such that (as a community) we end up needing to = support 1 && 2, when maybe we could have reached some comment = recommendation such that there was only need for support for 1 || 2. Let=A1=AFs wait and hear from the authors of the draft whether they = intend to put forward some recommendation. If they do not, and rather it = should be an operator=A1=AFs choice, perhaps then the numerous operators = that are involved in the SR/MPLS can instead try and make such a = recommendation if we see that there is value in it. However, as Stephane = pointed out, this is not a decision that can be made in isolation from = those that build h/w. r.= From nobody Tue Jul 22 08:28:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0111B297A; Tue, 22 Jul 2014 08:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J84--DYzKcb7; Tue, 22 Jul 2014 08:28:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A5E1B299C; Tue, 22 Jul 2014 08:28:02 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 816563741FE; Tue, 22 Jul 2014 17:28:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 5FF7C38409A; Tue, 22 Jul 2014 17:28:00 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.77]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Tue, 22 Jul 2014 17:28:00 +0200 From: To: Xuxiaohu , Rob Shakir Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGzFOMOyOFpYEWM2i7SQsHvQpurYA2ggAClVgCAACK8cP//4dUAgAAk5RD//+JjAIAAJ4dA Date: Tue, 22 Jul 2014 15:27:59 +0000 Message-ID: <32399_1406042880_53CE8300_32399_4850_1_9E32478DFA9976438E7A22F69B08FF9204426C@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <25011_1405997557_53CDD1F5_25011_16883_1_9E32478DFA9976438E7A22F69B08FF92043E06@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10DD5659-8B99-42A4-9B1D-18439CF0C832@rob.sh>, <26290_1406039248_53CE74D0_26290_10984_1_9E32478DFA9976438E7A22F69B08FF92044175@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08295FC3@NKGEML512-MBS.china.huawei.com>, <26288_1406040700_53CE7A7C_26288_2992_3_9E32478DFA9976438E7A22F69B08FF920441CB@OPEXCLILM34.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296047@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296047@NKGEML512-MBS.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.141219 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/L1wZD1827vrvjL7G_pjsP1rF9QU Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:28:06 -0000 SGF2aW5nIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucyBtYWtlcyBubyBzZW5zZSB0byBtZSA6DQot IGNvbXBsZXggdG8gdW5kZXJzdGFuZCBpbiBvcGVyYXRpb25zDQotICBpbnRlcm9wIHRvIGhhbmRs ZQ0KLSB2ZW5kb3JzIHdpbGwgbm90IGltcGxlbWVudCBhbGwgdGhlIG9wdGlvbnMsIGFzIHNvbWUg aGF2ZSBIVyBkZXZlbG9wbWVudCBuZWVkcy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXSANClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTE6MDUNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lC TkY7IFJvYiBTaGFraXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0 LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDog UmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCkl0IG1ha2VzIG5v IHNlbnNlIG9mIG1ha2luZyB0aGF0IGNvbXByb21pc2UsIElNSE8uIEl0IHNlZW1zIHRoYXQgdGhl IG1vc3QgZmVhc2libGUgd2F5IGlzIHRvIGFsbG93IG9wZXJhdG9ycyB0aGVtc2VsdmVzIHRvIG1h a2UgdGhlIGNob2ljZSBhbW9uZyB0aGVzZSBvcHRpb25zIGFjY29yZGluZyB0byB0aGVpciBuZXR3 b3JrIGNvbmRpdGlvbnMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tIFtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbV0NCreiy83KsbzkOiAyMDE0 xOo31MIyMsjVIDIyOjUxDQrK1bz+yMs6IFh1eGlhb2h1OyBSb2IgU2hha2lyDQqzrcvNOiBtcGxz QGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9w eS1sYWJlbEB0b29scy5pZXRmLm9yZw0K1vfM4jogUkU6IFtzcHJpbmddIFNQUklORyBNUExTIGFu ZCBFbnRyb3B5IExhYmVsDQoNClNvIGxldCdzIGZpbmQgdGhlIGJlc3QgY29tcHJvbWlzZSAuLi4g YnV0IHdlIGNhbid0IHN0YXkgc3R1Y2sgLi4uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMjIsIDIwMTQgMTA6MzkNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lC TkY7IFJvYiBTaGFraXINCkNjOiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0 LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDog UmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCkkgcGVyc29uYWxs eSBkb24ndCBiZWxpZXZlIHRoZXJlIGlzIGFueSBwb3NzaWJpbGl0eSBvZiBtYWtpbmcgdGhhdCBy ZWNvbW1lbmRhdGlvbiBhdCBwcmVzZW50IHNpbmNlIGVhY2ggb3B0aW9uIGlzIG9ubHkgYXBwbGlj YWxiZSBpbiBhIGNlcnRhaW4gY29uZGl0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iyzogc3ByaW5nIFtz cHJpbmctYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bSBbc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb21dDQq3osvNyrG85DogMjAxNMTqN9TCMjLI 1SAyMjoyNw0KytW8/sjLOiBSb2IgU2hha2lyDQqzrcvNOiBtcGxzQGlldGYub3JnOyBzcHJpbmdA aWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRm Lm9yZw0K1vfM4jogUmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoN Cj4gSXQgc291bmRzIGxpa2UgeW91J2QgYmUgc3VwcG9ydGl2ZSBvZiBhc2tpbmcgdGhlIGF1dGhv cnMgdG8gZXh0ZW5kIA0KPiB0aGlzIGRyYWZ0IHRvIG1ha2luZyBhIHJlY29tbWVuZGF0aW9uPyA6 LSkNCg0KQ29tcGxldGVseSByaWdodCA6KQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBSb2IgU2hha2lyIFttYWlsdG86cmpzQHJvYi5zaF0NClNlbnQ6IFR1ZXNkYXksIEp1 bHkgMjIsIDIwMTQgMTA6MjMNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBz cHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29s cy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNQUklORyBN UExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCkhpIFN0ZXBoYW5lLA0KDQpPbiAyMSBKdWwgMjAxNCwg YXQgMjI6NTIsIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4gPHN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPiBIaSBSb2IsDQo+DQo+IE1hbnkgdGhhbmtzIHRv IHJhaXNlIHRoaXMgaW1wb3J0YW50IHN1YmplY3QgYmFjayBvbiB0aGUgdGFibGUuDQo+IEVudHJv cHkgbGFiZWwgaW4gU1BSSU5HIGlzIG1haW5seSBhIG1hdHRlciBvZiB3aGF0IGFyZSB0aGUgY3Vy cmVudCANCj4gY2FwYWJpbGl0aWVzIG9mIG91ciBmYXZvcml0ZSB2ZW5kb3IncyBjdXJyZW50IEhX IC4uLiBVbmZvcnR1bmF0ZWx5LCBJIA0KPiB0aGluayB3ZSBhcmUgdG91Y2hpbmcgc29tZXRoaW5n IHF1aXRlICJzZWNyZXQiICBhbmQgdmVuZG9ycyB3b3VsZCBub3QgDQo+IHNoYXJlIHRoZWlyIGlz c3VlcyBwdWJsaWNseSA6KQ0KDQpUaGVyZSBhcmUgdHdvIHRoaW5ncyB0aGF0IHdlIG5lZWQgdG8g YWNoaWV2ZSB3LnIudCBTUi9NUExTIGFuZCBFTCBmcm9tIG15IHBlcnNwZWN0aXZlOg0KDQoxKSBI b3cgZG8gd2UgZXhwbG9pdCBFTCB3aXRoICp0b2RheSdzKiBoYXJkd2FyZSBzdWNoIHRoYXQgU1Ig TFNQcyBjYW4gYmUgZWZmaWNpZW50bHkgbG9hZCBzaGFyZWQ/DQoyKSBHb2luZyBmb3J3YXJkLCB3 aGljaCBvZiB0aGUgYXBwcm9hY2hlcyB0aGF0IHRoaXMgZHJhZnQgaWRlbnRpZmllcyBmb3IgZGVh bGluZyB3aXRoIGRlZXAgbGFiZWwgc3RhY2tzIHByb2R1Y2VkIGJ5IFNSL01QTFMgc2hvdWxkIHdl IG9wdGltaXNlIGZvcj8NCg0KU28sIHllcywgSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgc29tZXRoaW5n IGFyb3VuZCBjdXJyZW50IGNhcGFiaWxpdGllcyB0aGF0IHdlIG5lZWQgdG8gZmlndXJlIG91dCAt IGJ1dCBlcXVhbGx5LCBJJ2QgbGlrZSB0byB2aXNpdCBxdWVzdGlvbiAoMiksIHN1Y2ggdGhhdCB3 ZSBjYW4gc2VlIHdoZXRoZXIgdGhlIFdHIHRoaW5rcyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRoYXQg d2UgY2FuIHJlYWNoIGEgcmVjb21tZW5kYXRpb24gYW5kIGhlbmNlIGZ1dHVyZSBoYXJkd2FyZSBy ZXZpc2lvbnMgY2FuIHBvdGVudGlhbGx5IGZvY3VzIG9uIG9wdGltaXNpbmcgZm9yIG9uZSBwYXJ0 aWN1bGFyIFNSL01QTFMgKyBFTCBhcHByb2FjaC4NCg0KPiBJIHRoaW5rIHNvbWUgb3B0aW9ucyBt YXkgYWxzbyBpbnRyb2R1Y2Ugc29tZSAiSFcgY2FwYWJpbGl0eSIgaXNzdWVzIDoNCj4gLSByZXVz YWJsZSBFTCBhbmQgRUwgdG9wIG9mIHRoZSBzdGFjayAgOiBuZWVkIG11bHRpcGxlIE1QTFMgb3Bl cmF0aW9uIA0KPiAsIHNvIGl0IG1heSByZXF1aXJlIGZvcndhcmRpbmcgZmVlZGJhY2sgbG9vcHMg b24gc29tZSBIV3MgcmVkdWNpbmcgdGhlIA0KPiBmb3J3YXJkaW5nIGNhcGFjaXR5DQo+DQo+IFBl cnNvbmFsbHksIEkgZG9uJ3QgbGlrZSAoaGF0ZSA6KSApLCB0aGUgbXVsdGlwbGUgRUwvRUxJIChh dCBlYWNoIHR1bm5lbCBsZXZlbCBvciBhdCBzcGVjaWZpYyBwb2ludCBvZiBpbnNlcnRpb24pIGJl Y2F1c2UgaXQgd291bGQgYWdhaW4gcmVkdWNlIHRoZSBhdmFpbGFibGUgTVRVIGZvciB0aGUgY3Vz dG9tZXIganVtYm8gZnJhbWVzLg0KDQpBQ0sgLSB0aGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyB0 aGF0IEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBhdXRob3IncyBpbnRlbnRpb25zIG9u IHRoaXMgZHJhZnQuIEF0IHRoZSBtb21lbnQsIHRoZSBkcmFmdCBpcyBhIHRheG9ub215IG9mIHRo ZSBhcHByb2FjaGVzLCBidXQgcmF0aGVyIHN0b3BzIHNob3J0IG9mIG1ha2luZyBhbnkgcmVjb21t ZW5kYXRpb25zLiBJdCBzb3VuZHMgbGlrZSB5b3UnZCBiZSBzdXBwb3J0aXZlIG9mIGFza2luZyB0 aGUgYXV0aG9ycyB0byBleHRlbmQgdGhpcyBkcmFmdCB0byBtYWtpbmcgYSByZWNvbW1lbmRhdGlv bj8gOi0pDQoNCkNoZWVycywNCnIuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1h aWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpU aGFuayB5b3UuCgo= From nobody Tue Jul 22 23:40:43 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278FB1A0032; Tue, 22 Jul 2014 23:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PztxrYzKvS7s; Tue, 22 Jul 2014 23:40:39 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01561A002F; Tue, 22 Jul 2014 23:40:38 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so1050198pdj.0 for ; Tue, 22 Jul 2014 23:40:38 -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:content-type; bh=yn5bWtQUAR54EZoEIufVuAMhPXj1DIWlRNApNjobP4U=; b=jt8YDJcztdn+IC9uF7U5PlFfPQRaF2VuGiO7AlobCX0tpZlarO36b7WS70aXSJD/L6 uhRD/1/SPfx0WyfroVsmbJyo639su+pEXSmGJ/A0y/WNPoQpxFf4Vg9S6rYux5Cvupgn w671Q38HUBUgMMyX0/ea9AIeL+uhYxkLIiJc5rPpWM7ho1xISmluUxaE05moUZNIMaRt brHsF1TNmbjI5CmgAAypchWdJfTM18GLAL/pw4MljeHc5hoj7MQR/9bFDAwqFbztKhyF YpwTsL2GYfiNsS//4qZHmQesWLAD/hSMqinI6r1sLfLIt6LZUPdTpwtsff59lejNJPEE tMqA== X-Received: by 10.70.50.230 with SMTP id f6mr8014200pdo.84.1406097638644; Tue, 22 Jul 2014 23:40:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.136.167 with HTTP; Tue, 22 Jul 2014 23:40:08 -0700 (PDT) In-Reply-To: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> From: Sri Date: Tue, 22 Jul 2014 23:40:08 -0700 Message-ID: To: Rob Shakir Content-Type: multipart/alternative; boundary=089e0158c8d04563a404fed69e29 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/hT7DubKyYHglXxNcmh2ECtGSwXA Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 06:40:41 -0000 --089e0158c8d04563a404fed69e29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rob, see inline. [MPLS WG added to discussion] On Mon, Jul 21, 2014 at 7:38 AM, Rob Shakir wrote: > Hi SPRING, draft-kini=E2=80=A6 authors, > > I have a few comments on the discussion within this draft =E2=80=94 and a= quick > question > on the intention around the document. > > - I feel that it would be useful to provide some clarification as to wher= e > we > expect entropy to be required for load-sharing in the draft. The curren= t > wording (to me) could be read to say that where Adj-SID is used, then > there > is no requirement to consider placement for EL since there will be no > load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 in > draft-filsfils-spring-segment-routing-04), or the underlying transport > for an > IGP adjacency can be multi-path (e.g., an aggregated Ethernet link) > this is not true unless a head-end PE can guarantee that a particular > adjacency is made up of a transport that has only 1 path (i.e., > explicitly > requires no load-balancing). I'm not sure how the iLER would actually > determine > this, short of the definition of new per-adjacency advertisement > capabilities. > Even if it were able to, then it seems the result is very likely to be > that an > approach that requires per-hop entropy labels to be injected is going t= o > guarantee label stack depth >=3D 3*[number of path SIDs]. > Sri> You are correct. If a SID identifies multiple physical paths as in the case of Adj-SID identifying a bundle, then load balancing on that segment would be useful. When there is no information that every SID of a LSP maps to a single physical path, a load-balancing mechanism should be used for that LSP. I agree that today there is no mechanism to give such information about the mapping, so load balancing on every segment is useful. Whether that is achieved by using an EL per segment as described in sec 3.2 thereby resulting in a label stack of 3*#SIDs is something to be discussed. The draft lists the downsides of choosing that option. > > I think that the above means that the current draft under-estimates the > depth > of the stack when considering an EL per tunnel (=C2=A73.2), which might > amplify > some of the concerns raised for this option. > Sri> The draft does not estimate stack depth (without EL) since the depth is dependent on the degree of strict-hop traffic-engineering desired by the application. If you meant to say that the label stack is deep due to the application trying to make it as close to the desired physical path but you end up using the EL per segment anyways since there isn't information to determine for sure whether the mapping is to a single physical path, then yes the label stack will be very deep. > > - =C2=A73.4 - I am not clear how we would really implement this option. I= f we > learn > midpoint capabilities, and then tune our placement of the EL based on > these, > then it seems like the only viable approach is really to consider _all_ > midpoints, and tune the placement according to the "shallowest" midpoin= t > in > the network. This is because, whilst we might expect that there is > routing via > some particular path, this might change if there is ECMP between > mid-points > nodes where some paths have different capabilities than others, and > equally > might change whilst re-routing occurs. > Sri> This is correct. In case of re-routing from ingress, the algorithm to compute EL depths have to be re-computed. If the re-route is like FRR via a bypass LSP, the PLR may want to insert ELs if load-balancing is desired along the bypass. > > In terms of discovery of the capabilities of a mid-point -- do we need = to > consider how, in a multi-area network, we discover the capabilities of = a > mid-point which might not have information about it leaked between area= s? > Sri> Option in 3.4 runs into such complications in case of multi-area. All such cases have not been addressed yet for the option in 3.4 > > - Finally, it'd be good to determine what the intention of the authors fo= r > this > document is. Do we expect that we make a recommendation as to what > equipment > vendors who are going to support SR-MPLS should optimise for? At the > moment, > the document is good at classifying the different approaches that > _could_ be > taken, but potentially requires an operator/vendor to consider > optimisation > for both a) reading very deep into the stack when acting as an LSR, b) > pushing > very deep stacks when acting as iLER, c) potentially implementing more > complex > swap() operations, whereby some reshuffling of the EL is required. > > My feeling is that it would be very useful for this document to be able > to > make a clear recommendation as to which of these approaches should be > optimised for, and hence we should debate their technical efficacy. It'= d > be > good to understand whether the authors are intending to do this, or > rather > classify the approaches. > Sri> The first goal of the draft was to list the various approaches. But the final goal is to come up with recommendations through the discussions on the various approaches. > > Cheers, > r. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > Thanks Sri --089e0158c8d04563a404fed69e29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rob, see inline.

[MPLS WG added to d= iscussion]


On Mon, Jul 21, 2014 at 7:38 AM, Rob Shakir <rjs@rob.sh> wrote:
Hi SPRING, draft-kini=E2=80=A6 authors,

I have a few comments on the discussion within this draft =E2=80=94 and a q= uick question
on the intention around the document.

- I feel that it would be useful to provide some clarification as to where = we
=C2=A0 expect entropy to be required for load-sharing in the draft. The cur= rent
=C2=A0 wording (to me) could be read to say that where Adj-SID is used, the= n there
=C2=A0 is no requirement to consider placement for EL since there will be n= o
=C2=A0 load-balancing. However, since Adj-SID can apply to a bundle (3.5.1 = in
=C2=A0 draft-filsfils-spring-segment-routing-04), or the underlying transpo= rt for an
=C2=A0 IGP adjacency can be multi-path (e.g., an aggregated Ethernet link)<= br> =C2=A0 this is not true unless a head-end PE can guarantee that a particula= r
=C2=A0 adjacency is made up of a transport that has only 1 path (i.e., expl= icitly
=C2=A0 requires no load-balancing). I'm not sure how the iLER would act= ually determine
=C2=A0 this, short of the definition of new per-adjacency advertisement cap= abilities.
=C2=A0 Even if it were able to, then it seems the result is very likely to = be that an
=C2=A0 approach that requires per-hop entropy labels to be injected is goin= g to
=C2=A0 guarantee label stack depth >=3D 3*[number of path SIDs].

Sri> You are correct. If a SID identifies m= ultiple physical paths as in the case of Adj-SID identifying a bundle, then= load balancing on that segment would be useful. When there is no informati= on that every SID of a LSP maps to a single physical path, a load-balancing= mechanism should be used for that LSP. I agree that today there is no mech= anism to give such information about the mapping, so load balancing on ever= y segment is useful. Whether that is achieved by using an EL per segment as= described in sec 3.2 thereby resulting in a label stack of 3*#SIDs is some= thing to be discussed. The draft lists the downsides of choosing that optio= n.=C2=A0
=C2=A0

=C2=A0 I think that the above means that the current draft under-estimates = the depth
=C2=A0 of the stack when considering an EL per tunnel (=C2=A73.2), which mi= ght amplify
=C2=A0 some of the concerns raised for this option.

Sri> The draft does not estimate stack depth= (without EL) since the depth is dependent on the degree of strict-hop traf= fic-engineering desired by the application. If you meant to say that the la= bel stack is deep due to the application trying to make it as close to the = desired physical path but you end up using the EL per segment anyways since= there isn't information to determine for sure whether the mapping is t= o a single physical path, then yes the label stack will be very deep.=C2=A0=
=C2=A0

- =C2=A73.4 - I am not clear how we would really implement this option. If = we learn
=C2=A0 midpoint capabilities, and then tune our placement of the EL based o= n these,
=C2=A0 then it seems like the only viable approach is really to consider _a= ll_
=C2=A0 midpoints, and tune the placement according to the "shallowest&= quot; midpoint in
=C2=A0 the network. This is because, whilst we might expect that there is r= outing via
=C2=A0 some particular path, this might change if there is ECMP between mid= -points
=C2=A0 nodes where some paths have different capabilities than others, and = equally
=C2=A0 might change whilst re-routing occurs.

Sri> This is correct. In case of re-routing from ingress, the alg= orithm to compute EL depths have to be re-computed. If the re-route is like= FRR via a bypass LSP, the PLR may want to insert ELs if load-balancing is = desired along the bypass.=C2=A0
=C2=A0

=C2=A0 In terms of discovery of the capabilities of a mid-point -- do we ne= ed to
=C2=A0 consider how, in a multi-area network, we discover the capabilities = of a
=C2=A0 mid-point which might not have information about it leaked between a= reas?

Sri> Option in 3.4 runs into s= uch complications in case of multi-area. All such cases have not been addre= ssed yet for the option in 3.4
=C2=A0

- Finally, it'd be good to determine what the intention of the authors = for this
=C2=A0 document is. Do we expect that we make a recommendation as to what e= quipment
=C2=A0 vendors who are going to support SR-MPLS should optimise for? At the= moment,
=C2=A0 the document is good at classifying the different approaches that _c= ould_ be
=C2=A0 taken, but potentially requires an operator/vendor to consider optim= isation
=C2=A0 for both a) reading very deep into the stack when acting as an LSR, = b) pushing
=C2=A0 very deep stacks when acting as iLER, c) potentially implementing mo= re complex
=C2=A0 swap() operations, whereby some reshuffling of the EL is required.
=C2=A0 My feeling is that it would be very useful for this document to be a= ble to
=C2=A0 make a clear recommendation as to which of these approaches should b= e
=C2=A0 optimised for, and hence we should debate their technical efficacy. = It'd be
=C2=A0 good to understand whether the authors are intending to do this, or = rather
=C2=A0 classify the approaches.

Sri>= The first goal of the draft was to list the various approaches. But the fi= nal goal is to come up with recommendations through the discussions on the = various approaches.
=C2=A0

Cheers,
r.


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

Thanks
Sri
--089e0158c8d04563a404fed69e29-- From nobody Wed Jul 23 07:36:24 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4321B2A31; Wed, 23 Jul 2014 07:36:23 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn0SRVH49E5N; Wed, 23 Jul 2014 07:36:22 -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 1968D1B2A2F; Wed, 23 Jul 2014 07:36:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN32216; Wed, 23 Jul 2014 14:36:20 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 15:36:20 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 22:36:14 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: Flexibility of SCH or NSH Thread-Index: Ac+mgVZ7EsuA1zKRSKKbmaoKloaCAA== Date: Wed, 23 Jul 2014 14:36:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08296CF0@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.156.221] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fy05QB17AXh41AlbF7ly64e7y10 Cc: "spring@ietf.org" Subject: [spring] Flexibility of SCH or NSH X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:36:24 -0000 Hi all, I have said the following word at this thread (http://www.ietf.org/mail-arc= hive/web/sfc/current/msg02172.html): ************************ I'm glad to see that the Service Path Header is decoupled from the Base Hea= der of the NSH while the MD Type field is introduced. With such MD Type fie= ld, it becomes possible that the Base Header could be followed by 1) a Serv= ice Path Header, 2) a context header or 3) both. Option 1 would be used bet= ween SFFs in the case where metadata is not required to be shared. Option 2= would be used between SFFs and SFs in the case where SFs don't care about = the service path information at all. Option 3 would be used between SFFs in= the case where metadata is required to be shared. If you agree with the ab= ove possible usages, it may be helpful to allocate two additional MT Type c= odes besides 0x1 so as to indicate the above three options. ************************ Now I see the following text from (http://www.ietf.org/proceedings/90/slide= s/slides-90-sfc-1.pdf): Applicability: SCH text describes usage to optionally carry only chain forw= arding information; only metadata; or both. I believe the above flexibility is much worthwhile. In addition, opiton 2 (= i.e., only carry metadata or metadata correlation id) is also be meanful in= the case where the service path or chain informaiton has been carried some= where else rahter than in the SCH or NSH (http://www.ietf.org/proceedings/9= 0/slides/slides-90-spring-5.pptx). Best regards, Xiaohu= From nobody Wed Jul 23 08:26:07 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D38B1B28D4; Wed, 23 Jul 2014 08:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciusBknw1omn; Wed, 23 Jul 2014 08:26:04 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739531A031D; Wed, 23 Jul 2014 08:26:01 -0700 (PDT) Received: from [31.133.166.167] (helo=dhcp-a6a7.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9yQY-0004oe-Pl; Wed, 23 Jul 2014 16:25:58 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Wed, 23 Jul 2014 11:25:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> To: Sri X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ysXay2pBqJ18xBSIHi-E-b6xMsw Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:26:06 -0000 Hi Sri! Thanks for the feedback. On 23 Jul 2014, at 02:40, Sri wrote: > Sri> You are correct. If a SID identifies multiple physical paths as = in the case of Adj-SID identifying a bundle, then load balancing on that = segment would be useful. When there is no information that every SID of = a LSP maps to a single physical path, a load-balancing mechanism should = be used for that LSP. I agree that today there is no mechanism to give = such information about the mapping, so load balancing on every segment = is useful. Whether that is achieved by using an EL per segment as = described in sec 3.2 thereby resulting in a label stack of 3*#SIDs is = something to be discussed. The draft lists the downsides of choosing = that option.=20 > =20 >=20 > I think that the above means that the current draft under-estimates = the depth > of the stack when considering an EL per tunnel (=A73.2), which might = amplify > some of the concerns raised for this option. >=20 >=20 > Sri> The draft does not estimate stack depth (without EL) since the = depth is dependent on the degree of strict-hop traffic-engineering = desired by the application. If you meant to say that the label stack is = deep due to the application trying to make it as close to the desired = physical path but you end up using the EL per segment anyways since = there isn't information to determine for sure whether the mapping is to = a single physical path, then yes the label stack will be very deep.=20 rjs> Absolutely. The point that I think is important here is that in the = case that we have: src->[ A ] -- [ B ] -- [ C ] -- [ D ] -- [ E ]->sink \ | / --------------[ F ] ----- And we have a strict requirement for A-B-C-D-E, then whilst it might = immediately look like we could specify: [5 labels] then actually, the requirement for EL per tunnel is now: = [15 labels] The example that you have in the document makes the case look somewhat = better than this. As you say, this is because the application that is = chosen in the example is somewhat less strict with its path placement = requirements, and a number of the labels in the stack are associated = with services. A reader could easily conclude that since the strict = src->A->B->C->D->E->sink path that is chosen has affinity to individual = adjacencies, this concern does not apply, but to deal with the fact that = things are bundles/LAGs, then I think it does.=20 It=92d be great if we could patch the wording (happy to help contribute) = to provide some wording that says that applications that already produce = deep label stacks would produce even deeper label stacks with this = option AND we know that there are limitations with the number of labels = that can be pushed by real h/w today. > Sri> This is correct. In case of re-routing from ingress, the = algorithm to compute EL depths have to be re-computed. If the re-route = is like FRR via a bypass LSP, the PLR may want to insert ELs if = load-balancing is desired along the bypass.=20 >=20 >=20 > In terms of discovery of the capabilities of a mid-point -- do we = need to > consider how, in a multi-area network, we discover the capabilities = of a > mid-point which might not have information about it leaked between = areas? >=20 > Sri> Option in 3.4 runs into such complications in case of multi-area. = All such cases have not been addressed yet for the option in 3.4 rjs> Sure =97 it would potentially be good to note this as a downside. = Especially if there=92s no clear solution other than leaking information = between areas, since this has impact on operator=92s network designs = today. > - Finally, it'd be good to determine what the intention of the = authors for this > document is. Do we expect that we make a recommendation as to what = equipment > vendors who are going to support SR-MPLS should optimise for? At the = moment, > the document is good at classifying the different approaches that = _could_ be > taken, but potentially requires an operator/vendor to consider = optimisation > for both a) reading very deep into the stack when acting as an LSR, = b) pushing > very deep stacks when acting as iLER, c) potentially implementing = more complex > swap() operations, whereby some reshuffling of the EL is required. >=20 > My feeling is that it would be very useful for this document to be = able to > make a clear recommendation as to which of these approaches should = be > optimised for, and hence we should debate their technical efficacy. = It'd be > good to understand whether the authors are intending to do this, or = rather > classify the approaches. >=20 > Sri> The first goal of the draft was to list the various approaches. = But the final goal is to come up with recommendations through the = discussions on the various approaches. rjs> Great =97 aligned with this, I think there would be some utility to = adding another option, which is that where there are ECMPs that can be = differentiated in terms of use of different SIDs (e.g., load-balancing = across two core planes), then a head-end based option (as per the = approach that we would take today with RSVP-TE LSPs) is possible. rjs> Addressing the final goal - as per Stephane=92s comments - I would = like to recommend that we specify =A73.1 as the target option (such that = we have a single ELI/EL deeper in the stack) as the =93ideal=94 option. = It then seems to me that a debate as to whether the forwarding behaviour = in =A73.3 is possible with most h/w today (both mean that either we = change the number of operations that are required on a forwarding device = when popping/swapping labels as far as I can see), or whether the = approach in =A73.4 (with the caveats noted above) is the best way = forward. Thanks for your consideration. r. From nobody Wed Jul 23 14:38:46 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC011A0B00; Wed, 23 Jul 2014 14:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdTzbgNW9hbG; Wed, 23 Jul 2014 14:38:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323631A03E3; Wed, 23 Jul 2014 14:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=414; q=dns/txt; s=iport; t=1406151520; x=1407361120; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cIDt53yTCxAPRkvZDpXQEuiWMhG55wbVYTg28H63uko=; b=VTvIGU9kHZdqvoGOg7ML/x/Wo2WJH3rtS1MPdJ6ZBF6kKWfwV1zoIvuj PBYyqeCXXTnwCRmWOieph+OnW8gXnWc8Hgg4O815Kzr+YCdd4puFGUazH Op2S0YqKrHCgxPveE6Yx1BbkbCgjC5WY/cURiJtnTlxwFBV9iwFw9UDDh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAM8q0FOtJA2I/2dsb2JhbABZgw6BLdF8FnaECjpRAT5CJwQBiFTARReTAIEYBZstlECDSIIx X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="342369137" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jul 2014 21:38:39 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6NLcdsS007505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 21:38:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 16:38:39 -0500 From: "Stefano Previdi (sprevidi)" To: 6man , "spring@ietf.org" Thread-Topic: SR-IPv6 in Toronto - IETF90 - Bits-n-Bites Thread-Index: AQHPpr53UCNBwrpo+kyVg/ncn/sMDw== Date: Wed, 23 Jul 2014 21:38:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.167.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E5DEA671F43D04AA84AD0A7AE0C4726@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/4M1sdmvzqEiMROphWMKR9JDTpRw Subject: [spring] SR-IPv6 in Toronto - IETF90 - Bits-n-Bites X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:38:43 -0000 Anyone in Toronto and interested into segment routing for ipv6, feel=20 free to come in the Concert Hall on thursday 1845-2100 EDT and attend=20 the interoperability demo between multiple SR-IPv6 implementations:=20 Cisco, Comcast, Ecole Polytechnique (Paris), Universite Catholique de=20 Louvain (LLN, Belgium).=20 Implementations are based on draft-previdi-6man-segment-routing-header-01. Thanks. s. From nobody Wed Jul 23 14:56:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752A81B298A; Wed, 23 Jul 2014 14:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ-jbZg0Dmx4; Wed, 23 Jul 2014 14:56:18 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252551B296A; Wed, 23 Jul 2014 14:56:16 -0700 (PDT) Received: from [2001:67c:370:160:4829:75c5:89d3:ef33] (helo=wireless-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XA4WE-0005fA-3K; Wed, 23 Jul 2014 22:56:14 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: <31D9512C-04FF-4BE3-866F-F7522BA78EC0@juniper.net> Date: Wed, 23 Jul 2014 17:56:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <31D9512C-04FF-4BE3-866F-F7522BA78EC0@juniper.net> To: Kireeti Kompella X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/8MJezOc_XzhxtbajERrztj5_bzs Cc: mpls@ietf.org, "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:56:22 -0000 Hi Kireeti, (Responding on-list for completeness - and a reminder to myself.) On 23 Jul 2014, at 12:54, Kireeti Kompella wrote: >> - I feel that it would be useful to provide some clarification as to = where we >> expect entropy to be required for load-sharing in the draft. >=20 > There are three questions hiding here: > 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)? > Valid question, as ECMP wasn't seen at first as necessary with = RSVP-TE, which shares intent with Adj-SID. I'd say the answer is Yes. = You give an example of why; analogies from the multi path RSVP draft can = also be used.=20 >=20 > 2) is EL the way to achieve ECMP with MPLS SPRING? > I sincerely hope so; having two mechanisms in MPLS to enable ECMP = wouldn't be ideal. But I won't rule out other ways.=20 >=20 > [Your point is taken: laying out (1) and (2) more clearly would help = the draft.] rjs> I agree with both points. Let me work to contribute some material = to expand on the couple of points I raised following the meeting this = week. >=20 > 3) Given Yeses to (1) and (2), how? > That's the current focus of the draft. This part is for now an = exploration. I agree that at some point, we have to narrow the options = down to a few (ideally one). This would be an action for vendors, = knowing their chips, and providers, knowing their requirements to sit = together and work it out.=20 >=20 > There is an aspect of the draft that hasn't come out, which is along = the lines of the MPLS forwarding draft, soon to be an RFC: what is the = best way in the future, given the requirements of SPRING and EL? I.e., = if you built new chips today, knowing what we know, which option would = you choose? Getting a sense of that would help the community to come to = a common choice for the future -- as someone mentioned, today's = choices/compromises may end up varying widely vendor-to-vendor.=20 rjs> Agreed =97 if we can determine whether we think that the list of = options is complete following the exercise of solving (1) and (2), then = perhaps we can start to address these questions and try to conclude the = discussions at the next meeting. Cheers, r. From nobody Wed Jul 23 23:32:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556651A006C; Wed, 23 Jul 2014 23:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqNnyRgAboq2; Wed, 23 Jul 2014 23:32:26 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16CC1A0010; Wed, 23 Jul 2014 23:32:24 -0700 (PDT) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail21.telekom.de with ESMTP; 24 Jul 2014 08:31:50 +0200 X-IronPort-AV: E=Sophos;i="5.01,722,1400018400"; d="scan'208";a="627917005" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jul 2014 08:31:50 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 24 Jul 2014 08:31:49 +0200 From: To: Date: Thu, 24 Jul 2014 08:31:49 +0200 Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: Ac+mitx3LxoxUqMwQrSWLKkO83LzrwAfaSVw Message-ID: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> In-Reply-To: <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7MrlVsXnkNUtXuhhuu6lEBudONE Cc: mpls@ietf.org, spring@ietf.org, draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 06:32:28 -0000 Hi Rob, I agree, a single ELI/EL deeper in the stack as proposed by =A73.1 is the m= ost useful target solution also from my point of view. Regards, Ruediger -----Message----- From: spring [mailto:spring-bounces@ietf.org] Rob Shakir Hi Sri! [snip] rjs> Addressing the final goal - as per Stephane's comments - I would like = to recommend that we specify =A73.1 as the target option (such that we have= a single ELI/EL deeper in the stack) as the "ideal" option. It then seems = to me that a debate as to whether the forwarding behaviour in =A73.3 is pos= sible with most h/w today (both mean that either we change the number of op= erations that are required on a forwarding device when popping/swapping lab= els as far as I can see), or whether the approach in =A73.4 (with the cavea= ts noted above) is the best way forward. Thanks for your consideration. r. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Jul 24 00:21:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E591A00AA; Thu, 24 Jul 2014 00:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z6oQNZlDj9F; Thu, 24 Jul 2014 00:21:35 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA90E1A0059; Thu, 24 Jul 2014 00:21:34 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id h18so2362371igc.0 for ; Thu, 24 Jul 2014 00:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Cn2fio7tZZgluc7xDITZv/JKWnsQ4zTW/AcHCxlwJD4=; b=CrcOUN1o3XMGt54gDQde2HLk+sLq5lItmajuwT6s8TwMsP763Hhi1I8jo7HeuqCehc U3PD8khkHUZQ6oPjLjNp05oaPwoUNc7OcH0k0pD++ZuL3A9+g0R8PjYroke30i55Rl6c 5JWF4A/LWjGrHD+KFVdcFC4+7NQvuY9Ihs3QAKjRf2WBELwkUJCm/Wxf1WIVG0+ryR57 s2nEYxi/ngHKC5ySfKWXxkwkNb6la86efsnYYbsjl/eDxyxb8UY2A2gXq3n2cuI6yz3d oqOKK/WSsxWPM/Nvv7dOG0Ro7dQyZm8x37I/sjDx8jLqdFwzfIJ8VVVPHo7clULqHGvl MJsg== MIME-Version: 1.0 X-Received: by 10.42.64.77 with SMTP id f13mr1242459ici.72.1406186492914; Thu, 24 Jul 2014 00:21:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 00:21:32 -0700 (PDT) In-Reply-To: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> Date: Thu, 24 Jul 2014 09:21:32 +0200 X-Google-Sender-Auth: OxzK0mCgixd5SlXHVwqUdzzNeY0 Message-ID: From: Robert Raszuk To: "Ruediger.Geib@telekom.de Geib" Content-Type: multipart/alternative; boundary=90e6ba614c6465f3fa04feeb4ee3 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/eTSJx7jKLbmKk0aqlnmk8QTrhgA Cc: "mpls@ietf.org" , "spring@ietf.org" , Rob Shakir , draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 07:21:36 -0000 --90e6ba614c6465f3fa04feeb4ee3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, Observing this discussion I have a question why the draft as well as this discussion is only limited to one solution for efficient load balancing across parallel links in the network - namely entropy labels ? Let's observe that unlike in general MPLS label allocation per FEC in SPRING labels are allocated per much more contained number of segment node properties. Therefor an alternative of using any form of entropy labels in data plane all together would be to allocate a SID blocks (say 64 or 128 wide) and allow SPRING header imposition to use such pools of SIDs per group of flows to effectively allow for efficient load balancing in the network. Moreover this solution does not put any additional requirements on MPLS hardware and can be easily supported today by most of shipping routers. Best, r. On Thu, Jul 24, 2014 at 8:31 AM, wrote: > Hi Rob, > > I agree, a single ELI/EL deeper in the stack as proposed by =C2=A73.1 is = the > most useful target solution also from my point of view. > > Regards, > > Ruediger > > -----Message----- > From: spring [mailto:spring-bounces@ietf.org] Rob Shakir > > Hi Sri! > > [snip] > > rjs> Addressing the final goal - as per Stephane's comments - I would lik= e > to recommend that we specify =C2=A73.1 as the target option (such that we= have a > single ELI/EL deeper in the stack) as the "ideal" option. It then seems t= o > me that a debate as to whether the forwarding behaviour in =C2=A73.3 is p= ossible > with most h/w today (both mean that either we change the number of > operations that are required on a forwarding device when popping/swapping > labels as far as I can see), or whether the approach in =C2=A73.4 (with t= he > caveats noted above) is the best way forward. > > Thanks for your consideration. > r. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --90e6ba614c6465f3fa04feeb4ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Observing this discussion I have a question why the draft as well as this d= iscussion is only limited to one solution for efficient load balancing acro= ss parallel links in the network - namely entropy labels ?=C2=A0

Let's observe that unlike in general MPLS label= allocation per FEC in SPRING labels are allocated per much more contained = number of segment node properties.=C2=A0

Therefor an alternative of using any = form of entropy labels in data plane all together would be to allocate a SI= D blocks (say 64 or 128 wide) and allow SPRING header imposition to use suc= h pools of SIDs per group of flows to effectively allow for efficient load = balancing in the network.

Moreover this solution does not put a= ny additional requirements on MPLS hardware and can be easily supported tod= ay by most of shipping routers.=C2=A0

Best,
r.



On Thu, Jul 24, 2014 at 8:31 AM, <Ruedige= r.Geib@telekom.de> wrote:
Hi Rob,

I agree, a single ELI/EL deeper in the stack as proposed by =C2=A73.1 is th= e most useful target solution also from my point of view.

Regards,

Ruediger

-----Message-----
From: spring [mailto:spring-boun= ces@ietf.org] Rob Shakir

Hi Sri!

[snip]

rjs> Addressing the final goal - as per Stephane's comments - I woul= d like to recommend that we specify =C2=A73.1 as the target option (such th= at we have a single ELI/EL deeper in the stack) as the "ideal" op= tion. It then seems to me that a debate as to whether the forwarding behavi= our in =C2=A73.3 is possible with most h/w today (both mean that either we = change the number of operations that are required on a forwarding device wh= en popping/swapping labels as far as I can see), or whether the approach in= =C2=A73.4 (with the caveats noted above) is the best way forward.

Thanks for your consideration.
r.


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

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

--90e6ba614c6465f3fa04feeb4ee3-- From nobody Thu Jul 24 04:48:28 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649CD1A01DC; Thu, 24 Jul 2014 04:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvBUJvIKxVkS; Thu, 24 Jul 2014 04:48:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FF21A017E; Thu, 24 Jul 2014 04:48:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id A9D172DCEEF; Thu, 24 Jul 2014 13:48:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 80914238055; Thu, 24 Jul 2014 13:48:13 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 13:48:13 +0200 From: To: Rob Shakir , Kireeti Kompella Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGzFOMOyOFpYEWM2i7SQsHvQpuuOA3bgADm4LA= Date: Thu, 24 Jul 2014 11:48:12 +0000 Message-ID: <18048_1406202493_53D0F27D_18048_5436_1_9E32478DFA9976438E7A22F69B08FF9205C356@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <31D9512C-04FF-4BE3-866F-F7522BA78EC0@juniper.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.40923 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/TnNCPrbXWSlqRn_Ods6DKbhhWa8 Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 11:48:23 -0000 IMHO, > 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)? Yes it is ... SPRING brings more flexibility in ECMP for TE tunnels than RS= VP-TE does. And ECMP with Bundle-Adj-SID is something really useful when a = Service Provider is using parallel ECMP links rather than LAGs. >2) is EL the way to achieve ECMP with MPLS SPRING? I would also agree that having two mechanism would be bad from an operation= al point of view. Entropy label is not new at IETF, but new in deployment (feature availabili= ty is something really recent). If SP that have deployed Entropy for loadba= lancing flows needs to move to something else for their SR-TE tunnels, well= ... sounds a bad thing ... Moreover entropy label has the magic of keeping loadbalancing stateless whi= ch is a pretty good advantage compared to adding more states at Ingress jus= t for loadbalancing. Stephane -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Rob Shakir Sent: Wednesday, July 23, 2014 17:56 To: Kireeti Kompella Cc: mpls@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-label@to= ols.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label Hi Kireeti, (Responding on-list for completeness - and a reminder to myself.) On 23 Jul 2014, at 12:54, Kireeti Kompella wrote: >> - I feel that it would be useful to provide some clarification as to=20 >> where we expect entropy to be required for load-sharing in the draft. >=20 > There are three questions hiding here: > 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)? > Valid question, as ECMP wasn't seen at first as necessary with RSVP-TE, w= hich shares intent with Adj-SID. I'd say the answer is Yes. You give an ex= ample of why; analogies from the multi path RSVP draft can also be used.=20 >=20 > 2) is EL the way to achieve ECMP with MPLS SPRING? > I sincerely hope so; having two mechanisms in MPLS to enable ECMP wouldn'= t be ideal. But I won't rule out other ways.=20 >=20 > [Your point is taken: laying out (1) and (2) more clearly would help=20 > the draft.] rjs> I agree with both points. Let me work to contribute some material to e= xpand on the couple of points I raised following the meeting this week. >=20 > 3) Given Yeses to (1) and (2), how? > That's the current focus of the draft. This part is for now an exploratio= n. I agree that at some point, we have to narrow the options down to a few = (ideally one). This would be an action for vendors, knowing their chips, an= d providers, knowing their requirements to sit together and work it out.=20 >=20 > There is an aspect of the draft that hasn't come out, which is along the = lines of the MPLS forwarding draft, soon to be an RFC: what is the best way= in the future, given the requirements of SPRING and EL? I.e., if you built= new chips today, knowing what we know, which option would you choose? Get= ting a sense of that would help the community to come to a common choice fo= r the future -- as someone mentioned, today's choices/compromises may end u= p varying widely vendor-to-vendor.=20 rjs> Agreed - if we can determine whether we think that the list of options= is complete following the exercise of solving (1) and (2), then perhaps we= can start to address these questions and try to conclude the discussions a= t the next meeting. Cheers, r. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 24 05:16:30 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504C1A0250; Thu, 24 Jul 2014 05:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYiF181UHj4E; Thu, 24 Jul 2014 05:16:22 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA121A0202; Thu, 24 Jul 2014 05:16:22 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so2797783qap.23 for ; Thu, 24 Jul 2014 05:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kXYpzMZOIM/0al/yfKnFAqo1ANGAG/rXdaE3S8nSSt4=; b=HKpQkKCr8ml99gsdTlkJ/gtVJg++7ZMCaFC+Kd0Dt2zx3IFQ0j2Cl/0L6i4S/fR4Th tXVwNHQKifKwGkXUnxsbTYp2aWP8Fr7yjUspoHDg7Zd8ie2yQbamwfYbhkgRagnu+7dD dzD+OsR6RCUceVQV6+b/kxeOIriLKjhWff0/WaWjiw2uxXRAiX6vm0+zLHWf/sVGYNFl A+p8RDW/LPCBUJqp4CRhWTNJJoM1C5tGMfFjyWVScLpYRU49t/hewprxP9au0XA/CtUh v7FIhyp9aiHWuh8GyJ1fOiOlWHq3WS2+fHSvuOHzAjqprDf23CA90lug3J9MSvGiO39Q O2Nw== X-Received: by 10.224.30.139 with SMTP id u11mr13180337qac.77.1406204181557; Thu, 24 Jul 2014 05:16:21 -0700 (PDT) Received: from ohassanali-sslvpn-nc.jnpr.net ([66.129.241.10]) by mx.google.com with ESMTPSA id k6sm6928416qge.2.2014.07.24.05.16.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 05:16:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_70F00B94-15AA-4927-91A4-20CFA7316629" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Kireeti Kompella In-Reply-To: Date: Thu, 24 Jul 2014 08:16:18 -0400 Message-Id: <333AAED1-2F62-454F-A876-963B11206F9E@gmail.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/uUVgwU1ISa55mirKPBuAKntNPkQ Cc: "mpls@ietf.org" , "Ruediger.Geib@telekom.de Geib" , Kireeti Kompella , "spring@ietf.org" , draft-kini-mpls-spring-entropy-label@tools.ietf.org, Rob Shakir Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:16:27 -0000 --Apple-Mail=_70F00B94-15AA-4927-91A4-20CFA7316629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (resending; sorry for the spam) Hi Robert, On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > Therefor an alternative of using any form of entropy labels in data = plane all together would be to allocate a SID blocks (say 64 or 128 = wide) and allow SPRING header imposition to use such pools of SIDs per = group of flows to effectively allow for efficient load balancing in the = network. We=92re rehashing (pun unintended) the entropy label discussion. Before we settled on entropy labels the way we did, we discussed = advertising label blocks in LDP. There are two problems: a) as Stephane mentions, ELs are stateless, but pools of SIDs impose = more state in the forwarding plane (and to some extent, in the control = plane). b) if you use small blocks, you get uneven load balancing; if you use = large blocks, you blow up the state more. Kireeti= --Apple-Mail=_70F00B94-15AA-4927-91A4-20CFA7316629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(resending; sorry for the = spam)

Hi Robert,

On Jul 24, 2014, = at 03:21 , Robert Raszuk <robert@raszuk.net> = wrote:

Therefor an alternative of = using any form of entropy labels in data plane all together would be to = allocate a SID blocks (say 64 or 128 wide) and allow SPRING header = imposition to use such pools of SIDs per group of flows to effectively = allow for efficient load balancing in the = network.

We=92re rehashing (pun = unintended) the entropy label = discussion.

Before we settled on entropy = labels the way we did, we discussed advertising label blocks in LDP. =  There are two problems:
a) as Stephane mentions, ELs are = stateless, but pools of SIDs impose more state in the forwarding plane = (and to some extent, in the control plane).
b) if you use = small blocks, you get uneven load balancing; if you use large blocks, = you blow up the state = more.

Kireeti
= --Apple-Mail=_70F00B94-15AA-4927-91A4-20CFA7316629-- From nobody Thu Jul 24 05:48:27 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF561A02D8; Thu, 24 Jul 2014 05:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRm5qRElSXL2; Thu, 24 Jul 2014 05:48:22 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439901A02DB; Thu, 24 Jul 2014 05:48:21 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id tr6so2139506ieb.7 for ; Thu, 24 Jul 2014 05:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y9rsdX1CFsWfKinq/AuiVlIOSfCbV+ErF8/hUHpvHMk=; b=FLqWc7mRqV4uchJ+SZQIt4qZN99PjNhG2GdQsgG6zY7e0mbird3CZwOSbQ1ry09SCA EVHmeHNmO/AvPSRA+4SSKyWcFaQWuKytKe2nTR7/DQH51wb98Nt603XUqMwvA/jf4uJs QgpEzhWcQKkdK59kYN/Tv8+UWp8lUlmkYIPk+xIuWj9Iq5V9MzQj44u+PY7c9koN8oVt ZbZZ/UFWQcBiX+38QwfRZX1+BcwNHb5pin/xMLzatIo05oeyWjArmZTMYYQirJgLcsZl 6HI4RClK7QUfcWYqCJo5Fc0bQlbqiZwNrrKTUkjzlKUkT6Hn0Ihm+uPsm25TM/0lW/9u C3TA== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr14691002igx.9.1406206100499; Thu, 24 Jul 2014 05:48:20 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 05:48:20 -0700 (PDT) Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 05:48:20 -0700 (PDT) In-Reply-To: <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> Date: Thu, 24 Jul 2014 14:48:20 +0200 X-Google-Sender-Auth: 8Z-RBohYggec1741j3VHbahzyfo Message-ID: From: Robert Raszuk To: Kireeti Kompella Content-Type: multipart/alternative; boundary=089e0122a75419f2fd04feefdffe Archived-At: http://mailarchive.ietf.org/arch/msg/spring/BfRVdI3mThRtFjJ4sScv_eI_k8Q Cc: "mpls@ietf.org" , spring@ietf.org, draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:48:24 -0000 --089e0122a75419f2fd04feefdffe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kireeti, I quite disagree about the more state argument. If you treat mpls label as prefix with mask which is all this boils down to there is no more state either in data or control plane. As to the point of not perfect load balancing it all depends on your hash function. If you always advertise at least as big block as you have max parallel links on any interface you should be fine. Best , R. On Jul 24, 2014 2:12 PM, "Kireeti Kompella" wrote: > Hi Robert, > > On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > > Therefor an alternative of using any form of entropy labels in data > plane all together would be to allocate a SID blocks (say 64 or 128 wide) > and allow SPRING header imposition to use such pools of SIDs per group of > flows to effectively allow for efficient load balancing in the network. > > > We=E2=80=99re rehashing (pun unintended) the entropy label discussion. > > Before we settled on entropy labels the way we did, we discussed > advertising label blocks in LDP. There are two problems: > a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more > state in the forwarding plane (and to some extent, in the control plane). > b) if you use small blocks, you get uneven load balancing; if you use > large blocks, you blow up the state more. > > Kireeti > > --089e0122a75419f2fd04feefdffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Kireeti,

I quite disagree about the more state argument.

If you treat mpls label as prefix with mask which is all thi= s boils down to there is no more state either in data or control plane.

As to the point of not perfect load balancing it all depends= on your hash function. If you always advertise at least as big block as yo= u have max parallel links on any interface you should be fine.

Best ,
R.

On Jul 24, 2014 2:12 PM, "Kireeti Kompella&= quot; <kireeti@juniper.net>= ; wrote:
Hi Robert,

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> wrote:

Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allo= w SPRING header imposition to use such pools of SIDs per group of flows to = effectively allow for efficient load balancing in the network.

We=E2=80=99re rehashing (pun unintended) the entropy label discussion.=

Before we settled on entropy labels the way we did, we discussed adver= tising label blocks in LDP. =C2=A0There are two problems:
a) as Stephane mentions, ELs are stateless, but pools of SIDs impose m= ore state in the forwarding plane (and to some extent, in the control plane= ).
b) if you use small blocks, you get uneven load balancing; if you use = large blocks, you blow up the state more.

Kireeti

--089e0122a75419f2fd04feefdffe-- From nobody Thu Jul 24 06:27:16 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834F71A0320; Thu, 24 Jul 2014 06:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZisE_lberoCi; Thu, 24 Jul 2014 06:27:12 -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 5574E1A02CF; Thu, 24 Jul 2014 06:27:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHO22473; Thu, 24 Jul 2014 13:27:09 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 14:27:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 21:27:04 +0800 From: Xuxiaohu To: Kireeti Kompella , Robert Raszuk Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPG60J2/V/fu6kuL32lhjiOWm5usseMAgACS5gCAAP0cgIAADeQAgABRZgCAAJqYUg== Date: Thu, 24 Jul 2014 13:27:04 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08297278@NKGEML512-MBS.china.huawei.com> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> , <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> In-Reply-To: <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.24] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08297278NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/-OtGumsjWeiAoepRmKBaVR_VD_A Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 13:27:13 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08297278NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q29uY3VyLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMgW21wbHMtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBLaXJlZXRpIEtvbXBlbGxhIFtraXJlZXRpQGp1bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6 IDIwMTTE6jfUwjI0yNUgMjA6MTINCsrVvP7IyzogUm9iZXJ0IFJhc3p1aw0Ks63LzTogS2lyZWV0 aSBLb21wZWxsYTsgbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBkcmFmdC1raW5pLW1w bHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbXBsc10g W3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0KSGkgUm9iZXJ0LA0KDQpP biBKdWwgMjQsIDIwMTQsIGF0IDAzOjIxICwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4gd3JvdGU6DQoNClRoZXJlZm9yIGFuIGFsdGVy bmF0aXZlIG9mIHVzaW5nIGFueSBmb3JtIG9mIGVudHJvcHkgbGFiZWxzIGluIGRhdGEgcGxhbmUg YWxsIHRvZ2V0aGVyIHdvdWxkIGJlIHRvIGFsbG9jYXRlIGEgU0lEIGJsb2NrcyAoc2F5IDY0IG9y IDEyOCB3aWRlKSBhbmQgYWxsb3cgU1BSSU5HIGhlYWRlciBpbXBvc2l0aW9uIHRvIHVzZSBzdWNo IHBvb2xzIG9mIFNJRHMgcGVyIGdyb3VwIG9mIGZsb3dzIHRvIGVmZmVjdGl2ZWx5IGFsbG93IGZv ciBlZmZpY2llbnQgbG9hZCBiYWxhbmNpbmcgaW4gdGhlIG5ldHdvcmsuDQoNCldloa9yZSByZWhh c2hpbmcgKHB1biB1bmludGVuZGVkKSB0aGUgZW50cm9weSBsYWJlbCBkaXNjdXNzaW9uLg0KDQpC ZWZvcmUgd2Ugc2V0dGxlZCBvbiBlbnRyb3B5IGxhYmVscyB0aGUgd2F5IHdlIGRpZCwgd2UgZGlz Y3Vzc2VkIGFkdmVydGlzaW5nIGxhYmVsIGJsb2NrcyBpbiBMRFAuICBUaGVyZSBhcmUgdHdvIHBy b2JsZW1zOg0KYSkgYXMgU3RlcGhhbmUgbWVudGlvbnMsIEVMcyBhcmUgc3RhdGVsZXNzLCBidXQg cG9vbHMgb2YgU0lEcyBpbXBvc2UgbW9yZSBzdGF0ZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSAo YW5kIHRvIHNvbWUgZXh0ZW50LCBpbiB0aGUgY29udHJvbCBwbGFuZSkuDQpiKSBpZiB5b3UgdXNl IHNtYWxsIGJsb2NrcywgeW91IGdldCB1bmV2ZW4gbG9hZCBiYWxhbmNpbmc7IGlmIHlvdSB1c2Ug bGFyZ2UgYmxvY2tzLCB5b3UgYmxvdyB1cCB0aGUgc3RhdGUgbW9yZS4NCg0KS2lyZWV0aQ0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08297278NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Concur.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@iet= f.org] =B4=FA=B1=ED Kireeti Kompella [kireeti@juniper.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C224=C8=D5 20:12
=CA=D5=BC=FE=C8=CB: Robert Raszuk
=B3=AD=CB=CD: Kireeti Kompella; mpls@ietf.org; spring@ietf.org; draf= t-kini-mpls-spring-entropy-label@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] [spring] SPRING MPLS and Entropy Label

Hi Robert,

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> wrote:

Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allo= w SPRING header imposition to use such pools of SIDs per group of flows to = effectively allow for efficient load balancing in the network.

We=A1=AFre rehashing (pun unintended) the entropy label discussion.

Before we settled on entropy labels the way we did, we discussed adver= tising label blocks in LDP.  There are two problems:
a) as Stephane mentions, ELs are stateless, but pools of SIDs impose m= ore state in the forwarding plane (and to some extent, in the control plane= ).
b) if you use small blocks, you get uneven load balancing; if you use = large blocks, you blow up the state more.

Kireeti

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08297278NKGEML512MBSchi_-- From nobody Thu Jul 24 09:46:25 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66031A045D; Thu, 24 Jul 2014 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0T_oNM1XAbO; Thu, 24 Jul 2014 09:46:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76671A0439; Thu, 24 Jul 2014 09:46:17 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id C990E3B5B5A; Thu, 24 Jul 2014 18:46:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 9EDD63840D0; Thu, 24 Jul 2014 18:46:15 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 18:46:15 +0200 From: To: Robert Raszuk , Kireeti Kompella Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpop+sk+mL1pXdkKUVhjrFSzu1puuo0mAgAAN5ACAAFFmAIAACegAgABjfaA= Date: Thu, 24 Jul 2014 16:46:14 +0000 Message-ID: <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9205D5B6OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.102419 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/29aCl3vsyTSczPReZ0TscMz1Bvc Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:46:21 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9205D5B6OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpUYWxraW5nIE1QTFMsIEkgZG9u4oCZdCBzZWUgYSB3YXkgdG8gdXNlIE1QTFMg bGFiZWwg4oCccHJlZml44oCdIOKApiB0aGlzIGlzIGEgZGlzY3Vzc2lvbiB3ZSBhbHJlYWR5IGhh ZCB0b2dldGhlci4gSSB0aGluayB5b3UgYXJlIHRyeWluZyB0byBzZWxsIElQdjYgU1IgdGhhdCBJ IHdpbGwgdW5mb3J0dW5hdGVseSBub3QgYnV5IGFnYWluIOKYug0KDQpGcm9tOiBzcHJpbmcgW21h aWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsN ClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDA4OjQ4DQpUbzogS2lyZWV0aSBLb21wZWxs YQ0KQ2M6IG1wbHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQta2luaS1tcGxzLXNw cmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NwcmluZ10g U1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0KDQpIaSBLaXJlZXRpLA0KDQpJIHF1aXRl IGRpc2FncmVlIGFib3V0IHRoZSBtb3JlIHN0YXRlIGFyZ3VtZW50Lg0KDQpJZiB5b3UgdHJlYXQg bXBscyBsYWJlbCBhcyBwcmVmaXggd2l0aCBtYXNrIHdoaWNoIGlzIGFsbCB0aGlzIGJvaWxzIGRv d24gdG8gdGhlcmUgaXMgbm8gbW9yZSBzdGF0ZSBlaXRoZXIgaW4gZGF0YSBvciBjb250cm9sIHBs YW5lLg0KDQpBcyB0byB0aGUgcG9pbnQgb2Ygbm90IHBlcmZlY3QgbG9hZCBiYWxhbmNpbmcgaXQg YWxsIGRlcGVuZHMgb24geW91ciBoYXNoIGZ1bmN0aW9uLiBJZiB5b3UgYWx3YXlzIGFkdmVydGlz ZSBhdCBsZWFzdCBhcyBiaWcgYmxvY2sgYXMgeW91IGhhdmUgbWF4IHBhcmFsbGVsIGxpbmtzIG9u IGFueSBpbnRlcmZhY2UgeW91IHNob3VsZCBiZSBmaW5lLg0KDQpCZXN0ICwNClIuDQpPbiBKdWwg MjQsIDIwMTQgMjoxMiBQTSwgIktpcmVldGkgS29tcGVsbGEiIDxraXJlZXRpQGp1bmlwZXIubmV0 PG1haWx0bzpraXJlZXRpQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQpIaSBSb2JlcnQsDQoNCk9uIEp1 bCAyNCwgMjAxNCwgYXQgMDM6MjEgLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCg0KDQpUaGVyZWZvciBhbiBhbHRlcm5h dGl2ZSBvZiB1c2luZyBhbnkgZm9ybSBvZiBlbnRyb3B5IGxhYmVscyBpbiBkYXRhIHBsYW5lIGFs bCB0b2dldGhlciB3b3VsZCBiZSB0byBhbGxvY2F0ZSBhIFNJRCBibG9ja3MgKHNheSA2NCBvciAx Mjggd2lkZSkgYW5kIGFsbG93IFNQUklORyBoZWFkZXIgaW1wb3NpdGlvbiB0byB1c2Ugc3VjaCBw b29scyBvZiBTSURzIHBlciBncm91cCBvZiBmbG93cyB0byBlZmZlY3RpdmVseSBhbGxvdyBmb3Ig ZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIGluIHRoZSBuZXR3b3JrLg0KDQpXZeKAmXJlIHJlaGFz aGluZyAocHVuIHVuaW50ZW5kZWQpIHRoZSBlbnRyb3B5IGxhYmVsIGRpc2N1c3Npb24uDQoNCkJl Zm9yZSB3ZSBzZXR0bGVkIG9uIGVudHJvcHkgbGFiZWxzIHRoZSB3YXkgd2UgZGlkLCB3ZSBkaXNj dXNzZWQgYWR2ZXJ0aXNpbmcgbGFiZWwgYmxvY2tzIGluIExEUC4gIFRoZXJlIGFyZSB0d28gcHJv YmxlbXM6DQphKSBhcyBTdGVwaGFuZSBtZW50aW9ucywgRUxzIGFyZSBzdGF0ZWxlc3MsIGJ1dCBw b29scyBvZiBTSURzIGltcG9zZSBtb3JlIHN0YXRlIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIChh bmQgdG8gc29tZSBleHRlbnQsIGluIHRoZSBjb250cm9sIHBsYW5lKS4NCmIpIGlmIHlvdSB1c2Ug c21hbGwgYmxvY2tzLCB5b3UgZ2V0IHVuZXZlbiBsb2FkIGJhbGFuY2luZzsgaWYgeW91IHVzZSBs YXJnZSBibG9ja3MsIHlvdSBibG93IHVwIHRoZSBzdGF0ZSBtb3JlLg0KDQpLaXJlZXRpDQoNCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF9205D5B6OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UYWxraW5nIE1Q TFMsIEkgZG9u4oCZdCBzZWUgYSB3YXkgdG8gdXNlIE1QTFMgbGFiZWwg4oCccHJlZml44oCdIOKA piB0aGlzIGlzIGEgZGlzY3Vzc2lvbiB3ZSBhbHJlYWR5IGhhZCB0b2dldGhlci4gSSB0aGluayB5 b3UgYXJlIHRyeWluZyB0byBzZWxsIElQdjYgU1IgdGhhdCBJIHdpbGwNCiB1bmZvcnR1bmF0ZWx5 IG5vdCBidXkgYWdhaW4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBKdWx5IDI0LCAyMDE0IDA4OjQ4PGJyPg0KPGI+VG86PC9iPiBLaXJlZXRpIEtvbXBlbGxhPGJy Pg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmkt bXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPkhpIEtpcmVldGksPG86cD48L286cD48L3A+DQo8cD5JIHF1aXRlIGRpc2FncmVlIGFib3V0 IHRoZSBtb3JlIHN0YXRlIGFyZ3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHA+SWYgeW91IHRyZWF0 IG1wbHMgbGFiZWwgYXMgcHJlZml4IHdpdGggbWFzayB3aGljaCBpcyBhbGwgdGhpcyBib2lscyBk b3duIHRvIHRoZXJlIGlzIG5vIG1vcmUgc3RhdGUgZWl0aGVyIGluIGRhdGEgb3IgY29udHJvbCBw bGFuZS48bzpwPjwvbzpwPjwvcD4NCjxwPkFzIHRvIHRoZSBwb2ludCBvZiBub3QgcGVyZmVjdCBs b2FkIGJhbGFuY2luZyBpdCBhbGwgZGVwZW5kcyBvbiB5b3VyIGhhc2ggZnVuY3Rpb24uIElmIHlv dSBhbHdheXMgYWR2ZXJ0aXNlIGF0IGxlYXN0IGFzIGJpZyBibG9jayBhcyB5b3UgaGF2ZSBtYXgg cGFyYWxsZWwgbGlua3Mgb24gYW55IGludGVyZmFjZSB5b3Ugc2hvdWxkIGJlIGZpbmUuDQo8bzpw PjwvbzpwPjwvcD4NCjxwPkJlc3QgLDxicj4NClIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDI0LCAyMDE0IDI6MTIgUE0sICZxdW90O0tpcmVldGkg S29tcGVsbGEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpraXJlZXRpQGp1bmlwZXIubmV0Ij5r aXJlZXRpQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9iZXJ0LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDI0LCAyMDE0LCBhdCAwMzoyMSAsIFJvYmVydCBS YXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxh bmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGhlcmVmb3IgYW4gYWx0ZXJuYXRpdmUgb2YgdXNpbmcgYW55IGZv cm0gb2YgZW50cm9weSBsYWJlbHMgaW4gZGF0YSBwbGFuZSBhbGwgdG9nZXRoZXIgd291bGQgYmUg dG8gYWxsb2NhdGUgYSBTSUQgYmxvY2tzIChzYXkgNjQgb3IgMTI4IHdpZGUpIGFuZCBhbGxvdyBT UFJJTkcgaGVhZGVyIGltcG9zaXRpb24gdG8gdXNlIHN1Y2ggcG9vbHMgb2YNCiBTSURzIHBlciBn cm91cCBvZiBmbG93cyB0byBlZmZlY3RpdmVseSBhbGxvdyBmb3IgZWZmaWNpZW50IGxvYWQgYmFs YW5jaW5nIGluIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZeKAmXJlIHJlaGFzaGluZyAocHVuIHVuaW50ZW5kZWQpIHRo ZSBlbnRyb3B5IGxhYmVsIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVmb3JlIHdlIHNldHRsZWQgb24gZW50 cm9weSBsYWJlbHMgdGhlIHdheSB3ZSBkaWQsIHdlIGRpc2N1c3NlZCBhZHZlcnRpc2luZyBsYWJl bCBibG9ja3MgaW4gTERQLiAmbmJzcDtUaGVyZSBhcmUgdHdvIHByb2JsZW1zOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YSkgYXMgU3RlcGhhbmUg bWVudGlvbnMsIEVMcyBhcmUgc3RhdGVsZXNzLCBidXQgcG9vbHMgb2YgU0lEcyBpbXBvc2UgbW9y ZSBzdGF0ZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSAoYW5kIHRvIHNvbWUgZXh0ZW50LCBpbiB0 aGUgY29udHJvbCBwbGFuZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5iKSBpZiB5b3UgdXNlIHNtYWxsIGJsb2NrcywgeW91IGdldCB1bmV2ZW4g bG9hZCBiYWxhbmNpbmc7IGlmIHlvdSB1c2UgbGFyZ2UgYmxvY2tzLCB5b3UgYmxvdyB1cCB0aGUg c3RhdGUgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+S2lyZWV0aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_9E32478DFA9976438E7A22F69B08FF9205D5B6OPEXCLILM34corpor_-- From nobody Thu Jul 24 09:48:28 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231F61A0AD9 for ; Wed, 23 Jul 2014 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI6Yukc8SynU for ; Wed, 23 Jul 2014 09:54:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7A51A0319 for ; Wed, 23 Jul 2014 09:54:47 -0700 (PDT) Received: from CO2PR05MB554.namprd05.prod.outlook.com (10.141.196.141) by CO2PR05MB555.namprd05.prod.outlook.com (10.141.196.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 16:54:45 +0000 Received: from CO2PR05MB554.namprd05.prod.outlook.com ([10.141.196.141]) by CO2PR05MB554.namprd05.prod.outlook.com ([10.141.196.141]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 16:54:44 +0000 From: Kireeti Kompella To: Rob Shakir Thread-Topic: SPRING MPLS and Entropy Label Thread-Index: AQHPpPGtdeX4OzxQjUOfPirMD2dZoZut47dP Date: Wed, 23 Jul 2014 16:54:44 +0000 Message-ID: <31D9512C-04FF-4BE3-866F-F7522BA78EC0@juniper.net> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> In-Reply-To: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.146.51] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(51704005)(37854004)(199002)(52604005)(24454002)(105586002)(106356001)(31966008)(107046002)(92566001)(76176999)(74662001)(33656002)(76482001)(99396002)(74502001)(54356999)(92726001)(46102001)(95666004)(83072002)(36756003)(106116001)(50986999)(99286002)(83716003)(81542001)(85306003)(81342001)(19580405001)(19580395003)(20776003)(87936001)(64706001)(80022001)(101416001)(77982001)(66066001)(21056001)(86362001)(85852003)(83322001)(2656002)(110136001)(4396001)(79102001)(82746002)(104396001)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB555; H:CO2PR05MB554.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Aw2rUmWiFnsFO2muIB6VRME0xtw X-Mailman-Approved-At: Thu, 24 Jul 2014 09:48:26 -0700 Cc: "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:54:50 -0000 Hi Rob, On Jul 21, 2014, at 10:40, "Rob Shakir" wrote: > Hi SPRING, draft-kini=85 authors, >=20 > I have a few comments on the discussion within this draft =97 and a quick= question > on the intention around the document. Thanks for bringing this up. Good questions; I'll answer them from my persp= ective.=20 > - I feel that it would be useful to provide some clarification as to wher= e we > expect entropy to be required for load-sharing in the draft. There are three questions hiding here: 1) is ECMP needed with MPLS SPRING (in particular, Adj-SID)? Valid question, as ECMP wasn't seen at first as necessary with RSVP-TE, whi= ch shares intent with Adj-SID. I'd say the answer is Yes. You give an exam= ple of why; analogies from the multi path RSVP draft can also be used.=20 2) is EL the way to achieve ECMP with MPLS SPRING? I sincerely hope so; having two mechanisms in MPLS to enable ECMP wouldn't = be ideal. But I won't rule out other ways.=20 [Your point is taken: laying out (1) and (2) more clearly would help the dr= aft.] 3) Given Yeses to (1) and (2), how? That's the current focus of the draft. This part is for now an exploration.= I agree that at some point, we have to narrow the options down to a few (i= deally one). This would be an action for vendors, knowing their chips, and = providers, knowing their requirements to sit together and work it out.=20 There is an aspect of the draft that hasn't come out, which is along the li= nes of the MPLS forwarding draft, soon to be an RFC: what is the best way i= n the future, given the requirements of SPRING and EL? I.e., if you built n= ew chips today, knowing what we know, which option would you choose? Getti= ng a sense of that would help the community to come to a common choice for = the future -- as someone mentioned, today's choices/compromises may end up = varying widely vendor-to-vendor.=20 HTH, Kireeti= From nobody Thu Jul 24 09:48:29 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6C51A024C; Thu, 24 Jul 2014 05:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o76-71zFTKk; Thu, 24 Jul 2014 05:12:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5901A023F; Thu, 24 Jul 2014 05:12:55 -0700 (PDT) Received: from CO2PR05MB554.namprd05.prod.outlook.com (10.141.196.141) by CO2PR05MB555.namprd05.prod.outlook.com (10.141.196.147) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 24 Jul 2014 12:12:53 +0000 Received: from CO2PR05MB554.namprd05.prod.outlook.com ([10.141.196.141]) by CO2PR05MB554.namprd05.prod.outlook.com ([10.141.196.141]) with mapi id 15.00.0990.007; Thu, 24 Jul 2014 12:12:53 +0000 From: Kireeti Kompella To: Robert Raszuk Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpPGtdeX4OzxQjUOfPirMD2dZoZutOAAAgACS5QCAAP0cgIAADeUAgABRYwA= Date: Thu, 24 Jul 2014 12:12:52 +0000 Message-ID: <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(16236675004)(105586002)(76176999)(83716003)(106356001)(107046002)(31966008)(83072002)(99286002)(33656002)(74502001)(99396002)(76482001)(74662001)(92566001)(93886003)(54356999)(92726001)(95666004)(46102001)(36756003)(50986999)(106116001)(81542001)(81342001)(19580405001)(19580395003)(20776003)(87936001)(64706001)(80022001)(101416001)(85852003)(21056001)(86362001)(66066001)(85306003)(77982001)(83322001)(82746002)(2656002)(110136001)(79102001)(4396001)(104396001)(217873001); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB555; H:CO2PR05MB554.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_083ECD6FD7B54AFC806619BD2B7E563Bjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/pH79mnpvWt4UNRNT0M8D7uKwdz4 X-Mailman-Approved-At: Thu, 24 Jul 2014 09:48:26 -0700 Cc: Kireeti Kompella , "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:13:02 -0000 --_000_083ECD6FD7B54AFC806619BD2B7E563Bjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Robert, On Jul 24, 2014, at 03:21 , Robert Raszuk > wrote: Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allo= w SPRING header imposition to use such pools of SIDs per group of flows to = effectively allow for efficient load balancing in the network. We=92re rehashing (pun unintended) the entropy label discussion. Before we settled on entropy labels the way we did, we discussed advertisin= g label blocks in LDP. There are two problems: a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more s= tate in the forwarding plane (and to some extent, in the control plane). b) if you use small blocks, you get uneven load balancing; if you use large= blocks, you blow up the state more. Kireeti --_000_083ECD6FD7B54AFC806619BD2B7E563Bjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94F8B6CA72843B4ABD649D698F80A3E1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Robert,

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> wrote:

Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allo= w SPRING header imposition to use such pools of SIDs per group of flows to = effectively allow for efficient load balancing in the network.

We=92re rehashing (pun unintended) the entropy label discussion.

Before we settled on entropy labels the way we did, we discussed adver= tising label blocks in LDP.  There are two problems:
a) as Stephane mentions, ELs are stateless, but pools of SIDs impose m= ore state in the forwarding plane (and to some extent, in the control plane= ).
b) if you use small blocks, you get uneven load balancing; if you use = large blocks, you blow up the state more.

Kireeti

--_000_083ECD6FD7B54AFC806619BD2B7E563Bjunipernet_-- From nobody Thu Jul 24 09:54:21 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CC81A066C; Thu, 24 Jul 2014 09:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTj_jyuaOy1K; Thu, 24 Jul 2014 09:54:16 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ABB1A05E5; Thu, 24 Jul 2014 09:54:15 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so6701852iga.4 for ; Thu, 24 Jul 2014 09:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SfTrnzbXHxRY7cwuGsbTKnD5OGd2QPi6PUpO4IZZzx0=; b=SYh8g4Dak5wRrg2DECTCre2McN4w9s0LnAicZVnd2zEyUMljMSAbNEbQghBYTvbqm8 uhDNbeipE2pIBcg7KOk+xy9AB9NpEABKw3IvkTB4WkoNJZO/GYljNJaydBmCuw35IUlI 1d8hvAZhl9u0NngAk/D5cxazBBx1ZxgY2XPkmW06JZ9w980o9Thqx7a7qz6xBUOKg3OQ JXIoYwYBZLGXUipsZtbfPEH3Hrz/D5toIpMk+7PBMKkuQNyHgEMfmSuI23ei+4NIk99k 7s2qsocNa7GKpOSH7Tmfm+HGts/OdSYm/QbiBkN5M0o5Yn5IaHqFsaHG9i4gt20yZjWU YaPA== MIME-Version: 1.0 X-Received: by 10.50.36.106 with SMTP id p10mr41496454igj.9.1406220854708; Thu, 24 Jul 2014 09:54:14 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 09:54:14 -0700 (PDT) In-Reply-To: <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 24 Jul 2014 18:54:14 +0200 X-Google-Sender-Auth: Xp9yCed01P40U-Y8rBozhjEPlpk Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=089e0115ebd0855d4304fef34e99 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/HpLp2BInmKYQnT1xqEbsWj94Evw Cc: Kireeti Kompella , "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:54:20 -0000 --089e0115ebd0855d4304fef34e99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephane, This has NOTHING TO DO with IPv6. I am not even sure based on what you draw such strange conclusion .... I am talking pure about MPLS data plane (even without any IP above) and how we can solve the load balancing problems. At min I expect for any discussion to be valid to discuss and compare all options. Note also that SPRING does not use LDP so I am much less interested in solving the LDP load balancing issues. Rgs, R. On Thu, Jul 24, 2014 at 6:46 PM, wrote: > Robert, > > > > Talking MPLS, I don=E2=80=99t see a way to use MPLS label =E2=80=9Cprefix= =E2=80=9D =E2=80=A6 this is a > discussion we already had together. I think you are trying to sell IPv6 S= R > that I will unfortunately not buy again J > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 08:48 > *To:* Kireeti Kompella > *Cc:* mpls@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > Hi Kireeti, > > I quite disagree about the more state argument. > > If you treat mpls label as prefix with mask which is all this boils down > to there is no more state either in data or control plane. > > As to the point of not perfect load balancing it all depends on your hash > function. If you always advertise at least as big block as you have max > parallel links on any interface you should be fine. > > Best , > R. > > On Jul 24, 2014 2:12 PM, "Kireeti Kompella" wrote: > > Hi Robert, > > > > On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > > > > Therefor an alternative of using any form of entropy labels in data > plane all together would be to allocate a SID blocks (say 64 or 128 wide) > and allow SPRING header imposition to use such pools of SIDs per group of > flows to effectively allow for efficient load balancing in the network. > > > > We=E2=80=99re rehashing (pun unintended) the entropy label discussion. > > > > Before we settled on entropy labels the way we did, we discussed > advertising label blocks in LDP. There are two problems: > > a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more > state in the forwarding plane (and to some extent, in the control plane). > > b) if you use small blocks, you get uneven load balancing; if you use > large blocks, you blow up the state more. > > > > Kireeti > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --089e0115ebd0855d4304fef34e99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane,

This has NOTHING TO DO with IPv6. I am not even sure based on what you draw= such strange conclusion ....=C2=A0

I am talking pure about MPLS data plane (even without any IP above) and how= we can solve the load balancing problems.=C2=A0

At min I expect for any discussion to be valid to discuss and compare all o= ptions.=C2=A0

Note also that SPRING does not use LDP so I am much less interested in solv= ing the LDP load balancing issues.=C2=A0

Rgs,
R.



On Thu, Jul 24, 2014 at 6:46 PM, <stephane.litkowski@orange.com> wrote:

Robert,

=C2=A0

Talking MPLS, I don=E2=80= =99t see a way to use MPLS label =E2=80=9Cprefix=E2=80=9D =E2=80=A6 this is= a discussion we already had together. I think you are trying to sell IPv6 = SR that I will unfortunately not buy again J=

=C2=A0

From: spring [= mailto:spring-= bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 08:48
To: Kireeti Kompella
Cc: mpls@ietf.org= ; spring@ietf.org<= /a>; draft-kini-mpls-spring-entropy-label@tools.ietf.org<= br> Subject: Re: [spring] SPRING MPLS and Entropy Label

=C2=A0

Hi Kireeti,

I quite disagree about the more state argument.

If you treat mpls label as prefix with mask which is all this boils down= to there is no more state either in data or control plane.

As to the point of not perfect load balancing it all depends on your has= h function. If you always advertise at least as big block as you have max p= arallel links on any interface you should be fine.

Best ,
R.

On Jul 24, 2014 2:12 PM, "Kireeti Kompella"= ; <kireeti@juni= per.net> wrote:

Hi Robert,

=C2=A0

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> = wrote:



= Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allo= w SPRING header imposition to use such pools of SIDs per group of flows to effectively allow for efficient load balancing = in the network.

=C2=A0

We=E2=80=99re rehashing (pun unintended) the entropy= label discussion.

=C2=A0

Before we settled on entropy labels the way we did, = we discussed advertising label blocks in LDP. =C2=A0There are two problems:=

a) as Stephane mentions, ELs are stateless, but pool= s of SIDs impose more state in the forwarding plane (and to some extent, in= the control plane).

b) if you use small blocks, you get uneven load bala= ncing; if you use large blocks, you blow up the state more.

=C2=A0

Kireeti

=C2=A0

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--089e0115ebd0855d4304fef34e99-- From nobody Thu Jul 24 10:06:07 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5F41A0A98; Thu, 24 Jul 2014 10:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWl80AKz3u24; Thu, 24 Jul 2014 10:05:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D3481A0A97; Thu, 24 Jul 2014 10:05:54 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2ACE7325FA0; Thu, 24 Jul 2014 19:05:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 02F45238134; Thu, 24 Jul 2014 19:05:53 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 19:05:52 +0200 From: To: Robert Raszuk Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpop+sk+mL1pXdkKUVhjrFSzu1puuo0mAgAAN5ACAAFFmAIAACegAgABjfaD//+E4AIAAI60A Date: Thu, 24 Jul 2014 17:05:51 +0000 Message-ID: <10232_1406221553_53D13CF1_10232_3488_1_9E32478DFA9976438E7A22F69B08FF9205D615@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9205D615OPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.121217 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Fu9VuJWm0ZBRrX0RQkmk3jz4hf8 Cc: Kireeti Kompella , "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:06:04 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9205D615OPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpGcm9tIGEgcHJhY3RpY2FsIHBvaW50IG9mIHZpZXcgLCBob3cgZG8gIHlvdSBy ZXByZXNlbnQgc3VjaCBNUExTIGxhYmVsIHJhbmdlIHdpdGggYSBwcmVmaXggPw0KWzcwLCAxNzBd DQpbMTcsIDY5XQ0KDQpNUExTIHdhcyBub3QgZGVzaWduZWQgZm9yIOKAnGxhYmVsIGFnZ3JlZ2F0 aW9u4oCdIHNjaGVtZSDigKYNCk9yIHdlIG5lZWQgdG8gY2hhbmdlIG9mIGxhYmVscyBhcmUgYWxs b2NhdGVkIGZyb20gdGhlIGxhYmVsIHNwYWNlIGZvciBhbGwgbGFiZWwgY29uc3VtZXJzIOKApiB0 byBwZXJtaXQgdGhpcyBhZ2dyZWdhdGlvbi4NCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBb bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2Vu dDogVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgMTI6NTQNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUg U0NFL0lCTkYNCkNjOiBLaXJlZXRpIEtvbXBlbGxhOyBtcGxzQGlldGYub3JnOyBzcHJpbmdAaWV0 Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoN ClN0ZXBoYW5lLA0KDQpUaGlzIGhhcyBOT1RISU5HIFRPIERPIHdpdGggSVB2Ni4gSSBhbSBub3Qg ZXZlbiBzdXJlIGJhc2VkIG9uIHdoYXQgeW91IGRyYXcgc3VjaCBzdHJhbmdlIGNvbmNsdXNpb24g Li4uLg0KDQpJIGFtIHRhbGtpbmcgcHVyZSBhYm91dCBNUExTIGRhdGEgcGxhbmUgKGV2ZW4gd2l0 aG91dCBhbnkgSVAgYWJvdmUpIGFuZCBob3cgd2UgY2FuIHNvbHZlIHRoZSBsb2FkIGJhbGFuY2lu ZyBwcm9ibGVtcy4NCg0KQXQgbWluIEkgZXhwZWN0IGZvciBhbnkgZGlzY3Vzc2lvbiB0byBiZSB2 YWxpZCB0byBkaXNjdXNzIGFuZCBjb21wYXJlIGFsbCBvcHRpb25zLg0KDQpOb3RlIGFsc28gdGhh dCBTUFJJTkcgZG9lcyBub3QgdXNlIExEUCBzbyBJIGFtIG11Y2ggbGVzcyBpbnRlcmVzdGVkIGlu IHNvbHZpbmcgdGhlIExEUCBsb2FkIGJhbGFuY2luZyBpc3N1ZXMuDQoNClJncywNClIuDQoNCg0K T24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNjo0NiBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KUm9i ZXJ0LA0KDQpUYWxraW5nIE1QTFMsIEkgZG9u4oCZdCBzZWUgYSB3YXkgdG8gdXNlIE1QTFMgbGFi ZWwg4oCccHJlZml44oCdIOKApiB0aGlzIGlzIGEgZGlzY3Vzc2lvbiB3ZSBhbHJlYWR5IGhhZCB0 b2dldGhlci4gSSB0aGluayB5b3UgYXJlIHRyeWluZyB0byBzZWxsIElQdjYgU1IgdGhhdCBJIHdp bGwgdW5mb3J0dW5hdGVseSBub3QgYnV5IGFnYWluIOKYug0KDQpGcm9tOiBzcHJpbmcgW21haWx0 bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVGh1cnNkYXksIEp1bHkgMjQsIDIw MTQgMDg6NDgNClRvOiBLaXJlZXRpIEtvbXBlbGxhDQpDYzogbXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz47IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPjsg ZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWwNCg0KDQpI aSBLaXJlZXRpLA0KDQpJIHF1aXRlIGRpc2FncmVlIGFib3V0IHRoZSBtb3JlIHN0YXRlIGFyZ3Vt ZW50Lg0KDQpJZiB5b3UgdHJlYXQgbXBscyBsYWJlbCBhcyBwcmVmaXggd2l0aCBtYXNrIHdoaWNo IGlzIGFsbCB0aGlzIGJvaWxzIGRvd24gdG8gdGhlcmUgaXMgbm8gbW9yZSBzdGF0ZSBlaXRoZXIg aW4gZGF0YSBvciBjb250cm9sIHBsYW5lLg0KDQpBcyB0byB0aGUgcG9pbnQgb2Ygbm90IHBlcmZl Y3QgbG9hZCBiYWxhbmNpbmcgaXQgYWxsIGRlcGVuZHMgb24geW91ciBoYXNoIGZ1bmN0aW9uLiBJ ZiB5b3UgYWx3YXlzIGFkdmVydGlzZSBhdCBsZWFzdCBhcyBiaWcgYmxvY2sgYXMgeW91IGhhdmUg bWF4IHBhcmFsbGVsIGxpbmtzIG9uIGFueSBpbnRlcmZhY2UgeW91IHNob3VsZCBiZSBmaW5lLg0K DQpCZXN0ICwNClIuDQpPbiBKdWwgMjQsIDIwMTQgMjoxMiBQTSwgIktpcmVldGkgS29tcGVsbGEi IDxraXJlZXRpQGp1bmlwZXIubmV0PG1haWx0bzpraXJlZXRpQGp1bmlwZXIubmV0Pj4gd3JvdGU6 DQpIaSBSb2JlcnQsDQoNCk9uIEp1bCAyNCwgMjAxNCwgYXQgMDM6MjEgLCBSb2JlcnQgUmFzenVr IDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCg0K VGhlcmVmb3IgYW4gYWx0ZXJuYXRpdmUgb2YgdXNpbmcgYW55IGZvcm0gb2YgZW50cm9weSBsYWJl bHMgaW4gZGF0YSBwbGFuZSBhbGwgdG9nZXRoZXIgd291bGQgYmUgdG8gYWxsb2NhdGUgYSBTSUQg YmxvY2tzIChzYXkgNjQgb3IgMTI4IHdpZGUpIGFuZCBhbGxvdyBTUFJJTkcgaGVhZGVyIGltcG9z aXRpb24gdG8gdXNlIHN1Y2ggcG9vbHMgb2YgU0lEcyBwZXIgZ3JvdXAgb2YgZmxvd3MgdG8gZWZm ZWN0aXZlbHkgYWxsb3cgZm9yIGVmZmljaWVudCBsb2FkIGJhbGFuY2luZyBpbiB0aGUgbmV0d29y ay4NCg0KV2XigJlyZSByZWhhc2hpbmcgKHB1biB1bmludGVuZGVkKSB0aGUgZW50cm9weSBsYWJl bCBkaXNjdXNzaW9uLg0KDQpCZWZvcmUgd2Ugc2V0dGxlZCBvbiBlbnRyb3B5IGxhYmVscyB0aGUg d2F5IHdlIGRpZCwgd2UgZGlzY3Vzc2VkIGFkdmVydGlzaW5nIGxhYmVsIGJsb2NrcyBpbiBMRFAu ICBUaGVyZSBhcmUgdHdvIHByb2JsZW1zOg0KYSkgYXMgU3RlcGhhbmUgbWVudGlvbnMsIEVMcyBh cmUgc3RhdGVsZXNzLCBidXQgcG9vbHMgb2YgU0lEcyBpbXBvc2UgbW9yZSBzdGF0ZSBpbiB0aGUg Zm9yd2FyZGluZyBwbGFuZSAoYW5kIHRvIHNvbWUgZXh0ZW50LCBpbiB0aGUgY29udHJvbCBwbGFu ZSkuDQpiKSBpZiB5b3UgdXNlIHNtYWxsIGJsb2NrcywgeW91IGdldCB1bmV2ZW4gbG9hZCBiYWxh bmNpbmc7IGlmIHlvdSB1c2UgbGFyZ2UgYmxvY2tzLCB5b3UgYmxvdyB1cCB0aGUgc3RhdGUgbW9y ZS4NCg0KS2lyZWV0aQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNl cywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJl Y3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0K DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N Cg0KVGhhbmsgeW91Lg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_9E32478DFA9976438E7A22F69B08FF9205D615OPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvYmVydCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkZyb20gYSBwcmFjdGljYWwgcG9pbnQgb2YgdmlldyAsIGhvdyBkbyZuYnNwOyB5b3UgcmVw cmVzZW50IHN1Y2ggTVBMUyBsYWJlbCByYW5nZSB3aXRoIGEgcHJlZml4ID88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WzcwLCAxNzBdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlsxNywgNjldPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NUExTIHdhcyBub3QgZGVzaWduZWQgZm9yIOKAnGxhYmVsIGFn Z3JlZ2F0aW9u4oCdIHNjaGVtZSDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3Ig d2UgbmVlZCB0byBjaGFuZ2Ugb2YgbGFiZWxzIGFyZSBhbGxvY2F0ZWQgZnJvbSB0aGUgbGFiZWwg c3BhY2UgZm9yIGFsbCBsYWJlbCBjb25zdW1lcnMg4oCmIHRvIHBlcm1pdCB0aGlzIGFnZ3JlZ2F0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJh c3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQgMTI6NTQ8YnI+DQo8Yj5Ubzo8L2I+ IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjxicj4NCjxiPkNjOjwvYj4gS2lyZWV0aSBLb21w ZWxsYTsgbXBsc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnOyBkcmFmdC1raW5pLW1wbHMtc3By aW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+U3RlcGhhbmUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgaGFzIE5PVEhJTkcgVE8gRE8gd2l0aCBJ UHY2LiBJIGFtIG5vdCBldmVuIHN1cmUgYmFzZWQgb24gd2hhdCB5b3UgZHJhdyBzdWNoIHN0cmFu Z2UgY29uY2x1c2lvbiAuLi4uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkkgYW0gdGFsa2luZyBwdXJlIGFib3V0IE1QTFMgZGF0YSBw bGFuZSAoZXZlbiB3aXRob3V0IGFueSBJUCBhYm92ZSkgYW5kIGhvdyB3ZSBjYW4gc29sdmUgdGhl IGxvYWQgYmFsYW5jaW5nIHByb2JsZW1zLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BdCBtaW4gSSBleHBlY3QgZm9yIGFueSBkaXNj dXNzaW9uIHRvIGJlIHZhbGlkIHRvIGRpc2N1c3MgYW5kIGNvbXBhcmUgYWxsIG9wdGlvbnMuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pk5vdGUgYWxzbyB0aGF0IFNQUklORyBkb2VzIG5vdCB1c2UgTERQIHNvIEkgYW0gbXVjaCBsZXNz IGludGVyZXN0ZWQgaW4gc29sdmluZyB0aGUgTERQIGxvYWQgYmFsYW5jaW5nIGlzc3Vlcy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ UmdzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Ui48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAyNCwgMjAx NCBhdCA2OjQ2IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFu Z2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9iZXJ0 LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRhbGtpbmcgTVBMUywgSSBkb27igJl0IHNlZSBhIHdheSB0byB1c2Ug TVBMUyBsYWJlbCDigJxwcmVmaXjigJ0g4oCmIHRoaXMgaXMgYSBkaXNjdXNzaW9uIHdlIGFscmVh ZHkgaGFkDQogdG9nZXRoZXIuIEkgdGhpbmsgeW91IGFyZSB0cnlpbmcgdG8gc2VsbCBJUHY2IFNS IHRoYXQgSSB3aWxsIHVuZm9ydHVuYXRlbHkgbm90IGJ1eSBhZ2Fpbg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdE Ij5KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc3ByaW5n IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0 IDA4OjQ4PGJyPg0KPGI+VG86PC9iPiBLaXJlZXRpIEtvbXBlbGxhPGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQpzcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQta2luaS1tcGxzLXNw cmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFm dC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBTUFJJTkcgTVBMUyBhbmQgRW50cm9weSBMYWJl bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkhpIEtpcmVldGksPG86cD48L286cD48L3A+ DQo8cD5JIHF1aXRlIGRpc2FncmVlIGFib3V0IHRoZSBtb3JlIHN0YXRlIGFyZ3VtZW50LjxvOnA+ PC9vOnA+PC9wPg0KPHA+SWYgeW91IHRyZWF0IG1wbHMgbGFiZWwgYXMgcHJlZml4IHdpdGggbWFz ayB3aGljaCBpcyBhbGwgdGhpcyBib2lscyBkb3duIHRvIHRoZXJlIGlzIG5vIG1vcmUgc3RhdGUg ZWl0aGVyIGluIGRhdGEgb3IgY29udHJvbCBwbGFuZS48bzpwPjwvbzpwPjwvcD4NCjxwPkFzIHRv IHRoZSBwb2ludCBvZiBub3QgcGVyZmVjdCBsb2FkIGJhbGFuY2luZyBpdCBhbGwgZGVwZW5kcyBv biB5b3VyIGhhc2ggZnVuY3Rpb24uIElmIHlvdSBhbHdheXMgYWR2ZXJ0aXNlIGF0IGxlYXN0IGFz IGJpZyBibG9jayBhcyB5b3UgaGF2ZSBtYXggcGFyYWxsZWwgbGlua3Mgb24gYW55IGludGVyZmFj ZSB5b3Ugc2hvdWxkIGJlIGZpbmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPkJlc3QgLDxicj4NClIu PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBKdWwgMjQs IDIwMTQgMjoxMiBQTSwgJnF1b3Q7S2lyZWV0aSBLb21wZWxsYSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmtpcmVldGlAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5raXJlZXRpQGp1bmlw ZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5IaSBSb2JlcnQsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIEp1bCAyNCwgMjAxNCwgYXQgMDM6MjEgLCBSb2JlcnQgUmFzenVr ICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5y b2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5UaGVyZWZvciBhbiBhbHRlcm5hdGl2ZSBvZiB1c2luZyBhbnkgZm9ybSBvZiBlbnRyb3B5 IGxhYmVscyBpbiBkYXRhIHBsYW5lIGFsbCB0b2dldGhlciB3b3VsZCBiZSB0byBhbGxvY2F0ZSBh IFNJRCBibG9ja3MgKHNheSA2NCBvciAxMjggd2lkZSkNCiBhbmQgYWxsb3cgU1BSSU5HIGhlYWRl ciBpbXBvc2l0aW9uIHRvIHVzZSBzdWNoIHBvb2xzIG9mIFNJRHMgcGVyIGdyb3VwIG9mIGZsb3dz IHRvIGVmZmVjdGl2ZWx5IGFsbG93IGZvciBlZmZpY2llbnQgbG9hZCBiYWxhbmNpbmcgaW4gdGhl IG5ldHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XZeKAmXJlIHJlaGFzaGluZyAocHVuIHVuaW50ZW5kZWQpIHRoZSBlbnRyb3B5 IGxhYmVsIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlZm9yZSB3ZSBzZXR0bGVkIG9uIGVudHJvcHkg bGFiZWxzIHRoZSB3YXkgd2UgZGlkLCB3ZSBkaXNjdXNzZWQgYWR2ZXJ0aXNpbmcgbGFiZWwgYmxv Y2tzIGluIExEUC4gJm5ic3A7VGhlcmUgYXJlIHR3byBwcm9ibGVtczo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YSkgYXMgU3RlcGhhbmUgbWVu dGlvbnMsIEVMcyBhcmUgc3RhdGVsZXNzLCBidXQgcG9vbHMgb2YgU0lEcyBpbXBvc2UgbW9yZSBz dGF0ZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSAoYW5kIHRvIHNvbWUgZXh0ZW50LCBpbiB0aGUg Y29udHJvbCBwbGFuZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPmIpIGlmIHlvdSB1c2Ugc21hbGwgYmxvY2tzLCB5b3UgZ2V0IHVuZXZlbiBs b2FkIGJhbGFuY2luZzsgaWYgeW91IHVzZSBsYXJnZSBibG9ja3MsIHlvdSBibG93IHVwIHRoZSBz dGF0ZSBtb3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+S2lyZWV0aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9o dG1sPg0K --_000_9E32478DFA9976438E7A22F69B08FF9205D615OPEXCLILM34corpor_-- From nobody Thu Jul 24 10:24:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0CE1A0146; Thu, 24 Jul 2014 10:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aEIERKcPtIa; Thu, 24 Jul 2014 10:24:33 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2ADF1A0B03; Thu, 24 Jul 2014 10:23:47 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id r2so96207igi.4 for ; Thu, 24 Jul 2014 10:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VsjPst/nikFW0AWz1tncMG/w/0GwNLiKzfiHS3FAWM8=; b=aTXXcPkZ5MPtzyJ86J0oQUydxVIzOr7XyozutYSKgzXsskg6h7JCAZxdc48KNcSzQG ui2J9tYRcMVeAW9Ax4lFjQDCgnd7VniXae5Qfo6EsyhORZcdrfjF934/pFXhkrxCIgkP eyHIMBTip46eU2XZ1k7GD4dxnZmHQuUZsaddWt2I9zKqKXvzYQUqL7rKJnnYcTr7HBe5 7NhO4mv6KUm6qdrGrZwX2zzwgHU7S6jUKMRknJLhjsr3AvHrPgv02Yjr1sQN0iMDsVZx Kaziw72aa/PWs0JINJV4GcJFcRKR0RYpi/ZxLbQBHSP+Mi+D+MGvQhzF+XTH3TaeVb0o EyLg== MIME-Version: 1.0 X-Received: by 10.42.154.132 with SMTP id q4mr14241239icw.4.1406222627014; Thu, 24 Jul 2014 10:23:47 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 10:23:46 -0700 (PDT) Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 10:23:46 -0700 (PDT) In-Reply-To: <10232_1406221553_53D13CF1_10232_3488_1_9E32478DFA9976438E7A22F69B08FF9205D615@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10232_1406221553_53D13CF1_10232_3488_1_9E32478DFA9976438E7A22F69B08FF9205D615@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 24 Jul 2014 19:23:46 +0200 X-Google-Sender-Auth: njB48SrUaigVqN1f39cIvksg45Q Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=90e6ba6e87a6288e1404fef3b86c Archived-At: http://mailarchive.ietf.org/arch/msg/spring/bIbMp19eZ9VPsMnVPWhoAt9Xw8Q Cc: Kireeti Kompella , "mpls@ietf.org" , spring@ietf.org, "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:24:35 -0000 --90e6ba6e87a6288e1404fef3b86c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, That is also solved problem ;) We already know how to encode label offset. Using the same encoding you can treat offset value as number of significant bits within the 20 bit label. We do not need to extend this to current label use cases. Hence there is no issue with backwards compatibility. Very basic and simple ;) Cheers, R. On Jul 24, 2014 7:05 PM, wrote: > Robert, > > > > From a practical point of view , how do you represent such MPLS label > range with a prefix ? > > [70, 170] > > [17, 69] > > > > MPLS was not designed for =E2=80=9Clabel aggregation=E2=80=9D scheme =E2= =80=A6 > > Or we need to change of labels are allocated from the label space for all > label consumers =E2=80=A6 to permit this aggregation. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Thursday, July 24, 2014 12:54 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Kireeti Kompella; mpls@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > Stephane, > > > > This has NOTHING TO DO with IPv6. I am not even sure based on what you > draw such strange conclusion .... > > > > I am talking pure about MPLS data plane (even without any IP above) and > how we can solve the load balancing problems. > > > > At min I expect for any discussion to be valid to discuss and compare all > options. > > > > Note also that SPRING does not use LDP so I am much less interested in > solving the LDP load balancing issues. > > > > Rgs, > > R. > > > > > > On Thu, Jul 24, 2014 at 6:46 PM, wrote: > > Robert, > > > > Talking MPLS, I don=E2=80=99t see a way to use MPLS label =E2=80=9Cprefix= =E2=80=9D =E2=80=A6 this is a > discussion we already had together. I think you are trying to sell IPv6 S= R > that I will unfortunately not buy again J > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 08:48 > *To:* Kireeti Kompella > *Cc:* mpls@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > Hi Kireeti, > > I quite disagree about the more state argument. > > If you treat mpls label as prefix with mask which is all this boils down > to there is no more state either in data or control plane. > > As to the point of not perfect load balancing it all depends on your hash > function. If you always advertise at least as big block as you have max > parallel links on any interface you should be fine. > > Best , > R. > > On Jul 24, 2014 2:12 PM, "Kireeti Kompella" wrote: > > Hi Robert, > > > > On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > > > > Therefor an alternative of using any form of entropy labels in data plane > all together would be to allocate a SID blocks (say 64 or 128 wide) and > allow SPRING header imposition to use such pools of SIDs per group of flo= ws > to effectively allow for efficient load balancing in the network. > > > > We=E2=80=99re rehashing (pun unintended) the entropy label discussion. > > > > Before we settled on entropy labels the way we did, we discussed > advertising label blocks in LDP. There are two problems: > > a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more > state in the forwarding plane (and to some extent, in the control plane). > > b) if you use small blocks, you get uneven load balancing; if you use > large blocks, you blow up the state more. > > > > Kireeti > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --90e6ba6e87a6288e1404fef3b86c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

That is also solved problem ;)

We already know how to encode label offset. Using the same e= ncoding you can treat offset value as number of significant bits within the= 20 bit label.

We do not need to extend this to current label use cases. He= nce there is no issue with backwards compatibility.

Very basic and simple ;)

Cheers,
R.

On Jul 24, 2014 7:05 PM, <stephane.litkowski@orange.com> wrote:=

Robert,

=C2=A0

From a practical point of= view , how do=C2=A0 you represent such MPLS label range with a prefix ?=

[70, 170]

[17, 69]

=C2=A0

MPLS was not designed for= =E2=80=9Clabel aggregation=E2=80=9D scheme =E2=80=A6<= /p>

Or we need to change of l= abels are allocated from the label space for all label consumers =E2=80=A6 = to permit this aggregation.

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 12:54
To: LITKOWSKI Stephane SCE/IBNF
Cc: Kireeti Kompella; mpls@ietf.org; spring@ietf.org; draft-kini-mpls-spring-entropy-label@t= ools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label

=C2=A0

= Stephane,

= =C2=A0

= This has NOTHING TO DO with IPv6. I am not even sure based on what you draw= such strange conclusion ....=C2=A0

= =C2=A0

= I am talking pure about MPLS data plane (even without any IP above) and how= we can solve the load balancing problems.=C2=A0

= =C2=A0

= At min I expect for any discussion to be valid to discuss and compare all o= ptions.=C2=A0

= =C2=A0

= Note also that SPRING does not use LDP so I am much less interested in solv= ing the LDP load balancing issues.=C2=A0

= =C2=A0

= Rgs,

= R.

= =C2=A0

=C2=A0<= /p>

On Thu, Jul 24, 2014 at 6:46 PM, <stephane.litkowski@oran= ge.com> wrote:

Robert,<= /u>

=C2=A0

Talking MPLS, I don=E2=80= =99t see a way to use MPLS label =E2=80=9Cprefix=E2=80=9D =E2=80=A6 this is= a discussion we already had together. I think you are trying to sell IPv6 SR that I will unfortunately= not buy again J

=C2=A0

From: spring [= mailto:spring-= bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 08:48
To: Kireeti Kompella
Cc: mpls@ietf.org= ; spring@ietf.org; draft-kini-mpls-spring-entropy-label@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label=

=C2=A0

Hi Kireeti,

I quite disagree about the more state argument.

If you treat mpls label as prefix with mask which is all this boils down= to there is no more state either in data or control plane.

As to the point of not perfect load balancing it all depends on your has= h function. If you always advertise at least as big block as you have max p= arallel links on any interface you should be fine.

Best ,
R.

On Jul 24, 2014 2:12 PM, "Kireeti Kompella"= ; <kireeti@juni= per.net> wrote:

Hi Robert,

=C2=A0

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> = wrote:

=C2=A0<= /p>

= Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allow SPRING header imposition to use such pools of SIDs per group of = flows to effectively allow for efficient load balancing in the network.

=C2=A0

We=E2=80=99re rehashing (pun unintended) the entropy= label discussion.

=C2=A0

Before we settled on entropy labels the way we did, = we discussed advertising label blocks in LDP. =C2=A0There are two problems:=

a) as Stephane mentions, ELs are stateless, but pool= s of SIDs impose more state in the forwarding plane (and to some extent, in= the control plane).

b) if you use small blocks, you get uneven load bala= ncing; if you use large blocks, you blow up the state more.

=C2=A0

Kireeti

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.

=C2=A0

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--90e6ba6e87a6288e1404fef3b86c-- From nobody Thu Jul 24 10:39:25 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FF91A0A9F; Thu, 24 Jul 2014 10:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2pRZ6VYkM0c; Thu, 24 Jul 2014 10:39:17 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175111A0275; Thu, 24 Jul 2014 10:39:17 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8926F2AC975; Thu, 24 Jul 2014 19:39:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 670E8C804B; Thu, 24 Jul 2014 19:39:15 +0200 (CEST) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.91]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 24 Jul 2014 19:39:15 +0200 From: To: Robert Raszuk Thread-Topic: [spring] SPRING MPLS and Entropy Label Thread-Index: AQHPpop+sk+mL1pXdkKUVhjrFSzu1puuo0mAgAAN5ACAAFFmAIAACegAgABjfaD//+E4AIAAI60A///kkwCAACS3wA== Date: Thu, 24 Jul 2014 17:39:14 +0000 Message-ID: <31300_1406223555_53D144C3_31300_12346_1_9E32478DFA9976438E7A22F69B08FF9205D6CF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10232_1406221553_53D13CF1_10232_3488_1_9E32478DFA9976438E7A22F69B08FF9205D615@OPEXCLILM34.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9205D6CFOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.24.170019 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/AqZpwCg8x1hFTezFd08CBQq6lQM Cc: Kireeti Kompella , "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:39:21 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9205D6CFOPEXCLILM34corpor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBXZSBhbHJlYWR5IGtub3cgaG93IHRvIGVuY29kZSBsYWJlbCBvZmZzZXQuDQpBcmUgeW91IHJl ZmVycmluZyB0byBTZWdtZW50IEluZGV4IGFzIG9mZnNldCAgb2YgbGFiZWwgYmFzZSA/DQoNCj4g VXNpbmcgdGhlIHNhbWUgZW5jb2RpbmcgeW91IGNhbiB0cmVhdCBvZmZzZXQgdmFsdWUgYXMgbnVt YmVyIG9mIHNpZ25pZmljYW50IGJpdHMgd2l0aGluIHRoZSAyMCBiaXQgbGFiZWwuDQpDb3VsZCB5 b3UgZ2l2ZSBhbiBleGFtcGxlICBvZiBsb29rdXAgYW5kIGZvcndhcmRpbmcgc3RydWN0dXJlIGZv ciB5b3VyIGxhYmVsIHJhbmdlL2xhYmVsIHByZWZpeCA/IEkgc2VlIHNvbWV0aGluZyBwb3NzaWJs ZSBidXQgSSBzdGlsbCBoYXZlIGFuIGlzc3VlIHdpdGggdGhlIGxvb2t1cCBzdHJ1Y3R1cmUuDQoN Cg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBP biBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVGh1cnNkYXksIEp1bHkgMjQsIDIwMTQg MTM6MjQNClRvOiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkYNCkNjOiBLaXJlZXRpIEtvbXBl bGxhOyBzcHJpbmdAaWV0Zi5vcmc7IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJl bEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzcHJpbmddIFNQ UklORyBNUExTIGFuZCBFbnRyb3B5IExhYmVsDQoNCg0KSGksDQoNClRoYXQgaXMgYWxzbyBzb2x2 ZWQgcHJvYmxlbSA7KQ0KDQpXZSBhbHJlYWR5IGtub3cgaG93IHRvIGVuY29kZSBsYWJlbCBvZmZz ZXQuIFVzaW5nIHRoZSBzYW1lIGVuY29kaW5nIHlvdSBjYW4gdHJlYXQgb2Zmc2V0IHZhbHVlIGFz IG51bWJlciBvZiBzaWduaWZpY2FudCBiaXRzIHdpdGhpbiB0aGUgMjAgYml0IGxhYmVsLg0KDQpX ZSBkbyBub3QgbmVlZCB0byBleHRlbmQgdGhpcyB0byBjdXJyZW50IGxhYmVsIHVzZSBjYXNlcy4g SGVuY2UgdGhlcmUgaXMgbm8gaXNzdWUgd2l0aCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4NCg0K VmVyeSBiYXNpYyBhbmQgc2ltcGxlIDspDQoNCkNoZWVycywNClIuDQpPbiBKdWwgMjQsIDIwMTQg NzowNSBQTSwgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KUm9iZXJ0LA0KDQpGcm9tIGEgcHJhY3RpY2Fs IHBvaW50IG9mIHZpZXcgLCBob3cgZG8gIHlvdSByZXByZXNlbnQgc3VjaCBNUExTIGxhYmVsIHJh bmdlIHdpdGggYSBwcmVmaXggPw0KWzcwLCAxNzBdDQpbMTcsIDY5XQ0KDQpNUExTIHdhcyBub3Qg ZGVzaWduZWQgZm9yIOKAnGxhYmVsIGFnZ3JlZ2F0aW9u4oCdIHNjaGVtZSDigKYNCk9yIHdlIG5l ZWQgdG8gY2hhbmdlIG9mIGxhYmVscyBhcmUgYWxsb2NhdGVkIGZyb20gdGhlIGxhYmVsIHNwYWNl IGZvciBhbGwgbGFiZWwgY29uc3VtZXJzIOKApiB0byBwZXJtaXQgdGhpcyBhZ2dyZWdhdGlvbi4N Cg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFtt YWlsdG86cnJhc3p1a0BnbWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gT24gQmVo YWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDEyOjU0 DQpUbzogTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GDQpDYzogS2lyZWV0aSBLb21wZWxsYTsg bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPjsgZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVs QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFi ZWxAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5k IEVudHJvcHkgTGFiZWwNCg0KU3RlcGhhbmUsDQoNClRoaXMgaGFzIE5PVEhJTkcgVE8gRE8gd2l0 aCBJUHY2LiBJIGFtIG5vdCBldmVuIHN1cmUgYmFzZWQgb24gd2hhdCB5b3UgZHJhdyBzdWNoIHN0 cmFuZ2UgY29uY2x1c2lvbiAuLi4uDQoNCkkgYW0gdGFsa2luZyBwdXJlIGFib3V0IE1QTFMgZGF0 YSBwbGFuZSAoZXZlbiB3aXRob3V0IGFueSBJUCBhYm92ZSkgYW5kIGhvdyB3ZSBjYW4gc29sdmUg dGhlIGxvYWQgYmFsYW5jaW5nIHByb2JsZW1zLg0KDQpBdCBtaW4gSSBleHBlY3QgZm9yIGFueSBk aXNjdXNzaW9uIHRvIGJlIHZhbGlkIHRvIGRpc2N1c3MgYW5kIGNvbXBhcmUgYWxsIG9wdGlvbnMu DQoNCk5vdGUgYWxzbyB0aGF0IFNQUklORyBkb2VzIG5vdCB1c2UgTERQIHNvIEkgYW0gbXVjaCBs ZXNzIGludGVyZXN0ZWQgaW4gc29sdmluZyB0aGUgTERQIGxvYWQgYmFsYW5jaW5nIGlzc3Vlcy4N Cg0KUmdzLA0KUi4NCg0KDQpPbiBUaHUsIEp1bCAyNCwgMjAxNCBhdCA2OjQ2IFBNLCA8c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tPj4gd3JvdGU6DQpSb2JlcnQsDQoNClRhbGtpbmcgTVBMUywgSSBkb27igJl0IHNlZSBhIHdh eSB0byB1c2UgTVBMUyBsYWJlbCDigJxwcmVmaXjigJ0g4oCmIHRoaXMgaXMgYSBkaXNjdXNzaW9u IHdlIGFscmVhZHkgaGFkIHRvZ2V0aGVyLiBJIHRoaW5rIHlvdSBhcmUgdHJ5aW5nIHRvIHNlbGwg SVB2NiBTUiB0aGF0IEkgd2lsbCB1bmZvcnR1bmF0ZWx5IG5vdCBidXkgYWdhaW4g4pi6DQoNCkZy b206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmct Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUaHVy c2RheSwgSnVseSAyNCwgMjAxNCAwODo0OA0KVG86IEtpcmVldGkgS29tcGVsbGENCkNjOiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+OyBkcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0 b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBTUFJJTkcgTVBMUyBhbmQgRW50 cm9weSBMYWJlbA0KDQoNCkhpIEtpcmVldGksDQoNCkkgcXVpdGUgZGlzYWdyZWUgYWJvdXQgdGhl IG1vcmUgc3RhdGUgYXJndW1lbnQuDQoNCklmIHlvdSB0cmVhdCBtcGxzIGxhYmVsIGFzIHByZWZp eCB3aXRoIG1hc2sgd2hpY2ggaXMgYWxsIHRoaXMgYm9pbHMgZG93biB0byB0aGVyZSBpcyBubyBt b3JlIHN0YXRlIGVpdGhlciBpbiBkYXRhIG9yIGNvbnRyb2wgcGxhbmUuDQoNCkFzIHRvIHRoZSBw b2ludCBvZiBub3QgcGVyZmVjdCBsb2FkIGJhbGFuY2luZyBpdCBhbGwgZGVwZW5kcyBvbiB5b3Vy IGhhc2ggZnVuY3Rpb24uIElmIHlvdSBhbHdheXMgYWR2ZXJ0aXNlIGF0IGxlYXN0IGFzIGJpZyBi bG9jayBhcyB5b3UgaGF2ZSBtYXggcGFyYWxsZWwgbGlua3Mgb24gYW55IGludGVyZmFjZSB5b3Ug c2hvdWxkIGJlIGZpbmUuDQoNCkJlc3QgLA0KUi4NCk9uIEp1bCAyNCwgMjAxNCAyOjEyIFBNLCAi S2lyZWV0aSBLb21wZWxsYSIgPGtpcmVldGlAanVuaXBlci5uZXQ8bWFpbHRvOmtpcmVldGlAanVu aXBlci5uZXQ+PiB3cm90ZToNCkhpIFJvYmVydCwNCg0KT24gSnVsIDI0LCAyMDE0LCBhdCAwMzoy MSAsIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4+IHdyb3RlOg0KDQpUaGVyZWZvciBhbiBhbHRlcm5hdGl2ZSBvZiB1c2luZyBhbnkgZm9y bSBvZiBlbnRyb3B5IGxhYmVscyBpbiBkYXRhIHBsYW5lIGFsbCB0b2dldGhlciB3b3VsZCBiZSB0 byBhbGxvY2F0ZSBhIFNJRCBibG9ja3MgKHNheSA2NCBvciAxMjggd2lkZSkgYW5kIGFsbG93IFNQ UklORyBoZWFkZXIgaW1wb3NpdGlvbiB0byB1c2Ugc3VjaCBwb29scyBvZiBTSURzIHBlciBncm91 cCBvZiBmbG93cyB0byBlZmZlY3RpdmVseSBhbGxvdyBmb3IgZWZmaWNpZW50IGxvYWQgYmFsYW5j aW5nIGluIHRoZSBuZXR3b3JrLg0KDQpXZeKAmXJlIHJlaGFzaGluZyAocHVuIHVuaW50ZW5kZWQp IHRoZSBlbnRyb3B5IGxhYmVsIGRpc2N1c3Npb24uDQoNCkJlZm9yZSB3ZSBzZXR0bGVkIG9uIGVu dHJvcHkgbGFiZWxzIHRoZSB3YXkgd2UgZGlkLCB3ZSBkaXNjdXNzZWQgYWR2ZXJ0aXNpbmcgbGFi ZWwgYmxvY2tzIGluIExEUC4gIFRoZXJlIGFyZSB0d28gcHJvYmxlbXM6DQphKSBhcyBTdGVwaGFu ZSBtZW50aW9ucywgRUxzIGFyZSBzdGF0ZWxlc3MsIGJ1dCBwb29scyBvZiBTSURzIGltcG9zZSBt b3JlIHN0YXRlIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIChhbmQgdG8gc29tZSBleHRlbnQsIGlu IHRoZSBjb250cm9sIHBsYW5lKS4NCmIpIGlmIHlvdSB1c2Ugc21hbGwgYmxvY2tzLCB5b3UgZ2V0 IHVuZXZlbiBsb2FkIGJhbGFuY2luZzsgaWYgeW91IHVzZSBsYXJnZSBibG9ja3MsIHlvdSBibG93 IHVwIHRoZSBzdGF0ZSBtb3JlLg0KDQpLaXJlZXRpDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0K DQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_9E32478DFA9976438E7A22F69B08FF9205D6CFOPEXCLILM34corpor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+IFdl IGFscmVhZHkga25vdyBob3cgdG8gZW5jb2RlIGxhYmVsIG9mZnNldC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSB5b3UgcmVmZXJyaW5nIHRvIFNlZ21lbnQgSW5kZXgg YXMgb2Zmc2V0Jm5ic3A7IG9mIGxhYmVsIGJhc2UgPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPiBVc2luZyB0aGUg c2FtZSBlbmNvZGluZyB5b3UgY2FuIHRyZWF0IG9mZnNldCB2YWx1ZSBhcyBudW1iZXIgb2Ygc2ln bmlmaWNhbnQgYml0cyB3aXRoaW4gdGhlIDIwIGJpdCBsYWJlbC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHlvdSBnaXZlIGFuIGV4YW1wbGUgJm5ic3A7b2YgbG9v a3VwIGFuZCBmb3J3YXJkaW5nIHN0cnVjdHVyZSBmb3IgeW91ciBsYWJlbCByYW5nZS9sYWJlbCBw cmVmaXggPyBJIHNlZSBzb21ldGhpbmcgcG9zc2libGUgYnV0IEkgc3RpbGwgaGF2ZSBhbiBpc3N1 ZSB3aXRoIHRoZSBsb29rdXAgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRv OnJyYXN6dWtAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDI0LCAyMDE0IDEzOjI0PGJyPg0KPGI+VG86 PC9iPiBMSVRLT1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY8YnI+DQo8Yj5DYzo8L2I+IEtpcmVldGkg S29tcGVsbGE7IHNwcmluZ0BpZXRmLm9yZzsgZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5 LWxhYmVsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBbc3ByaW5nXSBTUFJJTkcgTVBMUyBhbmQgRW50cm9weSBMYWJlbDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ SGksPG86cD48L286cD48L3A+DQo8cD5UaGF0IGlzIGFsc28gc29sdmVkIHByb2JsZW0gOyk8bzpw PjwvbzpwPjwvcD4NCjxwPldlIGFscmVhZHkga25vdyBob3cgdG8gZW5jb2RlIGxhYmVsIG9mZnNl dC4gVXNpbmcgdGhlIHNhbWUgZW5jb2RpbmcgeW91IGNhbiB0cmVhdCBvZmZzZXQgdmFsdWUgYXMg bnVtYmVyIG9mIHNpZ25pZmljYW50IGJpdHMgd2l0aGluIHRoZSAyMCBiaXQgbGFiZWwuPG86cD48 L286cD48L3A+DQo8cD5XZSBkbyBub3QgbmVlZCB0byBleHRlbmQgdGhpcyB0byBjdXJyZW50IGxh YmVsIHVzZSBjYXNlcy4gSGVuY2UgdGhlcmUgaXMgbm8gaXNzdWUgd2l0aCBiYWNrd2FyZHMgY29t cGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwPlZlcnkgYmFzaWMgYW5kIHNpbXBsZSA7KTxv OnA+PC9vOnA+PC9wPg0KPHA+Q2hlZXJzLDxicj4NClIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDI0LCAyMDE0IDc6MDUgUE0sICZsdDs8YSBocmVm PSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJvYmVydCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIGEgcHJhY3RpY2FsIHBvaW50IG9m IHZpZXcgLCBob3cgZG8mbmJzcDsgeW91IHJlcHJlc2VudCBzdWNoIE1QTFMgbGFiZWwgcmFuZ2Ug d2l0aCBhIHByZWZpeCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WzcwLCAxNzBd PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WzE3LCA2OV08L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N UExTIHdhcyBub3QgZGVzaWduZWQgZm9yIOKAnGxhYmVsIGFnZ3JlZ2F0aW9u4oCdIHNjaGVtZSDi gKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PciB3ZSBuZWVkIHRvIGNoYW5nZSBv ZiBsYWJlbHMgYXJlIGFsbG9jYXRlZCBmcm9tIHRoZSBsYWJlbCBzcGFjZSBmb3IgYWxsIGxhYmVs IGNvbnN1bWVycyDigKYgdG8gcGVybWl0DQogdGhpcyBhZ2dyZWdhdGlvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5jb208L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnJyYXN6dWtAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnJhc3p1a0BnbWFpbC5jb208L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKdWx5IDI0LCAyMDE0IDEyOjU0PGJyPg0KPGI+VG86PC9iPiBMSVRLT1dTS0kgU3Rl cGhhbmUgU0NFL0lCTkY8YnI+DQo8Yj5DYzo8L2I+IEtpcmVldGkgS29tcGVsbGE7IDxhIGhyZWY9 Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT47 DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50 cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQta2luaS1t cGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3NwcmluZ10gU1BSSU5HIE1QTFMgYW5kIEVudHJvcHkgTGFiZWw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3RlcGhhbmUsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIGhhcyBO T1RISU5HIFRPIERPIHdpdGggSVB2Ni4gSSBhbSBub3QgZXZlbiBzdXJlIGJhc2VkIG9uIHdoYXQg eW91IGRyYXcgc3VjaCBzdHJhbmdlIGNvbmNsdXNpb24gLi4uLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBhbSB0YWxraW5n IHB1cmUgYWJvdXQgTVBMUyBkYXRhIHBsYW5lIChldmVuIHdpdGhvdXQgYW55IElQIGFib3ZlKSBh bmQgaG93IHdlIGNhbiBzb2x2ZSB0aGUgbG9hZCBiYWxhbmNpbmcgcHJvYmxlbXMuJm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B dCBtaW4gSSBleHBlY3QgZm9yIGFueSBkaXNjdXNzaW9uIHRvIGJlIHZhbGlkIHRvIGRpc2N1c3Mg YW5kIGNvbXBhcmUgYWxsIG9wdGlvbnMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Ob3RlIGFsc28gdGhhdCBTUFJJTkcgZG9l cyBub3QgdXNlIExEUCBzbyBJIGFtIG11Y2ggbGVzcyBpbnRlcmVzdGVkIGluIHNvbHZpbmcgdGhl IExEUCBsb2FkIGJhbGFuY2luZyBpc3N1ZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SZ3MsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlIuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSnVs IDI0LCAyMDE0IGF0IDY6NDYgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293 c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Sb2JlcnQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGFsa2luZyBNUExTLCBJIGRvbuKAmXQgc2VlIGEgd2F5 IHRvIHVzZSBNUExTIGxhYmVsIOKAnHByZWZpeOKAnSDigKYgdGhpcyBpcyBhIGRpc2N1c3Npb24g d2UgYWxyZWFkeSBoYWQNCiB0b2dldGhlci4gSSB0aGluayB5b3UgYXJlIHRyeWluZyB0byBzZWxs IElQdjYgU1IgdGhhdCBJIHdpbGwgdW5mb3J0dW5hdGVseSBub3QgYnV5IGFnYWluDQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPko8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBzcHJpbmcgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkg MjQsIDIwMTQgMDg6NDg8YnI+DQo8Yj5Ubzo8L2I+IEtpcmVldGkgS29tcGVsbGE8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBs c0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnNwcmluZ0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1raW5p LW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIFNQUklORyBNUExTIGFuZCBFbnRy b3B5IExhYmVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SGkgS2lyZWV0aSw8bzpwPjwv bzpwPjwvcD4NCjxwPkkgcXVpdGUgZGlzYWdyZWUgYWJvdXQgdGhlIG1vcmUgc3RhdGUgYXJndW1l bnQuPG86cD48L286cD48L3A+DQo8cD5JZiB5b3UgdHJlYXQgbXBscyBsYWJlbCBhcyBwcmVmaXgg d2l0aCBtYXNrIHdoaWNoIGlzIGFsbCB0aGlzIGJvaWxzIGRvd24gdG8gdGhlcmUgaXMgbm8gbW9y ZSBzdGF0ZSBlaXRoZXIgaW4gZGF0YSBvciBjb250cm9sIHBsYW5lLjxvOnA+PC9vOnA+PC9wPg0K PHA+QXMgdG8gdGhlIHBvaW50IG9mIG5vdCBwZXJmZWN0IGxvYWQgYmFsYW5jaW5nIGl0IGFsbCBk ZXBlbmRzIG9uIHlvdXIgaGFzaCBmdW5jdGlvbi4gSWYgeW91IGFsd2F5cyBhZHZlcnRpc2UgYXQg bGVhc3QgYXMgYmlnIGJsb2NrIGFzIHlvdSBoYXZlIG1heCBwYXJhbGxlbCBsaW5rcyBvbiBhbnkg aW50ZXJmYWNlIHlvdSBzaG91bGQgYmUgZmluZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+QmVzdCAs PGJyPg0KUi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IEp1bCAyNCwgMjAxNCAyOjEyIFBNLCAmcXVvdDtLaXJlZXRpIEtvbXBlbGxhJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86a2lyZWV0aUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmtpcmVl dGlAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIFJvYmVydCwNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gSnVsIDI0LCAyMDE0LCBhdCAwMzoyMSAsIFJvYmVy dCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlRoZXJlZm9yIGFuIGFsdGVybmF0aXZlIG9mIHVzaW5nIGFueSBmb3JtIG9m IGVudHJvcHkgbGFiZWxzIGluIGRhdGEgcGxhbmUgYWxsIHRvZ2V0aGVyIHdvdWxkIGJlIHRvIGFs bG9jYXRlIGEgU0lEIGJsb2NrcyAoc2F5IDY0IG9yIDEyOCB3aWRlKQ0KIGFuZCBhbGxvdyBTUFJJ TkcgaGVhZGVyIGltcG9zaXRpb24gdG8gdXNlIHN1Y2ggcG9vbHMgb2YgU0lEcyBwZXIgZ3JvdXAg b2YgZmxvd3MgdG8gZWZmZWN0aXZlbHkgYWxsb3cgZm9yIGVmZmljaWVudCBsb2FkIGJhbGFuY2lu ZyBpbiB0aGUgbmV0d29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPldl4oCZcmUgcmVoYXNoaW5nIChwdW4gdW5pbnRlbmRlZCkgdGhl IGVudHJvcHkgbGFiZWwgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVmb3JlIHdlIHNldHRsZWQgb24g ZW50cm9weSBsYWJlbHMgdGhlIHdheSB3ZSBkaWQsIHdlIGRpc2N1c3NlZCBhZHZlcnRpc2luZyBs YWJlbCBibG9ja3MgaW4gTERQLiAmbmJzcDtUaGVyZSBhcmUgdHdvIHByb2JsZW1zOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hKSBhcyBTdGVw aGFuZSBtZW50aW9ucywgRUxzIGFyZSBzdGF0ZWxlc3MsIGJ1dCBwb29scyBvZiBTSURzIGltcG9z ZSBtb3JlIHN0YXRlIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIChhbmQgdG8gc29tZSBleHRlbnQs IGluIHRoZSBjb250cm9sIHBsYW5lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+YikgaWYgeW91IHVzZSBzbWFsbCBibG9ja3MsIHlvdSBnZXQg dW5ldmVuIGxvYWQgYmFsYW5jaW5nOyBpZiB5b3UgdXNlIGxhcmdlIGJsb2NrcywgeW91IGJsb3cg dXAgdGhlIHN0YXRlIG1vcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5LaXJlZXRpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48 L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF9205D6CFOPEXCLILM34corpor_-- From nobody Thu Jul 24 11:31:50 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20D1A016B; Thu, 24 Jul 2014 11:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APd8uTq-rU97; Thu, 24 Jul 2014 11:31:48 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA65B1A015D; Thu, 24 Jul 2014 11:31:46 -0700 (PDT) Received: from [2001:67c:370:176:b053:d33f:722f:f376] (helo=wireless-a-v6.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XANnn-0000Cm-R9; Thu, 24 Jul 2014 19:31:40 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Rob Shakir In-Reply-To: Date: Thu, 24 Jul 2014 14:31:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/WGFsQn8J8BlkM8gFjzVaUyL7kng Cc: "mpls@ietf.org" , "Ruediger.Geib@telekom.de Geib" , "spring@ietf.org" , draft-kini-mpls-spring-entropy-label@tools.ietf.org Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:31:49 -0000 Hi Robert, On 24 Jul 2014, at 03:21, Robert Raszuk wrote: >=20 > Therefor an alternative of using any form of entropy labels in data = plane all together would be to allocate a SID blocks (say 64 or 128 = wide) and allow SPRING header imposition to use such pools of SIDs per = group of flows to effectively allow for efficient load balancing in the = network. Sorry, maybe I=92m missing something here, but I found your message a = little cryptic. =46rom what I comprehend, you are saying that we define that a single = SID maps to N labels. These labels are split somehow into a =93forwarding=94= and =93hash=94 value. Simplistically, this could say that we have the = first 12 bits as the =93forwarding=94 and the bottom 8 as the =93hash=94 = value.=20 e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), = anything that is in the range 0b0000010100000000000 (10240) - = 0b0000010100011111111 (10495) has the same forwarding behaviour, but the = last 8 bits are used to hash (allowing 256 different hash-able objects). If I understood right - then this seems to have a number of challenges = to me: - For Node-SIDs, we now must sterilise the SRGB to be as wide as (number = of required entries)*(number of hash-able objects required) - which = means that we must be able to determine a label block that can be used = for this. - We reduce the size of the label space from 20-bits to a smaller value = - this might be a material concern in cases where we have many other = labels that are allocated on a device (per-prefix label allocation = within an L3VPN environment that has many prefixes might be a concern?). - We need every device in the network to comprehend this new format of = label allocation and imposition - such that we do not increase the = number of forwarding entries that are required (as Stephane and Kireeti = have observed). This is problematic where we have limited LFIB already = since instead of programming a number of LFIB entries O(the number of = labelled endpoints) then we instead need to have O(number of labelled = endpoints * number of hashable objects). Equally, I think the assertion that you have made is that deeper EL is = not =93easily supported by most of [today=92s] shipping routers=94. I = think that we need to determine whether this is really the case =97 = given that MPLS WG has standardised EL we need to figure *why* a change = from this is required =97 which is (I guess) the intention of the draft = we=92re discussing here. *If* we conclude that none of the options that = are presented using existing technology are suitable, then potentially = then we can look at new solutions. If my reading of your mail is completely whacky, then please ignore the = above - and a clarifying example would be greatly appreciated. thx, r. From nobody Thu Jul 24 13:21:45 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460391A0194; Thu, 24 Jul 2014 13:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G42gfosHcuv; Thu, 24 Jul 2014 13:21:34 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC161B2809; Thu, 24 Jul 2014 13:21:33 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so2782380iec.31 for ; Thu, 24 Jul 2014 13:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5eijuSBmDJGi45+aFDQAv/FOB3KuR9gagmS0FCg+JzM=; b=JLwZiUkLUztFhPDZw/0zIgKcqRZZG+Fi7WnKesOrnP45aB8TNWIkHM37uuHaUE22Ot WtB52WOqTylO+1bMu1SEVOPvln57fQXQ66RS0fIUtKAyR8DwnylKCNlBsuViMk5RIxfS LvOLqx+SFNlq8Gj90hNx+IAivsKaeiEh9iPm4IW9F0Uxguzz78lWPjWzpfkIxB8Pmh+2 SGAUet12UQlBc3qE1XkyRDr8B6nHx5FKwjbQPutMJFiWOHZW6+Zlx29LLDpQSZjWOLOc dfUQTaUZZiNaNhVy/J97TmNeH5NoAupVcV4XLDgJDJbGaK0f0MMZ9vdfrTBBJYVgichO IKCA== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr18774342igx.9.1406233293163; Thu, 24 Jul 2014 13:21:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 13:21:33 -0700 (PDT) In-Reply-To: <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> Date: Thu, 24 Jul 2014 22:21:33 +0200 X-Google-Sender-Auth: UD48OOtcGG8oXDyoKn3h36pcm80 Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: multipart/alternative; boundary=089e0122a754e913d004fef6331c Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9wxqFuvQN1OTsH_aPoMtyqCziiU Cc: "mpls@ietf.org" , "Ruediger.Geib@telekom.de Geib" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:21:40 -0000 --089e0122a754e913d004fef6331c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rob, I see your interpretation and where it could be confusing. You have clearly went beyond my boldest intentions :) > From what I comprehend, you are saying that we define > that a single SID maps to N labels. Nope. That is perhaps key difference. My proposal is that node advertises block of Node-SIDs which in turn map 1:1 to MPLS labels. The block of Node-SIDs as as big as largest expected number of parallel links. /* There is no harm in wrong estimation as simply you will just readvertise larger or smaller block */ While this could be accomplished today and may work fine in number of deployments as is there is clear opportunity for optimization. That say that SID block can be represented as prefix so naturally corresponding to it MPLS labels. That said there are two things missing ... * fundamental the SR architecture does not accommodate that * MPLS data plane can be optimized to reduce number of LFIB entries. And that's it. How you use it seems just natural both on ingress as well as on the transit nodes. Best, r. On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir wrote: > Hi Robert, > > On 24 Jul 2014, at 03:21, Robert Raszuk wrote: > > > > > Therefor an alternative of using any form of entropy labels in data > plane all together would be to allocate a SID blocks (say 64 or 128 wide) > and allow SPRING header imposition to use such pools of SIDs per group of > flows to effectively allow for efficient load balancing in the network. > > Sorry, maybe I=E2=80=99m missing something here, but I found your message= a little > cryptic. > > From what I comprehend, you are saying that we define that a single SID > maps to N labels. These labels are split somehow into a =E2=80=9Cforwardi= ng=E2=80=9D and > =E2=80=9Chash=E2=80=9D value. Simplistically, this could say that we have= the first 12 bits > as the =E2=80=9Cforwarding=E2=80=9D and the bottom 8 as the =E2=80=9Chash= =E2=80=9D value. > > e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), anything > that is in the range 0b0000010100000000000 (10240) - 0b000001010001111111= 1 > (10495) has the same forwarding behaviour, but the last 8 bits are used t= o > hash (allowing 256 different hash-able objects). > > If I understood right - then this seems to have a number of challenges to > me: > > - For Node-SIDs, we now must sterilise the SRGB to be as wide as (number > of required entries)*(number of hash-able objects required) - which means > that we must be able to determine a label block that can be used for this= . > - We reduce the size of the label space from 20-bits to a smaller value - > this might be a material concern in cases where we have many other labels > that are allocated on a device (per-prefix label allocation within an L3V= PN > environment that has many prefixes might be a concern?). > - We need every device in the network to comprehend this new format of > label allocation and imposition - such that we do not increase the number > of forwarding entries that are required (as Stephane and Kireeti have > observed). This is problematic where we have limited LFIB already since > instead of programming a number of LFIB entries O(the number of labelled > endpoints) then we instead need to have O(number of labelled endpoints * > number of hashable objects). > > Equally, I think the assertion that you have made is that deeper EL is no= t > =E2=80=9Ceasily supported by most of [today=E2=80=99s] shipping routers= =E2=80=9D. I think that we > need to determine whether this is really the case =E2=80=94 given that MP= LS WG has > standardised EL we need to figure *why* a change from this is required = =E2=80=94 > which is (I guess) the intention of the draft we=E2=80=99re discussing he= re. *If* > we conclude that none of the options that are presented using existing > technology are suitable, then potentially then we can look at new solutio= ns. > > If my reading of your mail is completely whacky, then please ignore the > above - and a clarifying example would be greatly appreciated. > > thx, > r. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --089e0122a754e913d004fef6331c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rob,

I see your interpretation and where it could = be confusing. You have clearly went beyond my boldest intentions :)=C2=A0

> From what I comprehend, you are saying that we define=C2=A0
> that a single SID maps to N labels.

Nope. That is perhaps key difference.=C2=A0
=

My proposal is that no= de advertises block of Node-SIDs which in turn map 1:1 to MPLS labels. The = block of Node-SIDs as as big as largest expected number of parallel links.= =C2=A0
/* There is no harm in wrong estimation as simply you will jus= t readvertise larger or smaller block */
While this could be accomplished today and may work fine in nu= mber of deployments as is there is clear opportunity for optimization. That= say that SID block can be represented as prefix so naturally corresponding= to it MPLS labels.=C2=A0
That said there are two things missing ...=C2=A0
<= div class=3D"gmail_default" style>
* fundamental the SR= =C2=A0architecture=C2=A0does not=C2=A0accommodate=C2=A0that
* MPLS data plane can be optimized to= reduce number of LFIB entries.

And that's it. How you use it see= ms just natural both on ingress as well as on the transit nodes.
=
Best,
r.






On Thu, Jul 24, = 2014 at 8:31 PM, Rob Shakir <rjs@rob.sh> wrote:
Hi Robert,

On 24 Jul 2014, at 03:21, Robert Raszuk <robert@raszuk.net> wrote:

>
> Therefor an alternative of using any form of entropy labels in data pl= ane all together would be to allocate a SID blocks (say 64 or 128 wide) and= allow SPRING header imposition to use such pools of SIDs per group of flow= s to effectively allow for efficient load balancing in the network.

Sorry, maybe I=E2=80=99m missing something here, but I found your mes= sage a little cryptic.

>From what I comprehend, you are saying that we define that a single SID map= s to N labels. These labels are split somehow into a =E2=80=9Cforwarding=E2= =80=9D and =E2=80=9Chash=E2=80=9D value. Simplistically, this could say tha= t we have the first 12 bits as the =E2=80=9Cforwarding=E2=80=9D and the bot= tom 8 as the =E2=80=9Chash=E2=80=9D value.

e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), anything t= hat is in the range 0b0000010100000000000 (10240) - 0b0000010100011111111 (= 10495) has the same forwarding behaviour, but the last 8 bits are used to h= ash (allowing 256 different hash-able objects).

If I understood right - then this seems to have a number of challenges to m= e:

- For Node-SIDs, we now must sterilise the SRGB to be as wide as (number of= required entries)*(number of hash-able objects required) - which means tha= t we must be able to determine a label block that can be used for this.
- We reduce the size of the label space from 20-bits to a smaller value - t= his might be a material concern in cases where we have many other labels th= at are allocated on a device (per-prefix label allocation within an L3VPN e= nvironment that has many prefixes might be a concern?).
- We need every device in the network to comprehend this new format of labe= l allocation and imposition - such that we do not increase the number of fo= rwarding entries that are required (as Stephane and Kireeti have observed).= This is problematic where we have limited LFIB already since instead of pr= ogramming a number of LFIB entries O(the number of labelled endpoints) then= we instead need to have O(number of labelled endpoints * number of hashabl= e objects).

Equally, I think the assertion that you have made is that deeper EL is not = =E2=80=9Ceasily supported by most of [today=E2=80=99s] shipping routers=E2= =80=9D. I think that we need to determine whether this is really the case = =E2=80=94 given that MPLS WG has standardised EL we need to figure *why* a = change from this is required =E2=80=94 which is (I guess) the intention of = the draft we=E2=80=99re discussing here. *If* we conclude that none of the = options that are presented using existing technology are suitable, then pot= entially then we can look at new solutions.

If my reading of your mail is completely whacky, then please ignore the abo= ve - and a clarifying example would be greatly appreciated.

thx,
r.

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

--089e0122a754e913d004fef6331c-- From nobody Thu Jul 24 13:34:30 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E91B27D7; Thu, 24 Jul 2014 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5dzgFgWxOlm; Thu, 24 Jul 2014 13:34:25 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6089C1A03BD; Thu, 24 Jul 2014 13:34:25 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so6941578igb.8 for ; Thu, 24 Jul 2014 13:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jW2U0WyUqUCGQFJPbQMM+t/+OAJORm2zR1KJrHz8RhU=; b=rsTtOMAYWNkk2nVv4OKv2KnVWBFXyCnVU3SX0+RcxL8EoHRnb+V/yQWanVtaAyuf6H IkR7PyfsXTvUAR6LspsE1Rbbkdl9y/aKM1DPoF+zzLy1HwrUN5cFstRxdDQbetwvBSZE /J66E6NGY7xK5fHRELWUeTQAUltBmWmQa5O2/2YBywvS+6oFoViDM2izc/1SPi1cZ81y D4hv9enuqe9W6y6VI2J2oypxTrWdt/Ad3hOGpb0BOYKOADS/KVOLek1n54vdiGX2bpkB Ae4PqTg+ZfJTWFCbJpYPKWqeV61H7aR/O7M5X6adxDtmNiwUY1atFyHLYAMzg/PAYrI0 jq4g== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr15310598icb.97.1406234064675; Thu, 24 Jul 2014 13:34:24 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Thu, 24 Jul 2014 13:34:24 -0700 (PDT) In-Reply-To: <31300_1406223555_53D144C3_31300_12346_1_9E32478DFA9976438E7A22F69B08FF9205D6CF@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <083ECD6F-D7B5-4AFC-8066-19BD2B7E563B@juniper.net> <23003_1406220375_53D13857_23003_12993_1_9E32478DFA9976438E7A22F69B08FF9205D5B6@OPEXCLILM34.corporate.adroot.infra.ftgroup> <10232_1406221553_53D13CF1_10232_3488_1_9E32478DFA9976438E7A22F69B08FF9205D615@OPEXCLILM34.corporate.adroot.infra.ftgroup> <31300_1406223555_53D144C3_31300_12346_1_9E32478DFA9976438E7A22F69B08FF9205D6CF@OPEXCLILM34.corporate.adroot.infra.ftgroup> Date: Thu, 24 Jul 2014 22:34:24 +0200 X-Google-Sender-Auth: P-L6OVE26hG3i0ehdxv3iNWk0_M Message-ID: From: Robert Raszuk To: "" Content-Type: multipart/alternative; boundary=001a113328f2e568cf04fef66161 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/2mepxTbzCCbOMc7iF-Rqu8s5vq4 Cc: Kireeti Kompella , "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:34:28 -0000 --001a113328f2e568cf04fef66161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > We already know how to encode label offset. > > Are you referring to Segment Index as offset of label base ? > =E2=80=8BNo.=E2=80=8B SI is already defined for different use. I am describ= ing general concept how we could indicate in 5 bits the number of significant (for forwarding) bits in MPLS label. > Using the same encoding you can treat offset value as number of > significant bits within the 20 bit label. > > Could you give an example of lookup and forwarding structure for your > label range/label prefix ? I see something possible but I still have an > issue with the lookup structure. > =E2=80=8BThe lookup is trivial as there is no LPM needed. You simply do par= tial match on your mpls labels in the LFIB. thx, R. > > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Thursday, July 24, 2014 13:24 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Kireeti Kompella; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org > *Subject:* RE: [spring] SPRING MPLS and Entropy Label > > > > Hi, > > That is also solved problem ;) > > We already know how to encode label offset. Using the same encoding you > can treat offset value as number of significant bits within the 20 bit > label. > > We do not need to extend this to current label use cases. Hence there is > no issue with backwards compatibility. > > Very basic and simple ;) > > Cheers, > R. > > On Jul 24, 2014 7:05 PM, wrote: > > Robert, > > > > From a practical point of view , how do you represent such MPLS label > range with a prefix ? > > [70, 170] > > [17, 69] > > > > MPLS was not designed for =E2=80=9Clabel aggregation=E2=80=9D scheme =E2= =80=A6 > > Or we need to change of labels are allocated from the label space for all > label consumers =E2=80=A6 to permit this aggregation. > > > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Thursday, July 24, 2014 12:54 > *To:* LITKOWSKI Stephane SCE/IBNF > *Cc:* Kireeti Kompella; mpls@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > Stephane, > > > > This has NOTHING TO DO with IPv6. I am not even sure based on what you > draw such strange conclusion .... > > > > I am talking pure about MPLS data plane (even without any IP above) and > how we can solve the load balancing problems. > > > > At min I expect for any discussion to be valid to discuss and compare all > options. > > > > Note also that SPRING does not use LDP so I am much less interested in > solving the LDP load balancing issues. > > > > Rgs, > > R. > > > > > > On Thu, Jul 24, 2014 at 6:46 PM, wrote: > > Robert, > > > > Talking MPLS, I don=E2=80=99t see a way to use MPLS label =E2=80=9Cprefix= =E2=80=9D =E2=80=A6 this is a > discussion we already had together. I think you are trying to sell IPv6 S= R > that I will unfortunately not buy again J > > > > *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Robert > Raszuk > *Sent:* Thursday, July 24, 2014 08:48 > *To:* Kireeti Kompella > *Cc:* mpls@ietf.org; spring@ietf.org; > draft-kini-mpls-spring-entropy-label@tools.ietf.org > *Subject:* Re: [spring] SPRING MPLS and Entropy Label > > > > Hi Kireeti, > > I quite disagree about the more state argument. > > If you treat mpls label as prefix with mask which is all this boils down > to there is no more state either in data or control plane. > > As to the point of not perfect load balancing it all depends on your hash > function. If you always advertise at least as big block as you have max > parallel links on any interface you should be fine. > > Best , > R. > > On Jul 24, 2014 2:12 PM, "Kireeti Kompella" wrote: > > Hi Robert, > > > > On Jul 24, 2014, at 03:21 , Robert Raszuk wrote: > > > > Therefor an alternative of using any form of entropy labels in data plane > all together would be to allocate a SID blocks (say 64 or 128 wide) and > allow SPRING header imposition to use such pools of SIDs per group of flo= ws > to effectively allow for efficient load balancing in the network. > > > > We=E2=80=99re rehashing (pun unintended) the entropy label discussion. > > > > Before we settled on entropy labels the way we did, we discussed > advertising label blocks in LDP. There are two problems: > > a) as Stephane mentions, ELs are stateless, but pools of SIDs impose more > state in the forwarding plane (and to some extent, in the control plane). > > b) if you use small blocks, you get uneven load balancing; if you use > large blocks, you blow up the state more. > > > > Kireeti > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --001a113328f2e568cf04fef66161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

> We already kn= ow how to encode label offset.

Are you referring to Segment Index as offset= =C2=A0 of label base ?


=E2=80=8BNo.=E2=80=8B SI is already defined for different use. I am describ= ing general concept how we could indicate in 5 bits the number of significa= nt (for forwarding) bits in MPLS label.=C2=A0

=C2=A0> Using the same encoding you can treat offset value as number of signif= icant bits within the 20 bit label.

Could you give an example =C2=A0of lookup and = forwarding structure for your label range/label prefix ? I see something po= ssible but I still have an issue with the lookup structure.

=


=E2=80=8BThe loo= kup is trivial as there is no LPM needed. You simply do partial match on yo= ur mpls labels in the LFIB.

thx,
R.






=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 13:24
To: LITKOWSKI Stephane SCE/IBNF
Cc: Kireeti Kompella; spring@ietf.org; draft-kini-mpls-spring-entropy-la= bel@tools.ietf.org; = mpls@ietf.org
Subject: RE: [spring] SPRING MPLS and Entropy Label

=C2=A0

Hi,

That is also solved problem ;)

We already know how to encode label offset. Using the same encoding you = can treat offset value as number of significant bits within the 20 bit labe= l.

We do not need to extend this to current label use cases. Hence there is= no issue with backwards compatibility.

Very basic and simple ;)

Cheers,
R.

On Jul 24, 2014 7:05 PM, <stephane.litkowski@orange.com> wrote:

Robert,<= /u>

=C2=A0

From a practical point of= view , how do=C2=A0 you represent such MPLS label range with a prefix ?

[70, 170]

[17, 69]=

=C2=A0

MPLS was not designed for= =E2=80=9Clabel aggregation=E2=80=9D scheme =E2=80=A6<= /p>

Or we need to change of l= abels are allocated from the label space for all label consumers =E2=80=A6 = to permit this aggregation.

=C2=A0

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 12:54
To: LITKOWSKI Stephane SCE/IBNF
Cc: Kireeti Kompella; mpls@ietf.org; spring@ietf.org; <= a href=3D"mailto:draft-kini-mpls-spring-entropy-label@tools.ietf.org" targe= t=3D"_blank"> draft-kini-mpls-spring-entropy-label@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label=

=C2=A0

= Stephane,

= =C2=A0

= This has NOTHING TO DO with IPv6. I am not even sure based on what you draw= such strange conclusion ....=C2=A0

= =C2=A0

= I am talking pure about MPLS data plane (even without any IP above) and how= we can solve the load balancing problems.=C2=A0

= =C2=A0

= At min I expect for any discussion to be valid to discuss and compare all o= ptions.=C2=A0

= =C2=A0

= Note also that SPRING does not use LDP so I am much less interested in solv= ing the LDP load balancing issues.=C2=A0

= =C2=A0

= Rgs,

= R.

= =C2=A0

=C2=A0<= /p>

On Thu, Jul 24, 2014 at 6:46 PM, <stephane.litkowski@oran= ge.com> wrote:

Robert,<= /u>

=C2=A0

Talking MPLS, I don=E2=80= =99t see a way to use MPLS label =E2=80=9Cprefix=E2=80=9D =E2=80=A6 this is= a discussion we already had together. I think you are trying to sell IPv6 SR that I will unfortunately= not buy again J

=C2=A0

From: spring [= mailto:spring-= bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 24, 2014 08:48
To: Kireeti Kompella
Cc: mpls@ietf.org= ; spring@ietf.org; draft-kini-mpls-spring-entropy-label@tools.ietf.org
Subject: Re: [spring] SPRING MPLS and Entropy Label=

=C2=A0

Hi Kireeti,

I quite disagree about the more state argument.

If you treat mpls label as prefix with mask which is all this boils down= to there is no more state either in data or control plane.

As to the point of not perfect load balancing it all depends on your has= h function. If you always advertise at least as big block as you have max p= arallel links on any interface you should be fine.

Best ,
R.

On Jul 24, 2014 2:12 PM, "Kireeti Kompella"= ; <kireeti@juni= per.net> wrote:

Hi Robert,

=C2=A0

On Jul 24, 2014, at 03:21 , Robert Raszuk <robert@raszuk.net> = wrote:

=C2=A0<= /p>

= Therefor an alternative of using any form of entropy labels in data plane a= ll together would be to allocate a SID blocks (say 64 or 128 wide) and allow SPRING header imposition to use such pools of SIDs per group of = flows to effectively allow for efficient load balancing in the network.

=C2=A0

We=E2=80=99re rehashing (pun unintended) the entropy= label discussion.

=C2=A0

Before we settled on entropy labels the way we did, = we discussed advertising label blocks in LDP. =C2=A0There are two problems:=

a) as Stephane mentions, ELs are stateless, but pool= s of SIDs impose more state in the forwarding plane (and to some extent, in= the control plane).

b) if you use small blocks, you get uneven load bala= ncing; if you use large blocks, you blow up the state more.

=C2=A0

Kireeti

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.

=C2=A0

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--001a113328f2e568cf04fef66161-- From nobody Fri Jul 25 08:44:42 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3D31A03A6; Fri, 25 Jul 2014 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOClUs-0uWjh; Fri, 25 Jul 2014 08:44:37 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB931A02EC; Fri, 25 Jul 2014 08:44:35 -0700 (PDT) Received: from [31.133.183.226] (helo=dhcp-b7e2.meeting.ietf.org) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XAhfb-0002NA-Um; Fri, 25 Jul 2014 16:44:32 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_66F2A3F9-0623-40ED-892E-03E4F525E8AB" From: Rob Shakir In-Reply-To: Date: Fri, 25 Jul 2014 11:44:26 -0400 Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7VpNIX3dlcjeqWTBzsOju6QWDHg Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:44:39 -0000 --Apple-Mail=_66F2A3F9-0623-40ED-892E-03E4F525E8AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Robert, On 24 Jul 2014, at 16:21, Robert Raszuk wrote: > I see your interpretation and where it could be confusing. You have = clearly went beyond my boldest intentions :)=20 Thanks for the clarification. > > =46rom what I comprehend, you are saying that we define=20 > > that a single SID maps to N labels. >=20 > Nope. That is perhaps key difference.=20 >=20 > My proposal is that node advertises block of Node-SIDs which in turn = map 1:1 to MPLS labels. The block of Node-SIDs as as big as largest = expected number of parallel links.=20 Operationally =97 this doesn=92t seem ideal to me. AIUI, If we have some = forwarding issue between two LSRs, then we might end up with partial = reachability if a subset of the paths do not have correct LFIB entries = throughout the network. It introduces a requirement, where failure = detection is required, to run N different OAM probes to be able to = monitor reachability (one for each Node-SID assigned to the remote = device - even in cases where we have 1 available path). I think the question for the MPLS WG here is whether there is any = appetite to introduce a new means by which entropy in MPLS networks is = introduced. We already have Entropy Label which has been published and = implemented. The question to me seems to be why we need anything else. = Fewer solutions seems optimal :-) Cheers, r. > Best, > r. >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir wrote: > Hi Robert, >=20 > On 24 Jul 2014, at 03:21, Robert Raszuk wrote: >=20 > > > > Therefor an alternative of using any form of entropy labels in data = plane all together would be to allocate a SID blocks (say 64 or 128 = wide) and allow SPRING header imposition to use such pools of SIDs per = group of flows to effectively allow for efficient load balancing in the = network. >=20 > Sorry, maybe I=92m missing something here, but I found your message a = little cryptic. >=20 > =46rom what I comprehend, you are saying that we define that a single = SID maps to N labels. These labels are split somehow into a =93forwarding=94= and =93hash=94 value. Simplistically, this could say that we have the = first 12 bits as the =93forwarding=94 and the bottom 8 as the =93hash=94 = value. >=20 > e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), = anything that is in the range 0b0000010100000000000 (10240) - = 0b0000010100011111111 (10495) has the same forwarding behaviour, but the = last 8 bits are used to hash (allowing 256 different hash-able objects). >=20 > If I understood right - then this seems to have a number of challenges = to me: >=20 > - For Node-SIDs, we now must sterilise the SRGB to be as wide as = (number of required entries)*(number of hash-able objects required) - = which means that we must be able to determine a label block that can be = used for this. > - We reduce the size of the label space from 20-bits to a smaller = value - this might be a material concern in cases where we have many = other labels that are allocated on a device (per-prefix label allocation = within an L3VPN environment that has many prefixes might be a concern?). > - We need every device in the network to comprehend this new format of = label allocation and imposition - such that we do not increase the = number of forwarding entries that are required (as Stephane and Kireeti = have observed). This is problematic where we have limited LFIB already = since instead of programming a number of LFIB entries O(the number of = labelled endpoints) then we instead need to have O(number of labelled = endpoints * number of hashable objects). >=20 > Equally, I think the assertion that you have made is that deeper EL is = not =93easily supported by most of [today=92s] shipping routers=94. I = think that we need to determine whether this is really the case =97 = given that MPLS WG has standardised EL we need to figure *why* a change = from this is required =97 which is (I guess) the intention of the draft = we=92re discussing here. *If* we conclude that none of the options that = are presented using existing technology are suitable, then potentially = then we can look at new solutions. >=20 > If my reading of your mail is completely whacky, then please ignore = the above - and a clarifying example would be greatly appreciated. >=20 > thx, > r. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >=20 --Apple-Mail=_66F2A3F9-0623-40ED-892E-03E4F525E8AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Robert,

On 24 Jul 2014, at 16:21, Robert Raszuk <robert@raszuk.net> = wrote:

I see your = interpretation and where it could be confusing. You have clearly went = beyond my boldest intentions = :) 

Thanks for the = clarification.

> =46rom what I comprehend, you are saying that we = define 
> that a single SID maps to N = labels.

Nope. That is perhaps key = difference. 

My proposal is that node advertises block of Node-SIDs which = in turn map 1:1 to MPLS labels. The block of Node-SIDs as as big as = largest expected number of parallel links. 

Operationally =97 this doesn=92t = seem ideal to me. AIUI, If we have some forwarding issue between two = LSRs, then we might end up with partial reachability if a subset of the = paths do not have correct LFIB entries throughout the network. It = introduces a requirement, where failure detection is required, to run N = different OAM probes to be able to monitor reachability (one for each = Node-SID assigned to the remote device - even in cases where we have 1 = available path).

I think the question for the = MPLS WG here is whether there is any appetite to introduce a new means = by which entropy in MPLS networks is introduced. We already have Entropy = Label which has been published and implemented. The question to me seems = to be why we need anything else. Fewer solutions seems optimal = :-)

Cheers,
r.



Best,
r.






On Thu, Jul 24, 2014 at 8:31 PM, Rob Shakir <rjs@rob.sh> wrote:
Hi Robert,

On 24 Jul 2014, at 03:21, Robert Raszuk <robert@raszuk.net> wrote:

>
> Therefor an alternative of using any form of entropy labels in data = plane all together would be to allocate a SID blocks (say 64 or 128 = wide) and allow SPRING header imposition to use such pools of SIDs per = group of flows to effectively allow for efficient load balancing in the = network.

Sorry, maybe I=92m missing something here, but I found your = message a little cryptic.

=46rom what I comprehend, you are saying that we define that a single = SID maps to N labels. These labels are split somehow into a =93forwarding=94= and =93hash=94 value. Simplistically, this could say that we have the = first 12 bits as the =93forwarding=94 and the bottom 8 as the =93hash=94 = value.

e.g. Node A advertises an Adj-SID with value 0b00000101000 (40), = anything that is in the range 0b0000010100000000000 (10240) - = 0b0000010100011111111 (10495) has the same forwarding behaviour, but the = last 8 bits are used to hash (allowing 256 different hash-able = objects).

If I understood right - then this seems to have a number of challenges = to me:

- For Node-SIDs, we now must sterilise the SRGB to be as wide as (number = of required entries)*(number of hash-able objects required) - which = means that we must be able to determine a label block that can be used = for this.
- We reduce the size of the label space from 20-bits to a smaller value = - this might be a material concern in cases where we have many other = labels that are allocated on a device (per-prefix label allocation = within an L3VPN environment that has many prefixes might be a = concern?).
- We need every device in the network to comprehend this new format of = label allocation and imposition - such that we do not increase the = number of forwarding entries that are required (as Stephane and Kireeti = have observed). This is problematic where we have limited LFIB already = since instead of programming a number of LFIB entries O(the number of = labelled endpoints) then we instead need to have O(number of labelled = endpoints * number of hashable objects).

Equally, I think the assertion that you have made is that deeper EL is = not =93easily supported by most of [today=92s] shipping routers=94. I = think that we need to determine whether this is really the case =97 = given that MPLS WG has standardised EL we need to figure *why* a change = from this is required =97 which is (I guess) the intention of the draft = we=92re discussing here. *If* we conclude that none of the options that = are presented using existing technology are suitable, then potentially = then we can look at new solutions.

If my reading of your mail is completely whacky, then please ignore the = above - and a clarifying example would be greatly appreciated.

thx,
r.

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


= --Apple-Mail=_66F2A3F9-0623-40ED-892E-03E4F525E8AB-- From nobody Fri Jul 25 09:16:47 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432111A02D9; Fri, 25 Jul 2014 09:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtWvSOw1tFUG; Fri, 25 Jul 2014 09:16:41 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E856D1A0337; Fri, 25 Jul 2014 09:16:40 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so1032079igb.8 for ; Fri, 25 Jul 2014 09:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aoa+EfFgmEN+yD88szATKRfAOMzrtIS6GWNI02goQ0w=; b=oWBmLXVGPRQKgh6WrAD13m02NQ5sEsT11CO09ng5f7AOFj82HyhtMEyGBKhd5/2rqb G7p0QvtQzI+uPRESNQn+yYEReK+B1S3oPMtGYJ+nzXlak6gA5eD5DWLBDeNkt6jUpt7z 8IM56t4jl98U/xljlBf9LhLbV3X4d3F8BKVNFkAeceuSIFKTuBPqS/JXy2JIhLozYtVw bJD/qsb6ZQR/pdIkKa4y7n2P8FWe4CaOliinbymiQh6tITYXxJdbTt/QAjhk2uOENH83 kVL4WqamXhgY7Q+KIxS5JGlX+dtEAXFhpVc5Unj4IaX+b1lLYqhVraKr5Z7OdWShFntg jG1A== MIME-Version: 1.0 X-Received: by 10.42.240.20 with SMTP id ky20mr3978655icb.97.1406305000096; Fri, 25 Jul 2014 09:16:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Fri, 25 Jul 2014 09:16:39 -0700 (PDT) In-Reply-To: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> Date: Fri, 25 Jul 2014 18:16:39 +0200 X-Google-Sender-Auth: Tlqh-LVqmx6o_FVSW0z2CnBXXoU Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: multipart/alternative; boundary=001a113328f2fa07d504ff06e5e8 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/uWmoRgDkkJYSvDbNNPWqYlQm6tM Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:16:42 -0000 --001a113328f2fa07d504ff06e5e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi Rob,=E2=80=8B > =E2=80=8B > It introduces a requirement, where failure detection is required, to run = N > different OAM probes to be able to monitor reachability (one for each > Node-SID assigned to the remote device - even in cases where we have 1 > available path). > =E2=80=8BWhen you get today /24 IP prefix =E2=80=8Bdo you monitor reachabil= ity to all 255 host addresses within this prefix or to the next hop which advertised it ? Likewise when you get a block of SID monitoring OEM to the node which advertised it seems sufficient to me. I assume there is still IGP there and router_id or s-bfd. Comparing two options it seems that mpls hardware is to much faster support match on subset of MPLS label bits vs ability to look over long chain of labels for ELI/EL. I think the question for the MPLS WG here is whether there is any appetite > to introduce a new means by which entropy in MPLS networks is introduced. > We already have Entropy Label which has been published and implemented. T= he > question to me seems to be why we need anything else. Fewer solutions see= ms > optimal :-) > =E2=80=8BOf course fewer is better provided that: a) fewer works b) is architecturally sound Moreover SID/label block vs entropy labels is not apple to apple comparison. Former is just control plane solution, does not insert anything extra into each packet while latter is based on data plane modifications and new hardware support to either handle Eiffel Tower of label stack or tricks with search along the stack for ELI/EL tupel(s). Cheers, R. =E2=80=8B --001a113328f2fa07d504ff06e5e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi Rob,=E2=80=8B
=C2=A0
= =E2=80=8B
It introduces a requirement, where failure detection is req= uired, to run N different OAM probes to be able to monitor reachability (on= e for each Node-SID assigned to the remote device - even in cases where we = have 1 available path).

=E2=80=8BWhen you get today /24 IP prefix =E2=80=8Bdo you monitor rea= chability to all 255 host addresses within this prefix or to the next hop w= hich advertised it ?=C2=A0

Likewise when you= get a block of SID monitoring OEM to the node which advertised it seems su= fficient to me. I assume there is still IGP there and router_id or s-bfd.

Comparing two opt= ions it seems that mpls hardware is to much faster support match on subset = of MPLS label bits vs ability to look over long chain of labels for ELI/EL.=

I think the question for= the MPLS WG here is whether there is any appetite to introduce a new means= by which entropy in MPLS networks is introduced. We already have Entropy L= abel which has been published and implemented. The question to me seems to = be why we need anything else. Fewer solutions seems optimal :-)

=E2=80=8BOf course fewer is better provided that:

a) fewer works
b) is architecturally sound

Moreover SID/labe= l block vs entropy labels is not apple to apple comparison.=C2=A0

Former is just co= ntrol plane solution, does not insert anything extra into each packet while= latter is based on data plane modifications and new hardware support to ei= ther handle Eiffel Tower of label stack or tricks with search along the sta= ck for ELI/EL tupel(s).

Cheers,
=
R.
=E2=80=8B
--001a113328f2fa07d504ff06e5e8-- From nobody Sat Jul 26 15:04:53 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628C01A02D1; Sat, 26 Jul 2014 15:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoGR3F76hJn8; Sat, 26 Jul 2014 15:04:48 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D083C1A0601; Sat, 26 Jul 2014 15:04:46 -0700 (PDT) Received: from [199.119.128.122] (helo=[10.0.1.35]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XBA54-0004JJ-Hg; Sat, 26 Jul 2014 23:04:42 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D2A66BA-48D6-46ED-8A93-C7BE2CF1FCB4" From: Rob Shakir In-Reply-To: Date: Sat, 26 Jul 2014 18:04:37 -0400 Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/sTjW03XWVXJRXqmQtu9wAixeLKU Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 22:04:50 -0000 --Apple-Mail=_9D2A66BA-48D6-46ED-8A93-C7BE2CF1FCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, On 25 Jul 2014, at 12:16, Robert Raszuk wrote: > =E2=80=8BHi Rob,=E2=80=8B > =20 > =E2=80=8B It introduces a requirement, where failure detection is = required, to run N different OAM probes to be able to monitor = reachability (one for each Node-SID assigned to the remote device - even = in cases where we have 1 available path). >=20 > =E2=80=8BWhen you get today /24 IP prefix =E2=80=8Bdo you monitor = reachability to all 255 host addresses within this prefix or to the next = hop which advertised it ?=20 >=20 > Likewise when you get a block of SID monitoring OEM to the node which = advertised it seems sufficient to me. I assume there is still IGP there = and router_id or s-bcd. I don=E2=80=99t think this is analogous =E2=80=94 there is only one = forwarding entry for a /24 if it has a single next-hop. With the = multiple SIDs (and 1:1 SID to label mapping) then there will be multiple = LFIB entries. BR, r. --Apple-Mail=_9D2A66BA-48D6-46ED-8A93-C7BE2CF1FCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Robert,

On 25 Jul 2014, at 12:16, Robert Raszuk <robert@raszuk.net> = wrote:

=E2=80=8BHi = Rob,=E2=80=8B
 
=E2=80=8B It introduces a requirement, where failure detection is required, to = run N different OAM probes to be able to monitor reachability (one for = each Node-SID assigned to the remote device - even in cases where we = have 1 available path).

=E2=80=8BWhe= n you get today /24 IP prefix =E2=80=8Bdo you monitor reachability to = all 255 host addresses within this prefix or to the next hop which = advertised it ? 

Likewise = when you get a block of SID monitoring OEM to the node which advertised = it seems sufficient to me. I assume there is still IGP there and = router_id or = s-bcd.

I = don=E2=80=99t think this is analogous =E2=80=94 there is only one = forwarding entry for a /24 if it has a single next-hop. With the = multiple SIDs (and 1:1 SID to label mapping) then there will be multiple = LFIB = entries.

BR,
r.


= --Apple-Mail=_9D2A66BA-48D6-46ED-8A93-C7BE2CF1FCB4-- From nobody Sat Jul 26 15:07:42 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4A1A07A1; Sat, 26 Jul 2014 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja1yLA_v0Ulo; Sat, 26 Jul 2014 15:07:30 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32111A0769; Sat, 26 Jul 2014 15:07:29 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id x19so4979375ier.6 for ; Sat, 26 Jul 2014 15:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xhex//3FqGbvfuHp0dfho7J8qJm6EyP6MQTXblgxYp8=; b=STOXJe612NOH2v8TyRl8oj77gBwO3OFo3evbYBT+Un9glGNhG1TD8EdeQiWrIhM1hs S6pC4C4rtrpPVTe8CBG6HiJxAq2zui3s5UVnfFAaTXV7v9JpmjwhBEEvOBn+4cT7bp+l btXOPyf555LMaGSwT2oF7IqjYZZ6iLtCNcoRt2FRfOX1x7CWIaxky9ot3uaUNbdIvxFk JE7FWmRtpOKN4+HtYbwaXxMIaTP0nisY8xffJm7JDmx+I/6Kx/o3EVIlt6om2C0iO+uO YUxY3IWJes6wF0U0WJQvbls66D/gM89Z6LlXP+7ORSAPCHyy2ith6A869Q6gjXImAZho n/Og== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr17936399igx.9.1406412449341; Sat, 26 Jul 2014 15:07:29 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Sat, 26 Jul 2014 15:07:29 -0700 (PDT) In-Reply-To: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> Date: Sun, 27 Jul 2014 00:07:29 +0200 X-Google-Sender-Auth: PqtjvJiFOiYgXI3vk7jWRI9TDKY Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: multipart/alternative; boundary=089e0122a754736a6e04ff1fea83 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/yHnRUuBWajrrxFe4Y6ByID3zK6Q Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 22:07:32 -0000 --089e0122a754736a6e04ff1fea83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I don=E2=80=99t think this is analogous =E2=80=94 there is only one forwa= rding entry for a > /24 if it has a single next-hop. With the multiple SIDs (and 1:1 SID to > label mapping) then there will be multiple LFIB entries. > =E2=80=8BNope. The entire idea is to have a single LFIB entry as well. Best, r. =E2=80=8B --089e0122a754736a6e04ff1fea83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I = don=E2=80=99t think this is analogous =E2=80=94 there is only one forwardin= g entry for a /24 if it has a single next-hop. With the multiple SIDs (and = 1:1 SID to label mapping) then there will be multiple LFIB entries.

= =E2=80=8BNope.=C2=A0

The entire idea is to have a single LFIB = entry as well.=C2=A0

Best,
r.

=E2=80=8B

--089e0122a754736a6e04ff1fea83-- From nobody Sat Jul 26 15:14:31 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351991A0769; Sat, 26 Jul 2014 15:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmiSVcezsa0y; Sat, 26 Jul 2014 15:14:25 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D421A0601; Sat, 26 Jul 2014 15:14:23 -0700 (PDT) Received: from [199.119.128.122] (helo=[10.0.1.35]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XBAER-0004KQ-3F; Sat, 26 Jul 2014 23:14:23 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_433BD40B-196B-487E-8C69-680CAAA90006" From: Rob Shakir In-Reply-To: Date: Sat, 26 Jul 2014 18:14:14 -0400 Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/dWGuOkLXfPjWbOSuhFZSHdGMtZ0 Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 22:14:28 -0000 --Apple-Mail=_433BD40B-196B-487E-8C69-680CAAA90006 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 26 Jul 2014, at 18:07, Robert Raszuk wrote: > I don=E2=80=99t think this is analogous =E2=80=94 there is only one = forwarding entry for a /24 if it has a single next-hop. With the = multiple SIDs (and 1:1 SID to label mapping) then there will be multiple = LFIB entries. >=20 > =E2=80=8BNope.=20 >=20 > The entire idea is to have a single LFIB entry as well.=20 Again, I=E2=80=99m lost. :-( Perhaps you can expand on how an LSR programs its LFIB such that it has = multiple labels matched with a single entry please? I=E2=80=99m = struggling to comprehend how this fits into the existing = implementations, or can be realised without requiring some = forwarding/entropy split of the 20-bit label as I described before. Kind regards, r. --Apple-Mail=_433BD40B-196B-487E-8C69-680CAAA90006 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Jul 2014, at 18:07, Robert = Raszuk <robert@raszuk.net> = wrote:

I don=E2=80=99t think this is analogous = =E2=80=94 there is only one forwarding entry for a /24 if it has a = single next-hop. With the multiple SIDs (and 1:1 SID to label mapping) = then there will be multiple LFIB entries.

=E2=80=8BNope. 

The entire idea is to have a single LFIB = entry as = well. 

Again= , I=E2=80=99m lost. :-(

Perhaps you can expand = on how an LSR programs its LFIB such that it has multiple labels matched = with a single entry please? I=E2=80=99m struggling to comprehend how = this fits into the existing implementations, or can be realised without = requiring some forwarding/entropy split of the 20-bit label as I = described before.

Kind = regards,
r.

= --Apple-Mail=_433BD40B-196B-487E-8C69-680CAAA90006-- From nobody Sat Jul 26 15:26:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA131A03FF; Sat, 26 Jul 2014 15:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDJfrPslgMMN; Sat, 26 Jul 2014 15:26:02 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F6C1A00FC; Sat, 26 Jul 2014 15:26:02 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id rp18so4940598iec.26 for ; Sat, 26 Jul 2014 15:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UhQDSkaQve2ypfnliSbO1zT0qglwwPnqKtZgGekjrUs=; b=yQ3rgcnf1oeNI443vbBnpa9fmOKjxlRWAT8lZnMVndSSzn9/HFSfvr64y3CQuPvodB lj5Xc5vFVcy/AYu8PC3VIdQNYi8TNYLCQGKyAPqNiVeElB5Q1RGPFZTy4Lsfh+zJVjqq Xlez0OePH+NBJAu0SpHfrlEkGZ2AWhQ8w4iPIrDk3RSkyGvxO3Mdo6ZvVl7XK2ObXeIs 4nCXWzwaXRrpB/2hvXtu2tCNm+iZzAuidqk4cimRT1YIn+OWme3iJ82xX20I4pE30kQl ERBub/x95+o6HXySxafsEfex/6gSXl83pJSrxPvt2KyXa4LSvsrsD0yHFKTKa04YpsbF le7g== MIME-Version: 1.0 X-Received: by 10.50.62.80 with SMTP id w16mr17635042igr.21.1406413562125; Sat, 26 Jul 2014 15:26:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Sat, 26 Jul 2014 15:26:01 -0700 (PDT) In-Reply-To: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> Date: Sun, 27 Jul 2014 00:26:01 +0200 X-Google-Sender-Auth: lQWF5UFBl9BUwpZaOmsqE4ySs6o Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: multipart/alternative; boundary=047d7bdc0aeac7237104ff202c5e Archived-At: http://mailarchive.ietf.org/arch/msg/spring/vJ55g-v5SIFyPl1cxeluqbVs6Cw Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 22:26:04 -0000 --047d7bdc0aeac7237104ff202c5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Perhaps you can expand on how an LSR programs its LFIB such that it has > multiple labels matched with a single entry please? > =E2=80=8BWhen you install a label to LFIB you also pass its depth ie number= of significant bits to match on. Hardware will treat the remaining bits as "do not care". That is pretty basic logical function for any match operation. At least I am quite sure it is much simpler then any other form of search for ELI/EL within the SR deep stack :) I=E2=80=99m struggling to comprehend how this fits into the existing > implementations, or can be realised without requiring some > forwarding/entropy split of the 20-bit label as I described before. > =E2=80=8BThe split I have in mind is passed explicitiely in control plane. = So there is no additional logic required for it. =E2=80=8B =E2=80=8BNow you may rightfully state that this requires an upgrade. Well t= rue but any alternative discussed here requires an upgrade as well. Moreover even support of SR requires an upgrade :) Control plane vs data plane .. EL based solution requires both day one. Label mask does not strictly require any data plane change during the transition period as it could install all atomic labels till the mask support in LFIB is available later. Cheers, R.=E2=80=8B --047d7bdc0aeac7237104ff202c5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Perhaps= you can expand on how an LSR programs its LFIB such that it has multiple l= abels matched with a single entry please?

=E2=80=8BW= hen you install a label to LFIB you also pass its depth ie number of signif= icant bits to match on.=C2=A0

Hardware will tre= at the remaining bits as "do not care". That is pretty basic logi= cal function for any match operation.=C2=A0

At least I am qui= te sure it is much simpler then any other form of search for ELI/EL within = the SR deep stack :)

I=E2=80=99m struggling to comprehend how this fits into t= he existing implementations, or can be realised without requiring some forw= arding/entropy split of the 20-bit label as I described before.

=E2=80= =8BThe split I have in mind is passed explicitiely in control plane. So the= re is no additional logic required for it. =E2=80=8B

=E2=80=8BNow you may rightfully stat= e that this requires an upgrade. Well true but any alternative discussed he= re requires an upgrade as well. Moreover even support of SR requires an upg= rade :)

Control plane vs = data plane .. EL based solution requires both day one. Label mask does not = strictly require any data plane change during the transition period as it c= ould install all atomic labels till the mask support in LFIB is available l= ater.

Cheers,
R.=E2=80=8B

--047d7bdc0aeac7237104ff202c5e-- From nobody Mon Jul 28 03:58:17 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B0D1A03CB; Mon, 28 Jul 2014 03:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak7RD_N1xQXm; Mon, 28 Jul 2014 03:58:10 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B74C1A015B; Mon, 28 Jul 2014 03:58:09 -0700 (PDT) Received: from [109.144.194.84] (helo=[10.210.201.184]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XBid4-0006v3-TS; Mon, 28 Jul 2014 11:58:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Rob Shakir In-Reply-To: Date: Mon, 28 Jul 2014 11:58:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/spring/xLf9XNlWHTvgENECj87FllMAsBc Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:58:16 -0000 Hi Robert, On 26 Jul 2014, at 23:26, Robert Raszuk wrote: > Perhaps you can expand on how an LSR programs its LFIB such that it = has multiple labels matched with a single entry please? >=20 > =E2=80=8BWhen you install a label to LFIB you also pass its depth ie = number of significant bits to match on.=20 >=20 > Hardware will treat the remaining bits as "do not care". That is = pretty basic logical function for any match operation.=20 rjs> So, this is exactly akin to the description I gave of partitioning = the label space - since it requires one to sterilise some of the label = space (N-bits are now significant for forwarding, with the remaining = (20-M) being used for entropy). > At least I am quite sure it is much simpler then any other form of = search for ELI/EL within the SR deep stack :) rjs> The look-up logic has to change somewhat for the data-plane. = Particularly as: - We need to check whether the top-most label is within the block of = labels that we are using for this function. - If it is, we do a lookup based on the first N-bits to determine the = next-hop. - if it=E2=80=99s not, we need to do a lookup based on the = entire label. - If this was in the entropy block we determine the OIF by matching this = next-hop along with the hash of the remaining (20-N) bits. - else we fallback to the existing hashing procedures. Alternatively, we need to: - Look-up the next-hop based on the top-most label. - If the ELI is in the label stack, take the following label as the EL. - Determine the OIF based on the next-hop and the EL value received. - if the EL is not present, then hash based on existing = procedures. Is the former =E2=80=9Cmuch simpler=E2=80=9D? I am no hardware expert, = but I would say they seem roughly analogous in terms of decision process = that needs to be made - other than the latter needs visibility into more = of the packet (such that ELI/EL is included in the header that is = extracted).=20 It=E2=80=99s notable that the latter logic must be implemented anyway at = an LSR, because we have now standardised ELI/EL and it is implemented. > I=E2=80=99m struggling to comprehend how this fits into the existing = implementations, or can be realised without requiring some = forwarding/entropy split of the 20-bit label as I described before. >=20 > =E2=80=8BThe split I have in mind is passed explicitiely in control = plane. So there is no additional logic required for it. =E2=80=8B >=20 > =E2=80=8BNow you may rightfully state that this requires an upgrade. = Well true but any alternative discussed here requires an upgrade as = well. Moreover even support of SR requires an upgrade :) >=20 > Control plane vs data plane .. EL based solution requires both day = one. Label mask does not strictly require any data plane change during = the transition period as it could install all atomic labels till the = mask support in LFIB is available later. >=20 rjs> In smaller nodes (aggregation/access nodes) then this might have = significant impact, given LFIB limitations. If we need to have M*(number = of destination FECs) installed in the LFIB then this might bust some = limits. Whilst label mask is a potential solution, my view is that we should = continue to leverage the EL work already done by this WG. Kind regards, > Cheers, > R.=E2=80=8B >=20 From nobody Mon Jul 28 14:03:33 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611BF1A02AC; Mon, 28 Jul 2014 14:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNssa6EP6hFT; Mon, 28 Jul 2014 14:03:27 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD4B1A0217; Mon, 28 Jul 2014 14:03:27 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id tr6so7305910ieb.4 for ; Mon, 28 Jul 2014 14:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6H2ykF0noj150dS0IWEDh9mMvGUr0lB7famoGeDpwiE=; b=Uv4wM4artBMatYCyBSGbj673Q8IhpGTLqpDITAB20rqfxnbh9b6YQAi0DIOZt9QpWb eeLBMm7+roP1DpxPUhQhZNnMrrqOekU2FHnHU9CCyFDdmfF1Bk8Dv3ntUESRhlnCRiMq ewFdQ+fWAD2yNfRleK4QXeFbApGcfkooIQNinxfGy0st7u4XgIpQEfexgSVrw/kP3GeU d+sasSrL+S9bBjquGcS1rQUCkBSu6F9MElzWP6+/G6ijVbu98+IGoemkQjlCkQs89E2l GJQzsT58j6Ygf8U1gRgKRdWygz4ATeI2tFv0vqqoZq4OOEZw13hXAdgyCeQZvGUq09BJ kbMw== MIME-Version: 1.0 X-Received: by 10.50.61.195 with SMTP id s3mr13678926igr.29.1406581406594; Mon, 28 Jul 2014 14:03:26 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.128.99 with HTTP; Mon, 28 Jul 2014 14:03:26 -0700 (PDT) In-Reply-To: References: <5E87F378-9EE4-44BF-8001-E87A1B7BB169@rob.sh> <3378D800-2E02-45D0-BA47-4BEACAECC6F8@rob.sh> <820F3138-D28A-47C6-AB0B-27AB3466D65C@rob.sh> Date: Mon, 28 Jul 2014 23:03:26 +0200 X-Google-Sender-Auth: Tw8TPIDs8pL8kkm3GcWokrH1m78 Message-ID: From: Robert Raszuk To: Rob Shakir Content-Type: multipart/alternative; boundary=047d7bdc05f2167cfa04ff474165 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/ivx8Yi0rhq50lNbaE_bnKp7QSAc Cc: "mpls@ietf.org" , "spring@ietf.org" , "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] SPRING MPLS and Entropy Label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:03:28 -0000 --047d7bdc05f2167cfa04ff474165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > - We need to check whether the top-most label is within the block of > labels that we are using for this function. > - If it is, we do a lookup based on the first N-bits to determine the > next-hop. > - if it=E2=80=99s not, we need to do a lookup based on the entire= label. > =E2=80=8BNope. Sorry. We always do identical single lookup. It is that some entries in the LFIB have mask (read: do not care bits). There are no two lookups nor two tables etc ... That's it. =E2=80=8BTrivial= for anyone who has some min hardware design background :). Whilst label mask is a potential solution, my view is that we should > continue to leverage the EL work already done by this WG. > =E2=80=8BGreat. Go for it ! /* After all if we would have spend little cycles now and innovate tiny bit to improve MPLS data plane it would result in better operation and lasting longer .... ;-) */ Best, r.=E2=80=8B --047d7bdc05f2167cfa04ff474165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
- We need to check whether the = top-most label is within the block of labels that we are using for this fun= ction.
- If it is, we do a lookup based on the first N-bits to determine the next-= hop.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - if it=E2=80=99s not, we need to do a lookup b= ased on the entire label.

=E2=80=8BNope. Sorry.=C2=A0

We always do iden= tical single lookup.=C2=A0

It is that some e= ntries in the LFIB have mask (read: do not care bits). There are no two loo= kups nor two tables etc ... That's it. =E2=80=8BTrivial for anyone who = has some min hardware design background :).=C2=A0


= Whilst label mask is a potential solution, my view is that we should contin= ue to leverage the EL work already done by this WG.

=E2=80=8BGreat. Go= for it !=C2=A0

/* After all if we would have spend littl= e cycles now and innovate tiny bit to improve MPLS data plane it would resu= lt in better operation and lasting longer .... ;-) */

Best,
r.=E2=80=8B

--047d7bdc05f2167cfa04ff474165-- From nobody Thu Jul 31 14:55:50 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998171A01C5; Thu, 31 Jul 2014 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pji0lUN28wv8; Thu, 31 Jul 2014 14:55:34 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77031A0191; Thu, 31 Jul 2014 14:55:33 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-5e-53da67ebe5bc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A9.C2.05330.BE76AD35; Thu, 31 Jul 2014 17:59:39 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 31 Jul 2014 17:55:27 -0400 From: Uma Chunduri To: Chris Bowers , "isis-wg@ietf.org" Thread-Topic: comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: Ac+tB/m1SgwPt+aOTIqniJ++F94cJQAAP0Yw Date: Thu, 31 Jul 2014 21:55:26 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> In-Reply-To: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F319D19eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn+7r9FvBBld2qFv8WO9qcfTQe1aL 4xd+MzoweyxZ8pPJ43rTVfYApigum5TUnMyy1CJ9uwSujKbmFsaCV7sYK9Yuf8zawHhoOWMX IyeHhICJRMPpdihbTOLCvfVsXYxcHEICRxklrqyYwAySEBJYziix52EsiM0moCfxcepPdhBb RMBXYv7NG2A2s4C6xLL9F1hAbGEBV4kzlz8A9XIA1bhJTO01gCg3kjg1oZ0NxGYRUJV48PQ/ E4jNCzSm8e0VJohVoRI/968Cq+EUCJO4fGIF2EhGoNu+n1rDBLFKXOLWk/lMEDcLSCzZc54Z whaVePn4HyuErSQxaek5Voj6fImvfesYIXYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg9yc2 CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3LTTcy2MQIjK9jEmy6Oxj3vLQ8xCjAwajEw7tA +FawEGtiWXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwpkXs2Hda aYb+78+vRUx27TEtfrtvyZ+pOus+LTVSkdjB83POoVbL8K6sqAaeizOOfNk1zaLsNn/e+zmH dbw+PnW7ZL5CXdJRsunG/euHNbcZL5LcFLJeo81R4qLf94Azwbe+R4j1CLo2pf/7a1U794Pl xfwJGoc2yV57vJf3yv7Dk/rEvRP2/VBiKc5INNRiLipOBADQ66oMkAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/spring/VTDFcTCblK3JDG8MITq82PwrUlg Cc: "spring@ietf.org" Subject: Re: [spring] comment on draft-ietf-isis-segment-routing-extensions-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:55:37 -0000 --_000_1B502206DFA0C544B7A60469152008633F319D19eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [CC'ed Spring WG] I agree with what Chris said below in principle. But all this should not be= obviously part of ISIS/IGP extensions WG documents.. Use cases for binding TLVs are explained in great details in 2 key documen= ts (had to shuffle through to get here) - 1. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertise= ment-05 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 IMO, both are very useful documents. It would be good to combine both of these and publish as a "spring " docum= ent and eventually it should progress there. AFAICT, Both ISIS and OSPF should refer the same eventually to get more cla= rity and use of binding TLVs described currently. -- Uma C. From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris Bowers Sent: Thursday, July 31, 2014 2:42 PM To: isis-wg@ietf.org Subject: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 All, The current text of draft-ietf-isis-segment-routing-extensions-02 does not = clearly explain the usage of the Binding TLV for advertising LSPs created u= sing other protocols. I would like to propose the following text to be inc= luded as section 2.5 . Thanks, Chris ---------------- 2.5 Binding TLV usage examples This section gives examples of using the Binding TLV to advertise SID/label= bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. It a= lso includes an example of advertising a context-id for egress node protect= ion. All of the examples assume that the Binding TLV weight=3D1 and metric= =3D100. 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with route= r-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [strict], 192.= 3.4.2 [strict]). R1 can advertise a locally significant label binding for t= his LSP (with label value=3D1099) using the following values and sub-TLVs = in the Binding TLV. Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length=3D3= 2, FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-TLV: metric=3D100 IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 2.5.2 Advertising an LDP LSP using the Binding TLV Assume that R5 has learned a FEC-label binding via LDP for FEC=3D10.8.8.8/3= 2. R5 can advertise a locally significant label binding for this LSP (with= label value=3D5099) using the following values and sub-TLVs in the Binding= TLV. Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length=3D3= 2, FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-TLV: metric=3D100 IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV Assume that R9 has used BGP labeled-unicast to learn a label binding for pr= efix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can advertise a l= ocally significant label binding for this LSP (with label value=3D7099) us= ing the following values and sub-TLVs in the Binding TLV. Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length=3D3= 2, FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric sub-TLV: metric=3D100 IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 2.5.4 Advertising a context-id for egress node protection using the Binding= TLV Assume that R22 is configured in the protector role to provide egress node = protection for R21 using context-id=3D10.0.0.21. R22 can advertise the lab= el associated with this context-id (with label value=3D8099) using the foll= owing values and sub-TLVs in the Binding TLV. Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length=3D3= 2, FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 ---------------- --_000_1B502206DFA0C544B7A60469152008633F319D19eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[CC’ed Spring WG]

 <= /p>

I agree with what Chris s= aid below in principle. But all this should not be obviously part of ISIS/I= GP extensions WG documents..

 <= /p>

Use  cases for bindi= ng TLVs are explained in great details in 2 key documents (had to shuffle t= hrough to get here) –

 <= /p>

1. = ;      http:/= /tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-05

2. = ;      http://tools.ietf.org/ht= ml/draft-gredler-spring-mpls-06

 <= /p>

IMO, both are very useful= documents.

It would be good  to= combine both of these and publish as a “spring ” document and = eventually it should progress there.

AFAICT, Both ISIS and OSP= F should refer the same eventually to get more clarity and use of binding T= LVs described currently.

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: Isis-wg = [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris Bowers
Sent: Thursday, July 31, 2014 2:42 PM
To: isis-wg@ietf.org
Subject: [Isis-wg] comment on draft-ietf-isis-segment-routing-extens= ions-02

 

All,

 

The current text of draft-ietf-isis-seg= ment-routing-extensions-02 does not clearly explain the usage of the Bindin= g TLV for advertising LSPs created using other protocols.  I would like to propose the following text to be included as section 2.5 .=

 

Thanks,

Chris

 

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

 

2.5 Binding TLV usage examples

 

This section gives examples of using th= e Binding TLV to advertise SID/label bindings associated with RSVP-TE, LDP,= and BGP labeled-unicast LSPs.  It also includes an example of advertising a context-id for egress node protection.  All of the e= xamples assume that the Binding TLV weight=3D1 and metric=3D100. 

 

2.5.1 Advertising an RSVP-TE LSP using = the Binding TLV

 

Assume that R1 has signaled an RSVP-TE = LSP to egress router (R4) with router-id=3D10.4.4.4, with ER0 =3D (192.1.2.= 2 [strict], 192.2.3.2 [strict], 192.3.4.2 [strict]). R1 can advertise a locally significant label binding for this LSP (with label val= ue=3D1099)  using the following values and sub-TLVs in the Binding TLV= . 

 

Binding-TLV: F-bit=3D0, M-bit=3D0, weig= ht=3D1, range=3D1, prefix length=3D32, FEC prefix=3D10.4.4.4

SID/Label Sub-TLV: label=3D1099

ERO Metric sub-TLV: metric=3D100

IPv4 ERO sub-TLV: L-bit=3D0, IPv4 addre= ss=3D192.1.2.2

IPv4 ERO sub-TLV: L-bit=3D0, IPv4 addre= ss=3D192.2.3.2

IPv4 ERO sub-TLV: L-bit=3D0, IPv4 addre= ss=3D192.3.4.2

 

2.5.2 Advertising an LDP LSP using the = Binding TLV

 

Assume that R5 has learned a FEC-label = binding via LDP for FEC=3D10.8.8.8/32.  R5 can advertise a locally sig= nificant label binding for this LSP (with label value=3D5099) using the following values and sub-TLVs in the Binding TLV. 

 

Binding TLV: F-bit=3D0, M-bit=3D0, weig= ht=3D1, range=3D1, prefix length=3D32, FEC prefix=3D10.8.8.8

SID/Label Sub-TLV: label=3D5099

ERO Metric sub-TLV: metric=3D100

IPv4 ERO sub-TLV: L-bit=3D1, IPv4 addre= ss=3D10.8.8.8

 

2.5.3 Advertising a BGP labeled-unicast= LSP using the Binding TLV

 

Assume that R9 has used BGP labeled-uni= cast to learn a label binding for prefix 10.15.15.15/32 with BGP next-hop= =3D10.12.12.12.   R9 can advertise a locally significant label binding for this LSP (with label value=3D7099)  using the following v= alues and sub-TLVs in the Binding TLV. 

 

Binding-TLV: F-bit=3D0, M-bit=3D0, weig= ht=3D1, range=3D1, prefix length=3D32, FEC prefix=3D10.15.15.15<= /span>

SID/Label Sub-TLV: label=3D7099

ERO Metric sub-TLV: metric=3D100

IPv4 ERO sub-TLV: L-bit=3D1, IPv4 addre= ss=3D10.12.12.12

 

2.5.4 Advertising a context-id for egre= ss node protection using the Binding TLV

 

Assume that R22 is configured in the pr= otector role to provide egress node protection for R21 using context-id=3D1= 0.0.0.21.  R22 can advertise the label associated with this context-id (with label value=3D8099) using the following values and sub-TL= Vs in the Binding TLV.

 

Binding TLV: F-bit=3D0, M-bit=3D1, weig= ht=3D1, range=3D1, prefix length=3D32, FEC prefix=3D10.0.0.21 SID/Label Sub= -TLV: label=3D8099

 

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

 

 

 

--_000_1B502206DFA0C544B7A60469152008633F319D19eusaamb105erics_-- From nobody Thu Jul 31 18:38:03 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC1B1A0368; Thu, 31 Jul 2014 18:37:59 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfPbxyzy9kFL; Thu, 31 Jul 2014 18:37:55 -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 08B7E1A0373; Thu, 31 Jul 2014 18:37:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKT71851; Fri, 01 Aug 2014 01:37:49 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:37:47 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.48]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:37:37 +0800 From: Xuxiaohu To: "Nobo Akiya (nobo)" , Lizhenbin , "draft-li-mpls-global-label-usecases@tools.ietf.org" Thread-Topic: Comments on draft-li-mpls-global-label-usecases Thread-Index: Ac+pyGOnOvdR466BTIiQqApCOmu/xgBMxX8pAFXSx/AAAgpoUAApuexAAAjFzTA= Date: Fri, 1 Aug 2014 01:37:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829BA49@NKGEML512-MBS.china.huawei.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08233D1D@nkgeml506-mbx.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0829A43F@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9UUDHbTiA4mOAtlmSnnHwSuXFV0 Cc: "mpls@ietf.org" , "" , "sfc@ietf.org" Subject: Re: [spring] Comments on draft-li-mpls-global-label-usecases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:37:59 -0000 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Friday, August 01, 2014 7:33 AM > To: Xuxiaohu; Lizhenbin; draft-li-mpls-global-label-usecases@tools.ietf.o= rg > Cc: mpls@ietf.org > Subject: RE: Comments on draft-li-mpls-global-label-usecases >=20 > Hi Xiaohu, >=20 > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Wednesday, July 30, 2014 9:40 PM > > To: Nobo Akiya (nobo); Lizhenbin; draft-li-mpls-global-label- > > usecases@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: RE: Comments on draft-li-mpls-global-label-usecases > > > > > 2. Service Chaining > > > > > > Why not let SFC folks to do their work, which SFC will then work on > > > the MPLS data plane without any changes to the MPLS data plane nor > > > architecture, certainly doesn't require any "global label" as this > > > use case is describing. Unless the SFC WG require the "global label" > > > (which it doesn't) or the MPLS WG is re-chartered to pick up > > > creation of a tangent SFC solution specifically for MPLS, I don't > > > think this use case is > > valid. > > > [Robin] SFC WG truly works on some new header for service functions. > > > We need to work out the when MPLS dataplane applied, what the > > > possible problem and the solution. I think MPLS has been widely > > > deployed in the existing network and SFC is the possible useful use > > > case in MPLS network which should be taken into account in the MPLS > > > world. MPLS global label is one of the possible solutions. This does > > > not preclude other > > solutions. > > > > [NOBO] SFC is data plane agnostic. When SFC runs on MPLS data plane, > > there is no need to use global labels to describe service functions. > > > > Hi Nobo, > > > > It's fine that SFC is data plane agnostic. In the MPLS-SPRING-based > > SFC approach > > (http://www.ietf.org/proceedings/90/slides/slides-90-spring- > > 5.pdf) where the SFC-specific header is implemented in the form of an > > MPLS label stack, the SFC-encapsulated packet (i.e., the MPLS packet) > > could still be transported between service nodes over any transport > > such as MPLS, IP (e.g., MPLS-over-UDP or MPLS-over-GRE) or even > > Ethernet. To some extent, the MPLS-SPRING-based SFC approach is data pl= ane > agnostic as well. > > > > As had been mentioned in the above PDF, if it's the SFP information > > that is encoded in the MPLS label stack, there is no need for global > > labels. However, provided that some operators did want to encode the > > SFC information, rather than the SFP information in the MPLS label > > stack, the only feasible way to realize such goal is to use global > > labels. Here the global labels just need to be unique within the > > SFC-enabled domain, in other words, they are domain-wide unique > > labels. Just like the global label usage proposed in the segment > > routing mechanism, it only requires that a common label block, > > referred to as SF Label Block (SFLB) is reserved by all service nodes > > and Classifiers for SF SIDs. The domain-wide unique label for a given > > SF would be automatically determined by adding the SF ID to the first l= abel > value of the above SFLB. >=20 > You are creating a framework document based on a use case document that > includes use cases from another use case document that is still an indivi= dual > document. I understand the diff between SFC vs. SFs on SR and complicatio= ns of > NSH on the latter, but the way you are claiming this as a use case seems > premature. Let the SFC folks do their work. Let the SPRING folks do their= work. > Let's focus our energy into helping to progress the two. If either of tho= se spin off > real inter-WG requirements, then we probably won't even need separate use > case documents to start discussing solutions to address those requirement= s. In > other words, let's not take use cases w/o WG consensus to drive additiona= l use > cases to drive solutions. Hi Nobo, I'm not creating a framework doc. I'm just expressing a different opinion f= rom your argument as below: > > [NOBO] SFC is data plane agnostic. When SFC runs on MPLS data plane, > > there is no need to use global labels to describe service functions. That is: even when SFC runs on MPLS data plane, it's still feasible to use = the MPLS label stack to describe the SFP or the SFC information. Furthermor= e, in the latter case (i.e., encoding SFC information in the label stack), = using global labels (i.e., domain-wide unique label) to indicate SFs is the= only choice. Otherwise, the SFF (contained in the service node device) may= need to swap the whole label stack. BTW, global labels (i.e., domain-wide = unique label) just need to be processed by classifiers and service nodes. T= he underlay could be IP networks (e.g., using MPLS-in-UDP). It doesn't requ= ire any change to the existing data plane. In other words, it's just a netw= ork configuration issue. Hence I really don't understand why you and some o= ther guys are so strongly opposing the usage of global labels.=20 Best regards, Xiaohu > Thanks! >=20 > -Nobo >=20 > > > > Best regards, > > Xiaohu From nobody Thu Jul 31 23:54:09 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1F1A0414; Thu, 31 Jul 2014 23:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUFaYBWzNp30; Thu, 31 Jul 2014 23:54:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0CE1A0270; Thu, 31 Jul 2014 23:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5521; q=dns/txt; s=iport; t=1406876045; x=1408085645; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ti9U/wDgdTdHNQVHqn6TrqADXF2D4W+eHQZ1LkwPYqs=; b=OY1xONsGVDIYbS75ugG18lD7IvXBQPYv7AXxypqLIFQYrMEbfDavf9vC ql1/E25Q7MFuH+cIbUO08MogLqgijEhXJeUpioPvlq7cguQbjb1AcgaAm xpVu0+85qNe6nHVcdx4A0yH4G1RL0CsgDXWnugaEaidIHBdmDt1Ysq8Bk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAKc421OtJA2H/2dsb2JhbABbgw1SVwTMAwyHSQGBBhZ3hAMBAQEDAQEBAWsLBQsCAQgRBAEBKAcnCxQJCAIEDgWIOggNylAXjxkzB4MvgRwFjmyNCYFUkwSDSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,778,1400025600"; d="scan'208";a="65696367" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP; 01 Aug 2014 06:54:04 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s716s4CJ027004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 06:54:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 01:54:04 -0500 From: "Stefano Previdi (sprevidi)" To: Uma Chunduri Thread-Topic: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPrQo8rJYS5fRebkqFbfM/9+sOnZu7pH4A Date: Fri, 1 Aug 2014 06:54:03 +0000 Message-ID: References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.169.93] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/9SlR2sC21202UNwo5RiGv1MYjlA Cc: "spring@ietf.org" , "isis-wg@ietf.org" , Chris Bowers Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 06:54:07 -0000 Uma, I agree. I think we also explicitly stated this during our meeting in Toronto (from= =20 the minutes): -------------------------------------------------------------------- Uma: Needed to reference use cases in Hannes' draft. Hannes: Perhaps what we could do is add some practical examples for RSVP, BGP, and LDP LSPs binding. Not formal use cases. Stefano: Would rather not go into applications in this ISIS draft. Peter Psenak: Should go into a separate document that could be referenced from both ISIS and OSPF. Alia Atlas: There is a SPRING WG for such a document. ------------------------------------------------------------------- Now, note that: draft-filsfils-spring-segment-routing draft-filsfils-spring-segment-routing-ldp-interop describe the use case of the SR Mapping Server that is implemented using=20 the Binding TLV. As you suggested, Hannes drafts can be combined so to produce a use-case document (in spring) for the Binding TLV RSVP-based use-cases. s. On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: > [CC=92ed Spring WG] > =20 > I agree with what Chris said below in principle. But all this should not = be obviously part of ISIS/IGP extensions WG documents.. > =20 > Use cases for binding TLVs are explained in great details in 2 key docum= ents (had to shuffle through to get here) =96 > =20 > 1. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-adverti= sement-05 > 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 > =20 > IMO, both are very useful documents. > It would be good to combine both of these and publish as a =93spring =94= document and eventually it should progress there. > AFAICT, Both ISIS and OSPF should refer the same eventually to get more c= larity and use of binding TLVs described currently. > =20 > -- > Uma C. > =20 > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris Bowers > Sent: Thursday, July 31, 2014 2:42 PM > To: isis-wg@ietf.org > Subject: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-= 02 > =20 > All, > =20 > The current text of draft-ietf-isis-segment-routing-extensions-02 does no= t clearly explain the usage of the Binding TLV for advertising LSPs created= using other protocols. I would like to propose the following text to be i= ncluded as section 2.5 . > =20 > Thanks, > Chris > =20 > ---------------- > =20 > 2.5 Binding TLV usage examples > =20 > This section gives examples of using the Binding TLV to advertise SID/lab= el bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. It= also includes an example of advertising a context-id for egress node prote= ction. All of the examples assume that the Binding TLV weight=3D1 and metr= ic=3D100.=20 > =20 > 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV > =20 > Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with rou= ter-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [strict], 19= 2.3.4.2 [strict]). R1 can advertise a locally significant label binding for= this LSP (with label value=3D1099) using the following values and sub-TLV= s in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, FEC prefix=3D10.4.4.4 > SID/Label Sub-TLV: label=3D1099 > ERO Metric sub-TLV: metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 > =20 > 2.5.2 Advertising an LDP LSP using the Binding TLV > =20 > Assume that R5 has learned a FEC-label binding via LDP for FEC=3D10.8.8.8= /32. R5 can advertise a locally significant label binding for this LSP (wi= th label value=3D5099) using the following values and sub-TLVs in the Bindi= ng TLV.=20 > =20 > Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, FEC prefix=3D10.8.8.8 > SID/Label Sub-TLV: label=3D5099 > ERO Metric sub-TLV: metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 > =20 > 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV > =20 > Assume that R9 has used BGP labeled-unicast to learn a label binding for = prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can advertise a= locally significant label binding for this LSP (with label value=3D7099) = using the following values and sub-TLVs in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, FEC prefix=3D10.15.15.15 > SID/Label Sub-TLV: label=3D7099 > ERO Metric sub-TLV: metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 > =20 > 2.5.4 Advertising a context-id for egress node protection using the Bindi= ng TLV > =20 > Assume that R22 is configured in the protector role to provide egress nod= e protection for R21 using context-id=3D10.0.0.21. R22 can advertise the l= abel associated with this context-id (with label value=3D8099) using the fo= llowing values and sub-TLVs in the Binding TLV. > =20 > Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length= =3D32, FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 > =20 > ---------------- > =20 > =20 > =20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg