From cpignata@cisco.com Sun Dec 2 18:10:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511F221F895D for ; Sun, 2 Dec 2012 18:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ZmrIyPq2ir for ; Sun, 2 Dec 2012 18:10:42 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AD54A21F85D1 for ; Sun, 2 Dec 2012 18:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13153; q=dns/txt; s=iport; t=1354500641; x=1355710241; h=from:to:cc:subject:date:message-id:mime-version; bh=ujPjTaOPfAgdtfn86HQOoVkSeXICiG9EVteijmI4OXY=; b=fKl8H+0DmwPBWNOQcIW9WKNo/nW4QaaXU6Ln6vkbgTPM9wthDlkwIVZI o1cd/1ITCNUSxqmyODWyxljGyS5mRRXljSSb8GqSYyczq4oWZU5QTYe9q lJ4wBOXIBBWMP2eIrs24EOKAnOrWsW+87kDtYdqyOBmKNsfQXIgHAmFGM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngLAHYJvFCtJV2Y/2dsb2JhbABEgkm9MRZsB4IgAQQOVxQSASpWJwQODROHdb4TkCBhA6ZIgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="148535315" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 03 Dec 2012 02:10:41 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB32Afs1029744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 02:10:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 20:10:40 -0600 From: "Carlos Pignataro (cpignata)" To: "mpls@ietf.org" Thread-Topic: Technical Review of draft-xu-mpls-in-udp-03 Thread-Index: AQHN0PtkrdRX1gjCK0Czwht46ucobA== Date: Mon, 3 Dec 2012 02:10:40 +0000 Message-ID: <95067C434CE250468B77282634C96ED322747C5C@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.108.51] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322747C5Cxmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" Subject: [mpls] Technical Review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 02:10:43 -0000 --_000_95067C434CE250468B77282634C96ED322747C5Cxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find a set of observations, comments and suggestions regarding draft= -xu-mpls-in-udp-03, from reading and reviewing the document. I do find the = document very well written, and while the requirements are well articulated= , there are some apparent leaps as described below. More substantive: 1. Introduction However, with existing IP-based encapsulation methods as defined in [RFC4023] (e.g., MPLS-in-IP and MPLS-in-GRE), distinct customer traffic flows of various MPLS applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE pair would be encapsulated with the same IP or GRE tunnel header prior to traversing the IP core. Since the encapsulating traffic is neither TCP nor UDP traffic, core routers could only perform hash calculation on the fields in the IP header of IP or GRE tunnels. The Introduction in this document makes some fairly strong statements suppo= rting its conclusion. For example, "Since the encapsulation is neither TCP = nor UDP, core routers could only perform a hash on IP header fields". I am = not sure of the intended meaning of the "could" in that sentence -- however= from a technical perspective, it's incomplete. Certainly, core routers "co= uld" perform a hash calculation for load-balancing from other fields. For M= PLS-in-IP, and in particular for the case of MPLS-in-IPv6, the IPv6 Flow La= bel "could" be used [RFC 6438]. For GRE, the GRC Key can be used [RFC 5640]= . As a result, core routers could not achieve an effective load-balancing for these traffic flows in the network due to the lack of adequate entropy information. Consequently, "lack of entropy information" is not a reason. The fields and= entropy exist already. Further, the case made in this document is based on two requirements: i. MP= LS-in-some_form_of-IP, and ii., IP load-balancing based on UDP/TCP transpor= t ports. It would be useful to have citations that would qualify, quantify,= and better substantiate these requirements. Pointers? Additionally, this document proposes the creation of a new MPLS-in-IP encap= sulation. This new encapsulation requires not only specification but also d= evelopment. However, the requirements that drive the document, by implicati= on, seem to be under the premise that core loadbalancing of other entropy f= ields is not a solution as it is not developed. It would be interesting to = understand a comparative analysis of hashing on other transports and adding= to the LB paths, versus creating a new encapsulation. 3. Encapsulation in UDP ... Source Port of UDP To ensure that the source port number is always in the range 49152 to 65535 which may be required in some cases, instead of calculating a 16-bit hash, the ingress PE router could calculate a 14- bit hash and use those 14 bits as the least significant bits of the source port field while the most significant two bits would be set to binary 11. That still conveys 14 bits of entropy information which would be enough as well in practice. Is there an implication of 14 bits of entropy versus 32 bits of Key, 20 bit= s of Flow Label/MPLS Label, etc? UDP Checksum The usage of this field is in accordance with the current UDP specification. To simplify the operation on egress PE router, this field is recommended to be set to zero. And for MPLS-over-UDP-over-IPv6? draft-ietf-6man-udpzero-07 and draft-ietf-= 6man-udpchecksums-04? 4. Signaling for Encapsulation in UDP I agree with Eric Osborne's observations on this section. Additionally, thi= s section really pollutes an "encapsulation" draft. 8. IANA Considerations Two distinct UDP destination port numbers indicating MPLS and MPLS with upstream-assigned label respectively need to be assigned by IANA. It is not evident (or explicit) in the document why two ports, when other M= PLS-in-IP encaps do not have separate ones. More editorial: [RFC5640] describes a method for improving the load-balancing in Softwire mesh networks [RFC5565]. However, this method requires core routers to be able to perform hash calculation on the fields including the "load-balancing" field contained in the L2TPv3 or GRE tunnel header. Since this document describes various MPLS-in-IP encapsulations and their c= apabilities for LB, should probably also include and cite [RFC 4817] 5. Processing Functions P routers, upon receiving these UDP encapsulated packets, could balance these packets based on the hash of the five-tuple of UDP packets. Is this setting a new requirement for "P routers", making a statement of ex= isting ubiquitous support (citation), or describing an applicability statem= ent for the encapsulation? Upon receiving these UDP encapsulated packets, egress PE routers would decapsulate them by removing the UDP headers and then process them accordingly. The document should also discuss packet size issues, PMTUD, MTU, etc. Thanks, -- Carlos. --_000_95067C434CE250468B77282634C96ED322747C5Cxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

Please find a set of observations, comments and suggestions regarding&= nbsp;draft-xu-mpls-in-udp-03, from readin= g and reviewing the document. I do find the document very well written, and= while the requirements are well articulated, there are some apparent leaps as described below.

More substantive:

1. Introduction=20

   However, with existing IP-based=20
   encapsulation methods as defined in [RFC4023] (e.g., MPLS-in-IP and=20
   MPLS-in-GRE), distinct customer traffic flows of various MPLS=20
   applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE=20
   pair would be encapsulated with the same IP or GRE tunnel header=20
   prior to traversing the IP core. Since the encapsulating traffic is=20
   neither TCP nor UDP traffic, core routers could only perform hash=20
   calculation on the fields in the IP header of IP or GRE tunnels.
The Introduction in this document makes some fairly strong statements = supporting its conclusion. For example, &= quot;Since the encapsulation is neither TCP nor UDP, core routers could onl= y perform a hash on IP header fields". I am not sure of the intended meaning of the "could" in that sen= tence -- however from a technical perspective, it's incomplete. Certainly, = core routers "could" perform a hash calculation for load-balancin= g from other fields. For MPLS-in-IP, and in particular for the case of MPLS-in-IPv6, the IPv6 Flow Label "could" be use= d [RFC 6438]. For GRE, the GR= C Key can be used [RFC 5640].= 
   As=20
   a result, core routers could not achieve an effective load-balancing=20
   for these traffic flows in the network due to the lack of adequate=20
   entropy information.=20
Consequently, "lack of entropy information" is not a reason<= span style=3D"font-size: 12px; ">. The fields and entropy exist already.

Further, the case made in this docum= ent is based on two requirements: i. MPLS-in-some_form_of-IP, and ii., IP l= oad-balancing based on UDP/TCP transport ports. It would be useful to have = citations that would qualify, quantify, and better substantiate these requirements. Pointers?

Additionally, this document proposes the creation of a new MPLS-in-IP = encapsulation. This new encapsulation requires not only specification but a= lso development. However, the requirements that drive the document, by impl= ication, seem to be under the premise that core loadbalancing of other entropy fields is not a solution as it is= not developed. It would be interesting to understand a comparative analysi= s of hashing on other transports and adding to the LB paths, versus creatin= g a new encapsulation.


3. Encapsulation in UDP=20

...
            Source Port of UDP=20

                To ensure that the source=20
                port number is always in the range 49152 to 65535 which=20
                may be required in some cases, instead of calculating a=20
                16-bit hash, the ingress PE router could calculate a 14-
                bit hash and use those 14 bits as the least significant=20
                bits of the source port field while the most significant=20
                two bits would be set to binary 11. That still conveys=20
                14 bits of entropy information which would be enough as=20
                well in practice.
Is there an implication of 14 bits of entropy versus 32 bits of Key, 2= 0 bits of Flow Label/MPLS Label, etc?

            UDP Checksum       =20

                The usage of this field is in accordance with the=20
                current UDP specification. To simplify the operation on=20
                egress PE router, this field is recommended to be set to=20
                zero.

And for MPLS-over-UDP-over-IPv6?&nbs= p;draft-ietf-6man-udpzero-07 and draft-ietf-6man-udpchecksums-0= 4?

4. Signaling for Encapsulation in UDP
I agree with Eric Osborne's observations on this section. Additionally= , this section really pollutes an "encapsulation" draft.

8. IANA Considerations=20

   Two distinct UDP destination port numbers indicating MPLS and MPLS=20
   with upstream-assigned label respectively need to be assigned by=20
   IANA.
It is not evident (or explicit) in the document why two ports, when ot= her MPLS-in-IP encaps do not have separate ones.

More editorial:= 

   [RFC5640] describes a method for improving the load-balancing in=20
   Softwire mesh networks [RFC5565]. However, this method requires core=20
   routers to be able to perform hash calculation on the fields=20
   including the "load-balancing" field contained in the L2TPv3 o=
r GRE=20
   tunnel header.
Since this document describes various MPLS-in-IP encapsulations and th= eir capabilities for LB, should probably also include and cite [RFC 4817] 

5. Processing Functions =20


   P routers, upon receiving these UDP encapsulated packets, could=20
   balance these packets based on the hash of the five-tuple of UDP=20
   packets.
Is this setting a new requirement for "P routers", making a = statement of existing ubiquitous support (citation), or describing an appli= cability statement for the encapsulation?

   Upon receiving these UDP encapsulated packets, egress PE routers=20
   would decapsulate them by removing the UDP headers and then process=20
   them accordingly.

The document should also discuss packet size issues, PMTUD, MTU, etc.<= /div>

Thanks,

-- Carlos.

--_000_95067C434CE250468B77282634C96ED322747C5Cxmbalnx02ciscoc_-- From cpignata@cisco.com Sun Dec 2 18:19:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF4C21F8953 for ; Sun, 2 Dec 2012 18:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLCsSD+KQso3 for ; Sun, 2 Dec 2012 18:19:47 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8D21F8920 for ; Sun, 2 Dec 2012 18:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1354501187; x=1355710787; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nggkatF2+qFyhHUUEwVMEJU0yVdH7D1CHbox1H/OPUM=; b=QDvBHn0pdnIa3PmQN7LNKpbFvWR+e0KAzHSoA8CPOo+JHk9wnix1KA89 Pk/kzlcc/b9O2gsKcoj/QDtXUitFA/HdqsH4cw05cUrj3Lg4BYl8RUtgT LhwccSobiOGGtt9UsThSxKaObeq1Phgi1fCdt/hi06sC9S8s/kW/Gvzhz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsLAMELvFCtJXG+/2dsb2JhbABDv3oWbAeCHgEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQcnCxQJCAIEDgUIARKHbwYMvgeMQINgYQOSFZQzgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="148564335" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 03 Dec 2012 02:19:46 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB32JkYX016685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 02:19:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 20:19:46 -0600 From: "Carlos Pignataro (cpignata)" To: "adrian@olddog.co.uk" Thread-Topic: [mpls] MPLS test session protocol Thread-Index: AQHN0PypLmSDjjSueUi1Z4HqXt0YmA== Date: Mon, 3 Dec 2012 02:19:45 +0000 Message-ID: <95067C434CE250468B77282634C96ED322747CD1@xmb-aln-x02.cisco.com> References: <50B4C34A.8070809@cisco.com> <039001cdccc5$b28078c0$17816a40$@olddog.co.uk> In-Reply-To: <039001cdccc5$b28078c0$17816a40$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.108.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <40C7E37CD0005A45BB96E2D000F722E2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mpls] MPLS test session protocol X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 02:19:47 -0000 Adrian, Stewart, I think that perhaps a good start would be the Performance Metrics Director= ate at http://www.ietf.org/iesg/directorate/performance-metrics.html. I wil= l signal this work to pm-dir. Thanks, -- Carlos. On Nov 27, 2012, at 12:36 PM, Adrian Farrel wrote: > Hi, >=20 > Has anybody raised this work with the IPPM working group to get their tak= e on > it? >=20 > Adrian >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Stewart Bryant >> Sent: 27 November 2012 13:43 >> To: mpls@ietf.org >> Subject: [mpls] MPLS test session protocol >>=20 >> MPLS Working group, >>=20 >> The authors of draft-frost-mpls-test-session-00 wrote this draft to >> provide a simple and general G-ACh protocol for the setup and control of >> test traffic streams over MPLS. Such test streams are required by the >> Inferred Loss Measurement (ILM) mode specified in RFC 6374, and are >> useful for other purposes. >>=20 >> This draft was presented at IETF 85 and received two comments, from Lou >> Berger and Greg Mirsky. The authors would like to request feedback from >> other WG members as to whether this draft should progress in the MPLS >> WG. >>=20 >> To summarize the brief IETF 85 discussion, Greg felt the work was >> important but proposed using RSVP-TE/LDP for test session signaling. >> Lou similarly felt that RSVP-TE should be used in IP environments and >> that static NMS control is sufficient for non-IP MPLS-TP networks. >>=20 >> Note that to support Pseudowire we would also need to define and >> implement an LDP signalling solution in addition to the RSVP-TE >> solution proposed by Lou. Further note that an LDP only solution >> is not an option in MPLS-TP because G-MPLS is the only control >> plane available for LSPs. >>=20 >> In the view of the authors, it is important to have good protocol tools >> available to support OAM applications over the G-ACh in MPLS-TP networks >> with elements that do not necessarily support an IP stack. We do not >> find it convincing that a strictly NMS-based static configuration >> approach suffices to meet the needs of all such deployments. >>=20 >> Also, in our view, even some IP network operators may be reluctant to >> deploy RSVP-TE between, for example, two adjacent nodes merely to get a >> packet loss measurement for a connecting link. >>=20 >> We'd like to hear your views. Do you think the protocol described in >>=20 >> - Stewart & Dan (draft authors) >>=20 >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From xuxiaohu@huawei.com Sun Dec 2 19:58:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5221F8992 for ; Sun, 2 Dec 2012 19:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[AWL=1.680, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VLaCwzyyTam for ; Sun, 2 Dec 2012 19:58:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D944721F889B for ; Sun, 2 Dec 2012 19:58:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANK57520; Mon, 03 Dec 2012 03:58:00 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 03:57:34 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 03:57:57 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 11:57:53 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-in-udp-04.txt Thread-Index: AQHN0QmLF97fXBws3Eef7LcUKEKj5JgGcReA Date: Mon, 3 Dec 2012 03:57:52 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075862A8@szxeml525-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.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:58:08 -0000 SGkgYWxsLA0KDQpBbiB1cGRhdGVkIHZlcnNpb24gaXMgc3VibWl0dGVkIG5vdy4gVGhpcyByZXZp c2lvbiBoYXMgaW5jb3Jwb3JhdGVkIG1vc3QgYWxsIG9mIHRoZSBjb21tZW50cyByZWNlaXZlZCB0 aWxsIGxhc3Qgd2Vla2VuZC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1IChvbiBiZWhhbGYgb2Yg YWxsIGNvLWF1dGhvcnMpDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NCj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MTLmnIgz5pelIDExOjUyDQo+IOaUtuS7tuS6ujog WHV4aWFvaHUNCj4g5oqE6YCBOiBMaXpoZW5iaW47IG5zaGV0aEBjb250cmFpbHN5c3RlbXMuY29t OyBmYW55YkBnc3RhLmNvbTsgTHVjeSB5b25nDQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC14dS1tcGxzLWluLXVkcC0wNC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtbXBscy1pbi11ZHAtMDQudHh0DQo+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQteHUtbXBscy1pbi11ZHANCj4g UmV2aXNpb246CSAwNA0KPiBUaXRsZToJCSBFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQDQo+IENy ZWF0aW9uIGRhdGU6CSAyMDEyLTEyLTAzDQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPiBOdW1iZXIgb2YgcGFnZXM6IDgNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC14dS1tcGxzLWluLXVkcC0wNC50eHQNCj4gU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LW1wbHMtaW4tdWRw DQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUt bXBscy1pbi11ZHAtMDQNCj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC14dS1tcGxzLWluLXVkcC0wNA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg IEV4aXN0aW5nIHRlY2hub2xvZ2llcyB0byBlbmNhcHN1bGF0ZSBNUExTIG92ZXIgSVAgYXJlIG5v dCBhZGVxdWF0ZQ0KPiAgICBmb3IgZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIGFjcm9zcyBJUCBu ZXR3b3Jrcy4gVGhpcyBkb2N1bWVudA0KPiAgICBzcGVjaWZpZXMgYWRkaXRpb25hbCBJUC1iYXNl ZCBlbmNhcHN1bGF0aW9uIHRlY2hub2xvZ3ksIHJlZmVycmVkIHRvDQo+ICAgIGFzIE1QTFMtaW4t VURQLCB3aGljaCBjYW4gZmFjaWxpdGF0ZSB0aGUgbG9hZCBiYWxhbmNpbmcgb2YgTVBMUw0KPiAg ICBhcHBsaWNhdGlvbiB0cmFmZmljLCBzdWNoIGFzIEwyVlBOIGFuZCBMM1ZQTiB0cmFmZmljLCBh Y3Jvc3MgSVANCj4gICAgbmV0d29ya3MuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From someshg@Brocade.COM Thu Nov 29 18:07:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E032B21F8688; Thu, 29 Nov 2012 18:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EroSaZ7kzkUN; Thu, 29 Nov 2012 18:07:48 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0221F8419; Thu, 29 Nov 2012 18:07:47 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qAU27cZQ013808; Thu, 29 Nov 2012 18:07:38 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 18xg3y04bm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Nov 2012 18:07:37 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 29 Nov 2012 18:08:35 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 29 Nov 2012 18:08:13 -0800 From: Somesh Gupta To: Lucy yong , Shahram Davari , Daniel King Date: Thu, 29 Nov 2012 18:08:31 -0800 Thread-Topic: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Thread-Index: AQHHkwCqOEnUt0Njx0mhcjqR0u0yRAGo9NF+l/u7i9CAAJG6/IAD0d9AgAC04gD//5iOUIAAYXPw Message-ID: References: <50A28033.3050904@pi.nu> <7347100B5761DC41A166AC17F22DF11201BCB8@eusaamb103.ericsson.se>, <002a01cdcc17$5ef0dcd0$1cd29670$@olddog.co.uk> <8E15642F-5F4B-4BD3-9BE9-C4EA56AA3FDE@broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44850CB1@dfweml505-mbb.china.huawei.com> <4A6CE49E6084B141B15C0713B8993F281BD34607@SJEXCHMB12.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44852ED2@dfweml505-mbb.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44852ED2@dfweml505-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-29_05:2012-11-29, 2012-11-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211290291 X-Mailman-Approved-At: Sun, 02 Dec 2012 20:25:38 -0800 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "nvo3@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:07:50 -0000 Standardization that ignores how Software Driven Data Centers will be provisioned and managed may be just an academic exercise. The existing solution from Nicira, Vmware and Microsoft do point to the general direction in which the virtual network solution will move. While some existing networking protocols do provide similar functionality, they assume a different operating environment - distributed intelligence, autonomous systems, inability to manage centrally. The Software Driven Data Center will be centrally provisioned and managed. We can come up with the IETF standards, but unless they serve that model in a simple manner, we will be disappointed with their adoption by the folks who own the orchestration and management software. Somesh > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Lucy yong > Sent: Thursday, November 29, 2012 12:21 PM > To: Shahram Davari; Daniel King > Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls- > chairs@tools.ietf.org; nvo3@ietf.org > Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 >=20 > Shahram, >=20 > That is the point. The draft helps to extend VPN solution into DCs for > NVO without implementing MPLS in DC. MPLS VPN solution has been > standardized and deployed widely for long time. >=20 > Regarding your second point, no matter you like or dislike, it already > happens in other WGs. Let's focus on the technical merit here rather > than politics. >=20 > Lucy >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Shahram Davari > > Sent: Thursday, November 29, 2012 12:17 PM > > To: Lucy yong; Daniel King > > Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls- > > chairs@tools.ietf.org; nvo3@ietf.org > > Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > Lucy, > > > > As far as I know data center operators don't like MPLS and that is > why > > the core of Data center is mostly IP (or L2) and not MPLS. As you > > mentioned there is no standard solution, but there are many de-facto > > standards such as NVGRE and VXLAN, which are already in silicon. > > > > I think you should take this argument to NVo3 WG and get their > blessing > > for your solution before indirectly submitting yet another solution > to > > the same problem to MPLS WG. IETF as a whole should decide on one > > preferred solution. > > > > > > > > Thanks > > Shahram > > > > > > > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Thursday, November 29, 2012 8:33 AM > > To: Shahram Davari; Daniel King > > Cc: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; mpls- > > chairs@tools.ietf.org > > Subject: RE: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > Hi Shahram, > > > > Let me share my opinion on this. Please see inline. > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > Shahram Davari > > > Sent: Monday, November 26, 2012 11:10 PM > > > To: Daniel King > > > Cc: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; mpls- > > > chairs@tools.ietf.org > > > Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > Hi, > > > > > > In my opinion this is a solution to a problem that has a dozen > other > > > solutions such as NVGRE, VXLAN, OTP, STT, etc. > > [Lucy] is any of them standardized? do we want any BIG company to > > implement one solution ahead and then tell the industry to follow it > > without going through a standardization? What is the purpose of IETF? > > > > > > > > So I wonder why MPLS WG should spend its valuable time working on > yet > > > another solution. > > [Lucy] IMO: because MPLS and VPN are widely technologies in WAN > space. > > The VPN technology is very close to network virtualization overlay > > vision in DC except current solution is tied into MPLS implementation > > slightly, which makes overlay network (MPLS client layer) couples > with > > underlying network (MPLS server layer). DC NVO requires to decouple > > overlay network from underlying network. We want to leverage VPN > > technology into DC NVO instead of redesigning a full set of VPN > > features for DC NVO. > > > > In fact, the solution is very simple and requires no change to the > > transit nodes while MPLS client layer can decouple from the MPLS > server > > layer. I don't think that it will take a lot of WG time to work out > the > > solution. If you think that it will, please point out where is the > > complexity in the solution? > > > > Regards, > > Lucy > > > > > > Regards, > > > Shahram > > > > > > > > > On Nov 26, 2012, at 12:48 PM, "Daniel King" > > wrote: > > > > > > > Hi All, > > > > > > > > As requested, I have performed an MPLS-TR review of draft-xu- > mpls- > > in- > > > udp-03: > > > > > > > > http://tools.ietf.org/html/draft-xu-mpls-in-udp-03 > > > > > > > > Overall the document is well written and the motivation seems > clear. > > > The > > > > proposed solution is technically sound and given the application > of > > > > tunneling of MPLS VPNs across IP PSNs, the mechanism does look to > > > bring > > > > operational benefits for specific use cases. Therefore I believe > > the > > > > document is ready to be considered for WG adoption. > > > > > > > > Authors, > > > > > > > > As I was reviewing the draft I jotted down a number of minor > > comments, > > > these > > > > are outlined below. Feel free to use or discard. > > > > > > > > 1. Authors. The RFC-Editors are requesting no more than 5 authors > > on > > > the > > > > front-page. So you may as well address this sooner rather than > > later. > > > You > > > > can look to split into to - Authors and Contributing Authors (or > > just > > > > Contributors) to circumnavigate the author limit. > > > > > > > > 2. You should move the Abstract above the Status of this Memo > > section. > > > > > > > > 3. Perhaps look to expand Abstract to: > > > > > > > > Existing technologies to encapsulate MPLS over IP are not > adequate > > > for > > > > efficient transport across IP-enabled Packet Switch Networks > (PSNs). > > > This > > > > document specifies an IP-based encapsulation technology for load- > > > balancing > > > > MPLS packets across IP PSNs. This mechanism is referred to as > MPLS- > > > in-UDP. > > > > > > > > This document defines the protocol extensions and procedures for > > > MPLS-in-UDP > > > > and will facilitate transport of MPLS application traffic, > > including > > > L2VPNs > > > > and L3VPNs, across IP-enabled PSNs. > > > > << > > > > > > > > 4. Introduction is ok, but the wall of text requires splitting > into > > > separate > > > > paragraphs for readability. You could split the introduction into > > > sections > > > > (or just additional paragraphs) to help with navigation, no major > > > changes in > > > > text are required: > > > > > > > > 1. Introduction > > > > - Contains application/motivation background text. > > > > - Intention of the document. > > > > > > > > 1.1 Existing Technologies > > > > - Describes existing techniques (RFC4023, et al.). > > > > > > > > 1.2 Requirements and Motivation > > > > - What the technology or application gaps between prior work and > > this > > > > proposal. > > > > - Very important to discuss the motivation given that we already > > have > > > a > > > > number of alternatives. > > > > > > > > 5. The document mentions "core" a number of times. Is this really > a > > > core > > > > application or is the mechanism more likely to be applied in > > > environments > > > > with equipment that does not support native MPLS forwarding? This > > is > > > > something you might want to expand on in Section 6 > (Applicability) > > > and > > > > lessen the "core" applicability in other parts of the document. > > Also, > > > how > > > > applicable is the document to multicast VPNs, any issues? > > > > > > > > 6. General comment on acronyms. The document expands ECMP but not > > GRE > > > or > > > > SAFI, so maybe check document for consistency. > > > > > > > > Please do not hesitate to email me if anything is not clear. > > > > > > > > Br, Dan. > > > > > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.nu] > > > > Sent: Tuesday, November 13, 2012 9:16 AM > > > > To: Gregory Mirsky; Dan King; Eric Osborne (eosborne); > > > > nick.delregno@verizon.com; mpls-chairs@tools.ietf.org; Martin > > > Vigoureux; > > > > draft-xu-mpls-in-udp@tools.ietf.org > > > > Subject: MPLS-RT review of draft-xu-mpls-in-udp-03 > > > > > > > > Greg, Dan, Eric and Nick, > > > > > > > > You have been selected as an MPLS Review team reviewers for > > > > draft-xu-mpls-in-udp-03. > > > > > > > > Note to authors: You have been CC'd on this email so that you can > > > know that > > > > this review is going on. However, please do not review your own > > > document. > > > > > > > > Reviews should comment on whether the document is coherent, is it > > > useful > > > > (ie, is it likely to be actually useful in operational networks), > > and > > > is the > > > > document technically sound? We are interested in knowing whether > > the > > > > document is ready to be considered for WG adoption (ie, it > doesn't > > > have to > > > > be perfect at this point, but should be a good start). > > > > > > > > Reviews should be sent to the document authors, WG co-chairs and > > > secretary, > > > > and CC'd to the MPLS WG email list. If necessary, comments may be > > > sent > > > > privately to only the WG chairs. > > > > > > > > Are you able to review this draft by November 29, 2012? > > > > > > > > Thanks, Loa > > > > (as MPLS WG chair) > > > > > > > > /Loa > > > > > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > > > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From someshg@Brocade.COM Thu Nov 29 20:22:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C45821F8616; Thu, 29 Nov 2012 20:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[AWL=-2.571, BAYES_00=-2.599, CN_BODY_35=0.339, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, J_CHICKENPOX_37=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EoXVYhBjDfK; Thu, 29 Nov 2012 20:22:57 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id E3EA121F8468; Thu, 29 Nov 2012 20:22:55 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qAU4Mnlw032736; Thu, 29 Nov 2012 20:22:49 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 18xg3y068g-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Nov 2012 20:22:49 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 29 Nov 2012 20:23:46 -0800 Received: from HQ1-EXCH02.corp.brocade.com ([fe80::c92a:772e:befa:c34c]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 29 Nov 2012 20:23:24 -0800 From: Somesh Gupta To: Xuxiaohu , Lucy yong , "Shahram Davari" , Daniel King Date: Thu, 29 Nov 2012 20:23:40 -0800 Thread-Topic: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Thread-Index: AQHNwcJ+OEnUt0Njx0mhcjqR0u0yRJf8iuog//+aL4CAAIwzAIAD43qAgAAdKgCAACKZAIAAYQWAgACPshCAABkVIA== Message-ID: References: <50A28033.3050904@pi.nu> <7347100B5761DC41A166AC17F22DF11201BCB8@eusaamb103.ericsson.se>, <002a01cdcc17$5ef0dcd0$1cd29670$@olddog.co.uk> <8E15642F-5F4B-4BD3-9BE9-C4EA56AA3FDE@broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44850CB1@dfweml505-mbb.china.huawei.com> <4A6CE49E6084B141B15C0713B8993F281BD34607@SJEXCHMB12.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44852ED2@dfweml505-mbb.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07585D24@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07585D24@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-29_05:2012-11-29, 2012-11-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211290334 X-Mailman-Approved-At: Sun, 02 Dec 2012 20:25:38 -0800 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "nvo3@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 04:22:58 -0000 SSB0aGluayBpdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHN0YXJ0IG1hcmtldGluZyBCcm9jYWRlJ3Mg cHJvZHVjdHMNCmFuZCBjb21wYXJpbmcgdGhlaXIgc3VwZXJpb3JpdHkgdG8gc29tZSBvdGhlciB2 ZW5kb3IncyBwcm9kdWN0cy4NCkFuZCBpdCB3b3VsZCBub3QgbWFrZSBzZW5zZSBmb3IgbWUgdG8g ZXhwbGFpbiBob3cgb3VyIHByb2R1Y3RzDQpmaXQgaW50byB0b2RheSdzIGFuZCB0b21vcnJvdydz IGRhdGEgY2VudGVycyBhbmQgaG93IHRoZXkgd2lsbA0KZXZvbHZlLg0KDQpBbmQgSSBhZ3JlZSB0 aGF0IHRoZSBOVkUgd2lsbCBiZSBsb2NhdGVkIGluIHNvbWUgaW5zdGFuY2VzIGluDQpuZXR3b3Jr IGRldmljZXMuDQoNCkFuZCBJIGhhdmUgcmFpc2VkIHRoZSBpc3N1ZSBpbiBudjAzIHRoYXQgdGhl IGNvbnRyb2wgcGxhbmUgaW4gYQ0Kc29mdHdhcmUgZHJpdmVuIGRhdGEgY2VudGVyIHdpbGwgYmUg cHJpbWFyaWx5IGNlbnRyYWxpemVkLiBJIHdhcw0Kb25jZSBhZ2FpbiwgaXQgc2VlbXMgZnV0aWxl bHksIGhvcGluZyBmb3IgYWN0aXZpdHkgdGhhdCBpcyBtb3JlDQplZmZlY3RpdmUuDQoNClJlZ2Fy ZHMNClNvbWVzaA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG52bzMt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IFh1eGlhb2h1DQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyOSwgMjAxMiA3OjE2 IFBNDQo+IFRvOiBTb21lc2ggR3VwdGE7IEx1Y3kgeW9uZzsgU2hhaHJhbSBEYXZhcmk7IERhbmll bCBLaW5nDQo+IENjOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0Bp ZXRmLm9yZzsgbXBscy0NCj4gY2hhaXJzQHRvb2xzLmlldGYub3JnOyBudm8zQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbbnZvM10gW21wbHNdIE1QTFMtUlQgcmV2aWV3IG9mIGRyYWZ0LXh1LW1w bHMtaW4tdWRwLTAzDQo+DQo+IFNvbWVzaCwNCj4NCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g PiC3orz+yMs6IFNvbWVzaCBHdXB0YSBbbWFpbHRvOnNvbWVzaGdAQnJvY2FkZS5DT01dDQo+ID4g t6LLzcqxvOQ6IDIwMTLE6jEx1MIzMMjVIDEwOjA5DQo+ID4gytW8/sjLOiBMdWN5IHlvbmc7IFNo YWhyYW0gRGF2YXJpOyBEYW5pZWwgS2luZw0KPiA+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRw QHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOw0KPiA+IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnOyBudm8zQGlldGYub3JnDQo+ID4g1vfM4jogUkU6IFttcGxzXSBNUExTLVJUIHJldmll dyBvZiBkcmFmdC14dS1tcGxzLWluLXVkcC0wMw0KPiA+DQo+ID4gU3RhbmRhcmRpemF0aW9uIHRo YXQgaWdub3JlcyBob3cgU29mdHdhcmUgRHJpdmVuIERhdGEgQ2VudGVycyB3aWxsIGJlDQo+ID4g cHJvdmlzaW9uZWQgYW5kIG1hbmFnZWQgbWF5IGJlIGp1c3QgYW4gYWNhZGVtaWMgZXhlcmNpc2Uu IFRoZQ0KPiBleGlzdGluZw0KPiA+IHNvbHV0aW9uIGZyb20gTmljaXJhLCBWbXdhcmUgYW5kIE1p Y3Jvc29mdCBkbyBwb2ludCB0byB0aGUgZ2VuZXJhbA0KPiA+IGRpcmVjdGlvbiBpbiB3aGljaCB0 aGUgdmlydHVhbCBuZXR3b3JrIHNvbHV0aW9uIHdpbGwgbW92ZS4NCj4NCj4gQXMgZm9yIHdoZXJl IGlzIHRoZSByaWdodCBsb2NhdGlvbiBmb3IgTlZFKE5ldHdvcmsgVmlydHVhbGl6YXRpb24NCj4g RWRnZSksIHRoZSBjdXJyZW50IE5WbzMgV0cgY29uc2Vuc3VzIGlzIHRoZSBOVkUgY2FuIGJlIGxv Y2F0ZWQgZWl0aGVyDQo+IG9uIG5ldHdvcmsgZGV2aWNlcyBvciBvbiBzZXJ2ZXJzLiBJZiB5b3Ug aGF2ZSBhbnkgZGlmZmVyZW50IG9waW5pb24sIEkNCj4gc3VnZ2VzdCB5b3UgZ28gdG8gdGhlIE5W bzMgdG8gYXJndWUgZm9yIHRoYXQuIEJ5IHRoZSB3YXksIGRpZCB5b3UgZG91YnQNCj4gYWJvdXQg dGhlIGNvcnJlY3RuZXNzIG9mIEJyb2NhZGUncyBwdXJzdWluZyBvZiBUUklMTD8NCj4NCj4gPiBX aGlsZSBzb21lIGV4aXN0aW5nIG5ldHdvcmtpbmcgcHJvdG9jb2xzIGRvIHByb3ZpZGUgc2ltaWxh cg0KPiBmdW5jdGlvbmFsaXR5LA0KPiA+IHRoZXkgYXNzdW1lIGEgZGlmZmVyZW50IG9wZXJhdGlu ZyBlbnZpcm9ubWVudCAtIGRpc3RyaWJ1dGVkDQo+IGludGVsbGlnZW5jZSwNCj4gPiBhdXRvbm9t b3VzIHN5c3RlbXMsIGluYWJpbGl0eSB0byBtYW5hZ2UgY2VudHJhbGx5Lg0KPiA+DQo+ID4gVGhl IFNvZnR3YXJlIERyaXZlbiBEYXRhIENlbnRlciB3aWxsIGJlIGNlbnRyYWxseSBwcm92aXNpb25l ZCBhbmQNCj4gPiBtYW5hZ2VkLiBXZSBjYW4gY29tZSB1cCB3aXRoIHRoZSBJRVRGIHN0YW5kYXJk cywgYnV0IHVubGVzcyB0aGV5DQo+ID4gc2VydmUgdGhhdCBtb2RlbCBpbiBhIHNpbXBsZSBtYW5u ZXIsIHdlIHdpbGwgYmUgZGlzYXBwb2ludGVkIHdpdGgNCj4gPiB0aGVpciBhZG9wdGlvbiBieSB0 aGUgZm9sa3Mgd2hvIG93biB0aGUgb3JjaGVzdHJhdGlvbiBhbmQgbWFuYWdlbWVudA0KPiA+IHNv ZnR3YXJlLg0KPg0KPiBBcyBmb3IgdGhpcyByZWdhcmQsIFRoZSBOVm8zIFdHIGNvbnNlbnN1cyBp cyAiIEEgY29udHJvbC9tYW5hZ2VtZW50DQo+IHBsYW5lIGVudGl0eSBjYW4gYmUgY2VudHJhbGl6 ZWQgb3IgZGlzdHJpYnV0ZWQiIChyZWZlciB0byBOVm8zDQo+IGZyYW1ld29yayBkcmFmdCBmb3Ig bW9yZSBkZXRhaWxzKS4gSWYgeW91IGhhdmUgYW55IGRpZmZlcmVudCBvcGluaW9uIGluDQo+IHRo aXMgcmVnYXJkLCBJIHN1Z2dlc3QgeW91IGdvIHRvIHRoZSBOVm8zIHRvIGFyZ3VlIGZvciB0aGF0 IGFzIHdlbGwuDQo+DQo+IEluIGEgd29yZCwgdGhlIGFib3ZlIGFyZ3VtZW50cyB5b3UgbWVudGlv bmVkIGlzIHNvIEhVR0UgdGhhdCBpdCBzaG91bGQNCj4gYmUgc3VibWl0dGVkIHRvIHRoZSBOVm8z IFdHIG9yIGV2ZW4gdGhlIElFVEYgcGxlbmFyeSBtZWV0aW5nIGZvcg0KPiBkaXNjdXNzaW9uLg0K Pg0KPiBYaWFvaHUNCj4NCj4gPiBTb21lc2gNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm52bzMt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mDQo+ID4gPiBMdWN5IHlvbmcNCj4gPiA+ IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyOSwgMjAxMiAxMjoyMSBQTQ0KPiA+ID4gVG86IFNo YWhyYW0gRGF2YXJpOyBEYW5pZWwgS2luZw0KPiA+ID4gQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRw QHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLQ0KPiA+ID4gY2hhaXJzQHRvb2xz LmlldGYub3JnOyBudm8zQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW252bzNdIFttcGxz XSBNUExTLVJUIHJldmlldyBvZiBkcmFmdC14dS1tcGxzLWluLXVkcC0NCj4gMDMNCj4gPiA+DQo+ ID4gPiBTaGFocmFtLA0KPiA+ID4NCj4gPiA+IFRoYXQgaXMgdGhlIHBvaW50LiBUaGUgZHJhZnQg aGVscHMgdG8gZXh0ZW5kIFZQTiBzb2x1dGlvbiBpbnRvIERDcw0KPiBmb3INCj4gPiA+IE5WTyB3 aXRob3V0IGltcGxlbWVudGluZyBNUExTIGluIERDLiBNUExTIFZQTiBzb2x1dGlvbiBoYXMgYmVl bg0KPiA+ID4gc3RhbmRhcmRpemVkIGFuZCBkZXBsb3llZCB3aWRlbHkgZm9yIGxvbmcgdGltZS4N Cj4gPiA+DQo+ID4gPiBSZWdhcmRpbmcgeW91ciBzZWNvbmQgcG9pbnQsIG5vIG1hdHRlciB5b3Ug bGlrZSBvciBkaXNsaWtlLCBpdA0KPiBhbHJlYWR5DQo+ID4gPiBoYXBwZW5zIGluIG90aGVyIFdH cy4gTGV0J3MgZm9jdXMgb24gdGhlIHRlY2huaWNhbCBtZXJpdCBoZXJlDQo+IHJhdGhlcg0KPiA+ ID4gdGhhbiBwb2xpdGljcy4NCj4gPiA+DQo+ID4gPiBMdWN5DQo+ID4gPg0KPiA+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+ID4gT2YN Cj4gPiA+ID4gU2hhaHJhbSBEYXZhcmkNCj4gPiA+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVy IDI5LCAyMDEyIDEyOjE3IFBNDQo+ID4gPiA+IFRvOiBMdWN5IHlvbmc7IERhbmllbCBLaW5nDQo+ ID4gPiA+IENjOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRm Lm9yZzsgbXBscy0NCj4gPiA+ID4gY2hhaXJzQHRvb2xzLmlldGYub3JnOyBudm8zQGlldGYub3Jn DQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQteHUt bXBscy1pbi11ZHAtMDMNCj4gPiA+ID4NCj4gPiA+ID4gTHVjeSwNCj4gPiA+ID4NCj4gPiA+ID4g QXMgZmFyIGFzIEkga25vdyBkYXRhIGNlbnRlciBvcGVyYXRvcnMgZG9uJ3QgbGlrZSBNUExTIGFu ZCB0aGF0DQo+IGlzDQo+ID4gPiB3aHkNCj4gPiA+ID4gdGhlIGNvcmUgb2YgRGF0YSBjZW50ZXIg aXMgbW9zdGx5IElQIChvciBMMikgYW5kIG5vdCBNUExTLiAgQXMNCj4geW91DQo+ID4gPiA+IG1l bnRpb25lZCB0aGVyZSBpcyBubyBzdGFuZGFyZCBzb2x1dGlvbiwgYnV0IHRoZXJlIGFyZSBtYW55 IGRlLQ0KPiBmYWN0bw0KPiA+ID4gPiBzdGFuZGFyZHMgc3VjaCBhcyBOVkdSRSBhbmQgVlhMQU4s IHdoaWNoIGFyZSBhbHJlYWR5IGluIHNpbGljb24uDQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhpbmsg eW91IHNob3VsZCB0YWtlIHRoaXMgYXJndW1lbnQgdG8gTlZvMyBXRyBhbmQgZ2V0IHRoZWlyDQo+ ID4gPiBibGVzc2luZw0KPiA+ID4gPiBmb3IgeW91ciBzb2x1dGlvbiBiZWZvcmUgaW5kaXJlY3Rs eSBzdWJtaXR0aW5nIHlldCBhbm90aGVyDQo+IHNvbHV0aW9uDQo+ID4gPiB0bw0KPiA+ID4gPiB0 aGUgc2FtZSBwcm9ibGVtIHRvIE1QTFMgV0cuICBJRVRGIGFzIGEgd2hvbGUgc2hvdWxkIGRlY2lk ZSBvbg0KPiBvbmUNCj4gPiA+ID4gcHJlZmVycmVkIHNvbHV0aW9uLg0KPiA+ID4gPg0KPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MNCj4gPiA+ID4gU2hhaHJhbQ0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g PiBGcm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbV0NCj4gPiA+ID4g U2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI5LCAyMDEyIDg6MzMgQU0NCj4gPiA+ID4gVG86IFNo YWhyYW0gRGF2YXJpOyBEYW5pZWwgS2luZw0KPiA+ID4gPiBDYzogbXBsc0BpZXRmLm9yZzsgZHJh ZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtDQo+ID4gPiA+IGNoYWlyc0B0 b29scy5pZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogW21wbHNdIE1QTFMtUlQgcmV2aWV3 IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTAzDQo+ID4gPiA+DQo+ID4gPiA+IEhpIFNoYWhyYW0s DQo+ID4gPiA+DQo+ID4gPiA+IExldCBtZSBzaGFyZSBteSBvcGluaW9uIG9uIHRoaXMuIFBsZWFz ZSBzZWUgaW5saW5lLg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+ID4gRnJvbTogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnXSBPbg0KPiA+ID4gQmVoYWxmDQo+ID4gPiA+IE9mDQo+ID4gPiA+ID4g U2hhaHJhbSBEYXZhcmkNCj4gPiA+ID4gPiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDI2LCAyMDEy IDExOjEwIFBNDQo+ID4gPiA+ID4gVG86IERhbmllbCBLaW5nDQo+ID4gPiA+ID4gQ2M6IG1wbHNA aWV0Zi5vcmc7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLQ0KPiA+ ID4gPiA+IGNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbbXBs c10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDMNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSW4gbXkgb3BpbmlvbiB0aGlzIGlz IGEgc29sdXRpb24gdG8gYSBwcm9ibGVtIHRoYXQgaGFzIGEgZG96ZW4NCj4gPiA+IG90aGVyDQo+ ID4gPiA+ID4gc29sdXRpb25zIHN1Y2ggYXMgTlZHUkUsIFZYTEFOLCBPVFAsIFNUVCwgZXRjLg0K PiA+ID4gPiBbTHVjeV0gaXMgYW55IG9mIHRoZW0gc3RhbmRhcmRpemVkPyBkbyB3ZSB3YW50IGFu eSBCSUcgY29tcGFueSB0bw0KPiA+ID4gPiBpbXBsZW1lbnQgb25lIHNvbHV0aW9uIGFoZWFkIGFu ZCB0aGVuIHRlbGwgdGhlIGluZHVzdHJ5IHRvIGZvbGxvdw0KPiBpdA0KPiA+ID4gPiB3aXRob3V0 IGdvaW5nIHRocm91Z2ggYSBzdGFuZGFyZGl6YXRpb24/IFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YN Cj4gSUVURj8NCj4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFNvIEkgd29uZGVyIHdoeSBN UExTIFdHIHNob3VsZCBzcGVuZCBpdHMgdmFsdWFibGUgdGltZSB3b3JraW5nDQo+IG9uDQo+ID4g PiB5ZXQNCj4gPiA+ID4gPiBhbm90aGVyIHNvbHV0aW9uLg0KPiA+ID4gPiBbTHVjeV0gSU1POiBi ZWNhdXNlIE1QTFMgYW5kIFZQTiBhcmUgd2lkZWx5IHRlY2hub2xvZ2llcyBpbiBXQU4NCj4gPiA+ IHNwYWNlLg0KPiA+ID4gPiBUaGUgVlBOIHRlY2hub2xvZ3kgaXMgdmVyeSBjbG9zZSB0byBuZXR3 b3JrIHZpcnR1YWxpemF0aW9uDQo+IG92ZXJsYXkNCj4gPiA+ID4gdmlzaW9uIGluIERDIGV4Y2Vw dCBjdXJyZW50IHNvbHV0aW9uIGlzIHRpZWQgaW50byBNUExTDQo+IGltcGxlbWVudGF0aW9uDQo+ ID4gPiA+IHNsaWdodGx5LCB3aGljaCBtYWtlcyBvdmVybGF5IG5ldHdvcmsgKE1QTFMgY2xpZW50 IGxheWVyKSBjb3VwbGVzDQo+ID4gPiB3aXRoDQo+ID4gPiA+IHVuZGVybHlpbmcgbmV0d29yayAo TVBMUyBzZXJ2ZXIgbGF5ZXIpLiBEQyBOVk8gcmVxdWlyZXMgdG8NCj4gZGVjb3VwbGUNCj4gPiA+ ID4gb3ZlcmxheSBuZXR3b3JrIGZyb20gdW5kZXJseWluZyBuZXR3b3JrLiBXZSB3YW50IHRvIGxl dmVyYWdlIFZQTg0KPiA+ID4gPiB0ZWNobm9sb2d5IGludG8gREMgTlZPIGluc3RlYWQgb2YgcmVk ZXNpZ25pbmcgYSBmdWxsIHNldCBvZiBWUE4NCj4gPiA+ID4gZmVhdHVyZXMgZm9yIERDIE5WTy4N Cj4gPiA+ID4NCj4gPiA+ID4gSW4gZmFjdCwgdGhlIHNvbHV0aW9uIGlzIHZlcnkgc2ltcGxlIGFu ZCByZXF1aXJlcyBubyBjaGFuZ2UgdG8NCj4gdGhlDQo+ID4gPiA+IHRyYW5zaXQgbm9kZXMgd2hp bGUgTVBMUyBjbGllbnQgbGF5ZXIgY2FuIGRlY291cGxlIGZyb20gdGhlIE1QTFMNCj4gPiA+IHNl cnZlcg0KPiA+ID4gPiBsYXllci4gSSBkb24ndCB0aGluayB0aGF0IGl0IHdpbGwgdGFrZSBhIGxv dCBvZiBXRyB0aW1lIHRvIHdvcmsNCj4gb3V0DQo+ID4gPiB0aGUNCj4gPiA+ID4gc29sdXRpb24u IElmIHlvdSB0aGluayB0aGF0IGl0IHdpbGwsIHBsZWFzZSBwb2ludCBvdXQgd2hlcmUgaXMNCj4g dGhlDQo+ID4gPiA+IGNvbXBsZXhpdHkgaW4gdGhlIHNvbHV0aW9uPw0KPiA+ID4gPg0KPiA+ID4g PiBSZWdhcmRzLA0KPiA+ID4gPiBMdWN5DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBSZWdhcmRzLA0K PiA+ID4gPiA+IFNoYWhyYW0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24gTm92 IDI2LCAyMDEyLCBhdCAxMjo0OCBQTSwgIkRhbmllbCBLaW5nIg0KPiA8ZGFuaWVsQG9sZGRvZy5j by51az4NCj4gPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICBIaSBBbGwsDQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQXMgcmVxdWVzdGVkLCBJIGhhdmUgcGVyZm9ybWVkIGFu IE1QTFMtVFIgcmV2aWV3IG9mIGRyYWZ0LXh1LQ0KPiA+ID4gbXBscy0NCj4gPiA+ID4gaW4tDQo+ ID4gPiA+ID4gdWRwLTAzOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXh1LW1wbHMtaW4tdWRwLTAzDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gT3ZlcmFsbCB0aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCB0aGUgbW90aXZh dGlvbiBzZWVtcw0KPiA+ID4gY2xlYXIuDQo+ID4gPiA+ID4gVGhlDQo+ID4gPiA+ID4gPiBwcm9w b3NlZCBzb2x1dGlvbiBpcyB0ZWNobmljYWxseSBzb3VuZCBhbmQgZ2l2ZW4gdGhlDQo+IGFwcGxp Y2F0aW9uDQo+ID4gPiBvZg0KPiA+ID4gPiA+ID4gdHVubmVsaW5nIG9mIE1QTFMgVlBOcyBhY3Jv c3MgSVAgUFNOcywgdGhlIG1lY2hhbmlzbSBkb2VzDQo+IGxvb2sgdG8NCj4gPiA+ID4gPiBicmlu Zw0KPiA+ID4gPiA+ID4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgZm9yIHNwZWNpZmljIHVzZSBjYXNl cy4gVGhlcmVmb3JlIEkNCj4gYmVsaWV2ZQ0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+IGRvY3Vt ZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uLg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IEF1dGhvcnMsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQXMgSSB3 YXMgcmV2aWV3aW5nIHRoZSBkcmFmdCBJIGpvdHRlZCBkb3duIGEgbnVtYmVyIG9mIG1pbm9yDQo+ ID4gPiA+IGNvbW1lbnRzLA0KPiA+ID4gPiA+IHRoZXNlDQo+ID4gPiA+ID4gPiBhcmUgb3V0bGlu ZWQgYmVsb3cuIEZlZWwgZnJlZSB0byB1c2Ugb3IgZGlzY2FyZC4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiAxLiBBdXRob3JzLiBUaGUgUkZDLUVkaXRvcnMgYXJlIHJlcXVlc3Rpbmcgbm8gbW9y ZSB0aGFuIDUNCj4gYXV0aG9ycw0KPiA+ID4gPiBvbg0KPiA+ID4gPiA+IHRoZQ0KPiA+ID4gPiA+ ID4gZnJvbnQtcGFnZS4gU28geW91IG1heSBhcyB3ZWxsIGFkZHJlc3MgdGhpcyBzb29uZXIgcmF0 aGVyDQo+IHRoYW4NCj4gPiA+ID4gbGF0ZXIuDQo+ID4gPiA+ID4gWW91DQo+ID4gPiA+ID4gPiBj YW4gbG9vayB0byBzcGxpdCBpbnRvIHRvIC0gQXV0aG9ycyBhbmQgQ29udHJpYnV0aW5nIEF1dGhv cnMNCj4gKG9yDQo+ID4gPiA+IGp1c3QNCj4gPiA+ID4gPiA+IENvbnRyaWJ1dG9ycykgdG8gY2ly Y3VtbmF2aWdhdGUgdGhlIGF1dGhvciBsaW1pdC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAy LiBZb3Ugc2hvdWxkIG1vdmUgdGhlIEFic3RyYWN0IGFib3ZlIHRoZSBTdGF0dXMgb2YgdGhpcyBN ZW1vDQo+ID4gPiA+IHNlY3Rpb24uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gMy4gUGVyaGFw cyBsb29rIHRvIGV4cGFuZCBBYnN0cmFjdCB0bzoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBF eGlzdGluZyB0ZWNobm9sb2dpZXMgdG8gZW5jYXBzdWxhdGUgTVBMUyBvdmVyIElQIGFyZSBub3QN Cj4gPiA+IGFkZXF1YXRlDQo+ID4gPiA+ID4gZm9yDQo+ID4gPiA+ID4gPiBlZmZpY2llbnQgdHJh bnNwb3J0IGFjcm9zcyBJUC1lbmFibGVkIFBhY2tldCBTd2l0Y2ggTmV0d29ya3MNCj4gPiA+IChQ U05zKS4NCj4gPiA+ID4gPiBUaGlzDQo+ID4gPiA+ID4gPiBkb2N1bWVudCBzcGVjaWZpZXMgYW4g SVAtYmFzZWQgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IGZvcg0KPiBsb2FkLQ0KPiA+ID4gPiA+ IGJhbGFuY2luZw0KPiA+ID4gPiA+ID4gTVBMUyBwYWNrZXRzIGFjcm9zcyBJUCBQU05zLiBUaGlz IG1lY2hhbmlzbSBpcyByZWZlcnJlZCB0byBhcw0KPiA+ID4gTVBMUy0NCj4gPiA+ID4gPiBpbi1V RFAuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBw cm90b2NvbCBleHRlbnNpb25zIGFuZCBwcm9jZWR1cmVzDQo+IGZvcg0KPiA+ID4gPiA+IE1QTFMt aW4tVURQDQo+ID4gPiA+ID4gPiBhbmQgd2lsbCBmYWNpbGl0YXRlIHRyYW5zcG9ydCBvZiBNUExT IGFwcGxpY2F0aW9uIHRyYWZmaWMsDQo+ID4gPiA+IGluY2x1ZGluZw0KPiA+ID4gPiA+IEwyVlBO cw0KPiA+ID4gPiA+ID4gYW5kIEwzVlBOcywgYWNyb3NzIElQLWVuYWJsZWQgUFNOcy4NCj4gPiA+ ID4gPiA+IDw8DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gNC4gSW50cm9kdWN0aW9uIGlzIG9r LCBidXQgdGhlIHdhbGwgb2YgdGV4dCByZXF1aXJlcw0KPiBzcGxpdHRpbmcNCj4gPiA+IGludG8N Cj4gPiA+ID4gPiBzZXBhcmF0ZQ0KPiA+ID4gPiA+ID4gcGFyYWdyYXBocyBmb3IgcmVhZGFiaWxp dHkuIFlvdSBjb3VsZCBzcGxpdCB0aGUgaW50cm9kdWN0aW9uDQo+IGludG8NCj4gPiA+ID4gPiBz ZWN0aW9ucw0KPiA+ID4gPiA+ID4gKG9yIGp1c3QgYWRkaXRpb25hbCBwYXJhZ3JhcGhzKSB0byBo ZWxwIHdpdGggbmF2aWdhdGlvbiwgbm8NCj4gbWFqb3INCj4gPiA+ID4gPiBjaGFuZ2VzIGluDQo+ ID4gPiA+ID4gPiB0ZXh0IGFyZSByZXF1aXJlZDoNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAx LiBJbnRyb2R1Y3Rpb24NCj4gPiA+ID4gPiA+IC0gQ29udGFpbnMgYXBwbGljYXRpb24vbW90aXZh dGlvbiBiYWNrZ3JvdW5kIHRleHQuDQo+ID4gPiA+ID4gPiAtIEludGVudGlvbiBvZiB0aGUgZG9j dW1lbnQuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gMS4xIEV4aXN0aW5nIFRlY2hub2xvZ2ll cw0KPiA+ID4gPiA+ID4gLSBEZXNjcmliZXMgZXhpc3RpbmcgdGVjaG5pcXVlcyAoUkZDNDAyMywg ZXQgYWwuKS4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAxLjIgUmVxdWlyZW1lbnRzIGFuZCBN b3RpdmF0aW9uDQo+ID4gPiA+ID4gPiAtIFdoYXQgdGhlIHRlY2hub2xvZ3kgb3IgYXBwbGljYXRp b24gZ2FwcyBiZXR3ZWVuIHByaW9yIHdvcmsNCj4gYW5kDQo+ID4gPiA+IHRoaXMNCj4gPiA+ID4g PiA+IHByb3Bvc2FsLg0KPiA+ID4gPiA+ID4gLSBWZXJ5IGltcG9ydGFudCB0byBkaXNjdXNzIHRo ZSBtb3RpdmF0aW9uIGdpdmVuIHRoYXQgd2UNCj4gYWxyZWFkeQ0KPiA+ID4gPiBoYXZlDQo+ID4g PiA+ID4gYQ0KPiA+ID4gPiA+ID4gbnVtYmVyIG9mIGFsdGVybmF0aXZlcy4NCj4gPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiA1LiBUaGUgZG9jdW1lbnQgbWVudGlvbnMgImNvcmUiIGEgbnVtYmVyIG9m IHRpbWVzLiBJcyB0aGlzDQo+IHJlYWxseQ0KPiA+ID4gYQ0KPiA+ID4gPiA+IGNvcmUNCj4gPiA+ ID4gPiA+IGFwcGxpY2F0aW9uIG9yIGlzIHRoZSBtZWNoYW5pc20gbW9yZSBsaWtlbHkgdG8gYmUg YXBwbGllZCBpbg0KPiA+ID4gPiA+IGVudmlyb25tZW50cw0KPiA+ID4gPiA+ID4gd2l0aCBlcXVp cG1lbnQgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IG5hdGl2ZSBNUExTIGZvcndhcmRpbmc/DQo+IFRo aXMNCj4gPiA+ID4gaXMNCj4gPiA+ID4gPiA+IHNvbWV0aGluZyB5b3UgbWlnaHQgd2FudCB0byBl eHBhbmQgb24gaW4gU2VjdGlvbiA2DQo+ID4gPiAoQXBwbGljYWJpbGl0eSkNCj4gPiA+ID4gPiBh bmQNCj4gPiA+ID4gPiA+IGxlc3NlbiB0aGUgImNvcmUiIGFwcGxpY2FiaWxpdHkgaW4gb3RoZXIg cGFydHMgb2YgdGhlDQo+IGRvY3VtZW50Lg0KPiA+ID4gPiBBbHNvLA0KPiA+ID4gPiA+IGhvdw0K PiA+ID4gPiA+ID4gYXBwbGljYWJsZSBpcyB0aGUgZG9jdW1lbnQgdG8gbXVsdGljYXN0IFZQTnMs IGFueSBpc3N1ZXM/DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gNi4gR2VuZXJhbCBjb21tZW50 IG9uIGFjcm9ueW1zLiBUaGUgZG9jdW1lbnQgZXhwYW5kcyBFQ01QIGJ1dA0KPiA+IG5vdA0KPiA+ ID4gPiBHUkUNCj4gPiA+ID4gPiBvcg0KPiA+ID4gPiA+ID4gU0FGSSwgc28gbWF5YmUgY2hlY2sg ZG9jdW1lbnQgZm9yIGNvbnNpc3RlbmN5Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFBsZWFz ZSBkbyBub3QgaGVzaXRhdGUgdG8gZW1haWwgbWUgaWYgYW55dGhpbmcgaXMgbm90IGNsZWFyLg0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEJyLCBEYW4uDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiA+IEZyb206IExvYSBBbmRl cnNzb24gW21haWx0bzpsb2FAcGkubnVdDQo+ID4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAxMywgMjAxMiA5OjE2IEFNDQo+ID4gPiA+ID4gPiBUbzogR3JlZ29yeSBNaXJza3k7IERh biBLaW5nOyBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKTsNCj4gPiA+ID4gPiA+IG5pY2suZGVscmVn bm9AdmVyaXpvbi5jb207IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNYXJ0aW4NCj4gPiA+ ID4gPiBWaWdvdXJldXg7DQo+ID4gPiA+ID4gPiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5p ZXRmLm9yZw0KPiA+ID4gPiA+ID4gU3ViamVjdDogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQteHUt bXBscy1pbi11ZHAtMDMNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBHcmVnLCBEYW4sIEVyaWMg YW5kIE5pY2ssDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gWW91IGhhdmUgYmVlbiBzZWxlY3Rl ZCBhcyBhbiBNUExTIFJldmlldyB0ZWFtIHJldmlld2VycyBmb3INCj4gPiA+ID4gPiA+IGRyYWZ0 LXh1LW1wbHMtaW4tdWRwLTAzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE5vdGUgdG8gYXV0 aG9yczogWW91IGhhdmUgYmVlbiBDQydkIG9uIHRoaXMgZW1haWwgc28gdGhhdCB5b3UNCj4gY2Fu DQo+ID4gPiA+ID4ga25vdyB0aGF0DQo+ID4gPiA+ID4gPiB0aGlzIHJldmlldyBpcyBnb2luZyBv bi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91cg0KPiBvd24NCj4gPiA+ID4gPiBk b2N1bWVudC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBSZXZpZXdzIHNob3VsZCBjb21tZW50 IG9uIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LA0KPiBpcyBpdA0KPiA+ID4gPiA+ IHVzZWZ1bA0KPiA+ID4gPiA+ID4gKGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNl ZnVsIGluIG9wZXJhdGlvbmFsDQo+IG5ldHdvcmtzKSwNCj4gPiA+ID4gYW5kDQo+ID4gPiA+ID4g aXMgdGhlDQo+ID4gPiA+ID4gPiBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8gIFdlIGFyZSBp bnRlcmVzdGVkIGluIGtub3dpbmcNCj4gd2hldGhlcg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiA+ IGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uIChpZSwg aXQNCj4gPiA+IGRvZXNuJ3QNCj4gPiA+ID4gPiBoYXZlIHRvDQo+ID4gPiA+ID4gPiBiZSBwZXJm ZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUgYSBnb29kIHN0YXJ0KS4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBh dXRob3JzLCBXRyBjby1jaGFpcnMNCj4gYW5kDQo+ID4gPiA+ID4gc2VjcmV0YXJ5LA0KPiA+ID4g PiA+ID4gYW5kIENDJ2QgdG8gdGhlIE1QTFMgV0cgZW1haWwgbGlzdC4gSWYgbmVjZXNzYXJ5LCBj b21tZW50cw0KPiBtYXkgYmUNCj4gPiA+ID4gPiBzZW50DQo+ID4gPiA+ID4gPiBwcml2YXRlbHkg dG8gb25seSB0aGUgV0cgY2hhaXJzLg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEFyZSB5b3Ug YWJsZSB0byByZXZpZXcgdGhpcyBkcmFmdCBieSBOb3ZlbWJlciAyOSwgMjAxMj8NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBUaGFua3MsIExvYQ0KPiA+ID4gPiA+ID4gKGFzIE1QTFMgV0cgY2hh aXIpDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gL0xvYQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiAtLQ0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4g PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPiA+ID4gPiA+ IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+ID4gPiA+ID4gPiBTciBTdHJhdGVneSBhbmQg U3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4gPiA+ID4gPiA+IEVyaWNz c29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMN Cj4gPiA+ID4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArNDYgNzY3IDcyIDkyDQo+ID4gMTMNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiA+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4g PiA+ID4gbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiBtcGxzIG1haWxpbmcg bGlzdA0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4gPiBudm8z QGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252 bzMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g bnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From nsheth@contrailsystems.com Fri Nov 30 09:53:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98F021F8B21 for ; Fri, 30 Nov 2012 09:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aKbfB7Qdck0 for ; Fri, 30 Nov 2012 09:53:51 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B121F8B36 for ; Fri, 30 Nov 2012 09:53:51 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so568075pbc.31 for ; Fri, 30 Nov 2012 09:53:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IgnhY9EiMQGnscsJZZ2piU0+ziFANSUdtIRvuotP7ac=; b=fIhCT2g86Wynl2CMidqzHfEet10x+Dwrvhht3t8mCj5FifgC9El6deqTNFeQN6yQ0p EXZIMuOC/nWcnGRYhOxHXURGnqW7cizuMUqluhZ58b0fG6guF6/8HmodPNLm/do8FMxP t7zZtNWxiNrkVclC5zgh1wND8NOcdftBiNfO4hDVT/P7+z1gUdCmCCQlrLM2k+jUMiOP K4xmeP7WypuYDhjHPATRzSqDAHJqq93vs4b+kpio1W2aI5xMDrMEAlYmDVDcp9Lh9Msu CcWfs2TMRvUIx54xIuR26ti0h7iM55nDcSbdE5+4bCGe2040raXPOAXEduRqxhVbBFux aJRw== Received: by 10.68.232.201 with SMTP id tq9mr7710508pbc.12.1354298031231; Fri, 30 Nov 2012 09:53:51 -0800 (PST) Received: from [10.1.2.232] ([108.60.97.219]) by mx.google.com with ESMTPS id ue7sm3358946pbc.53.2012.11.30.09.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 09:53:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Nischal Sheth In-Reply-To: <50B885CA.4070000@pi.nu> Date: Fri, 30 Nov 2012 09:53:49 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <50B51A8A.5050108@pi.nu> <50B885CA.4070000@pi.nu> To: mpls@ietf.org X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmI5lvgoW421EqRFgd1eMdZYnD165jWVRTWHDYOOPiuEqgpyEwVCteaG2gkjfRaOxh7vvXE X-Mailman-Approved-At: Sun, 02 Dec 2012 20:25:38 -0800 Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-xu-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:56:59 -0000 I am not aware of any relevant IPR. -Nischal > > Working Group and authors; > > The authors of draft-xu-mpls-in-udp has indicated that the draft is > ready to be adopted as a working group document. > > Before starting the poll to see if there is wg consensus to make the > draft a working group document we will do an IPR poll to check whether > there is IPR on the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-xu-mpls-in-udp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > From xuxiaohu@huawei.com Sun Dec 2 22:53:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3908621F8200 for ; Sun, 2 Dec 2012 22:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJK7WmlekfJa for ; Sun, 2 Dec 2012 22:53:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0ECB21F898B for ; Sun, 2 Dec 2012 22:53:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMC77481; Mon, 03 Dec 2012 06:52:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 06:52:35 +0000 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 06:52:57 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 14:52:49 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , "mpls@ietf.org" Thread-Topic: Technical Review of draft-xu-mpls-in-udp-03 Thread-Index: AQHN0PtkrdRX1gjCK0Czwht46ucobJgGlN5Q Date: Mon, 3 Dec 2012 06:52:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332@szxeml525-mbs.china.huawei.com> References: <95067C434CE250468B77282634C96ED322747C5C@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322747C5C@xmb-aln-x02.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" Subject: Re: [mpls] Technical Review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:53:03 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUg bXkgcmVzcG9uc2UgaW4gbGluZS4NCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpDQq3osvNyrG85DogMjAxMsTqMTLUwjPI1SAxMDoxMQ0KytW8/sjLOiBtcGxzQGlldGYub3Jn DQqzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNd IFRlY2huaWNhbCBSZXZpZXcgb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDMNCg0KSGksDQoNClBs ZWFzZSBmaW5kIGEgc2V0IG9mIG9ic2VydmF0aW9ucywgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25z IHJlZ2FyZGluZyBkcmFmdC14dS1tcGxzLWluLXVkcC0wMywgZnJvbSByZWFkaW5nIGFuZCByZXZp ZXdpbmcgdGhlIGRvY3VtZW50LiBJIGRvIGZpbmQgdGhlIGRvY3VtZW50IHZlcnkgd2VsbCB3cml0 dGVuLCBhbmQgd2hpbGUgdGhlIHJlcXVpcmVtZW50cyBhcmUgd2VsbCBhcnRpY3VsYXRlZCwgdGhl cmUgYXJlIHNvbWUgYXBwYXJlbnQgbGVhcHMgYXMgZGVzY3JpYmVkIGJlbG93Lg0KDQpNb3JlIHN1 YnN0YW50aXZlOg0KDQoNCjEuIEludHJvZHVjdGlvbg0KDQoNCg0KICAgSG93ZXZlciwgd2l0aCBl eGlzdGluZyBJUC1iYXNlZA0KDQogICBlbmNhcHN1bGF0aW9uIG1ldGhvZHMgYXMgZGVmaW5lZCBp biBbUkZDNDAyM10gKGUuZy4sIE1QTFMtaW4tSVAgYW5kDQoNCiAgIE1QTFMtaW4tR1JFKSwgZGlz dGluY3QgY3VzdG9tZXIgdHJhZmZpYyBmbG93cyBvZiB2YXJpb3VzIE1QTFMNCg0KICAgYXBwbGlj YXRpb25zIChlLmcuLCBNUExTLWJhc2VkIEwyVlBOIG9yIEwzVlBOKSBiZXR3ZWVuIGEgZ2l2ZW4g UEUNCg0KICAgcGFpciB3b3VsZCBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgc2FtZSBJUCBvciBH UkUgdHVubmVsIGhlYWRlcg0KDQogICBwcmlvciB0byB0cmF2ZXJzaW5nIHRoZSBJUCBjb3JlLiBT aW5jZSB0aGUgZW5jYXBzdWxhdGluZyB0cmFmZmljIGlzDQoNCiAgIG5laXRoZXIgVENQIG5vciBV RFAgdHJhZmZpYywgY29yZSByb3V0ZXJzIGNvdWxkIG9ubHkgcGVyZm9ybSBoYXNoDQoNCiAgIGNh bGN1bGF0aW9uIG9uIHRoZSBmaWVsZHMgaW4gdGhlIElQIGhlYWRlciBvZiBJUCBvciBHUkUgdHVu bmVscy4NClRoZSBJbnRyb2R1Y3Rpb24gaW4gdGhpcyBkb2N1bWVudCBtYWtlcyBzb21lIGZhaXJs eSBzdHJvbmcgc3RhdGVtZW50cyBzdXBwb3J0aW5nIGl0cyBjb25jbHVzaW9uLiBGb3IgZXhhbXBs ZSwgIlNpbmNlIHRoZSBlbmNhcHN1bGF0aW9uIGlzIG5laXRoZXIgVENQIG5vciBVRFAsIGNvcmUg cm91dGVycyBjb3VsZCBvbmx5IHBlcmZvcm0gYSBoYXNoIG9uIElQIGhlYWRlciBmaWVsZHMiLiBJ IGFtIG5vdCBzdXJlIG9mIHRoZSBpbnRlbmRlZCBtZWFuaW5nIG9mIHRoZSAiY291bGQiIGluIHRo YXQgc2VudGVuY2UgLS0gaG93ZXZlciBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlLCBpdCdz IGluY29tcGxldGUuIENlcnRhaW5seSwgY29yZSByb3V0ZXJzICJjb3VsZCIgcGVyZm9ybSBhIGhh c2ggY2FsY3VsYXRpb24gZm9yIGxvYWQtYmFsYW5jaW5nIGZyb20gb3RoZXIgZmllbGRzLiBGb3Ig TVBMUy1pbi1JUCwgYW5kIGluIHBhcnRpY3VsYXIgZm9yIHRoZSBjYXNlIG9mIE1QTFMtaW4tSVB2 NiwgdGhlIElQdjYgRmxvdyBMYWJlbCAiY291bGQiIGJlIHVzZWQgW1JGQyA2NDM4XS4gRm9yIEdS RSwgdGhlIEdSQyBLZXkgY2FuIGJlIHVzZWQgW1JGQyA1NjQwXS4NCg0KDQoNCg0KICAgQXMNCg0K ICAgYSByZXN1bHQsIGNvcmUgcm91dGVycyBjb3VsZCBub3QgYWNoaWV2ZSBhbiBlZmZlY3RpdmUg bG9hZC1iYWxhbmNpbmcNCg0KICAgZm9yIHRoZXNlIHRyYWZmaWMgZmxvd3MgaW4gdGhlIG5ldHdv cmsgZHVlIHRvIHRoZSBsYWNrIG9mIGFkZXF1YXRlDQoNCiAgIGVudHJvcHkgaW5mb3JtYXRpb24u DQpDb25zZXF1ZW50bHksICJsYWNrIG9mIGVudHJvcHkgaW5mb3JtYXRpb24iIGlzIG5vdCBhIHJl YXNvbi4gVGhlIGZpZWxkcyBhbmQgZW50cm9weSBleGlzdCBhbHJlYWR5Lg0KDQpbWGlhb2h1XSBU aGUgYWJvdmUgc3RhdGVtZW50IGlzIGFib3V0IHRoZSBNUExTLWluLUdSRSBlbmNhcCB3aXRob3V0 IHVzaW5nIHRoZSBLZXkgZmllbGQgYXMgYSChsGxvYWQtYmFsYW5jaW5nobEgZmllbGQuIEFzIGZv ciB0aGUgbG9hZC1iYWxhbmNpbmcgYXBwcm9hY2ggZm9yIE1QTFMtaW4tR1JFIHVzaW5nIEtleSBm aWVsZCBhcyBhIKGwbG9hZC1iYWxhbmNpbmehsSBmaWVsZCwgaXQgaXMgZGlzY3Vzc2VkIGluIHRo ZSBzdWJzZXF1ZW50IHBhcmFncmFwaC4gQlRXLCB0aGVzZSBzdGF0ZW1lbnRzIGhhdmUgYmVlbiBy ZW9yZ2FuaXplZCBmb3IgcmVhZGFiaWxpdHkgaW4gdGhlIC0wNCB2ZXJzaW9uLiBQbGVhc2Ugc2Vl IHdoZXRoZXIgaXShr3MgT0suDQoNCkZ1cnRoZXIsIHRoZSBjYXNlIG1hZGUgaW4gdGhpcyBkb2N1 bWVudCBpcyBiYXNlZCBvbiB0d28gcmVxdWlyZW1lbnRzOiBpLiBNUExTLWluLXNvbWVfZm9ybV9v Zi1JUCwgYW5kIGlpLiwgSVAgbG9hZC1iYWxhbmNpbmcgYmFzZWQgb24gVURQL1RDUCB0cmFuc3Bv cnQgcG9ydHMuIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIGNpdGF0aW9ucyB0aGF0IHdvdWxk IHF1YWxpZnksIHF1YW50aWZ5LCBhbmQgYmV0dGVyIHN1YnN0YW50aWF0ZSB0aGVzZSByZXF1aXJl bWVudHMuIFBvaW50ZXJzPw0KDQpBZGRpdGlvbmFsbHksIHRoaXMgZG9jdW1lbnQgcHJvcG9zZXMg dGhlIGNyZWF0aW9uIG9mIGEgbmV3IE1QTFMtaW4tSVAgZW5jYXBzdWxhdGlvbi4gVGhpcyBuZXcg ZW5jYXBzdWxhdGlvbiByZXF1aXJlcyBub3Qgb25seSBzcGVjaWZpY2F0aW9uIGJ1dCBhbHNvIGRl dmVsb3BtZW50LiBIb3dldmVyLCB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgZHJpdmUgdGhlIGRvY3Vt ZW50LCBieSBpbXBsaWNhdGlvbiwgc2VlbSB0byBiZSB1bmRlciB0aGUgcHJlbWlzZSB0aGF0IGNv cmUgbG9hZGJhbGFuY2luZyBvZiBvdGhlciBlbnRyb3B5IGZpZWxkcyBpcyBub3QgYSBzb2x1dGlv biBhcyBpdCBpcyBub3QgZGV2ZWxvcGVkLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byB1bmRl cnN0YW5kIGEgY29tcGFyYXRpdmUgYW5hbHlzaXMgb2YgaGFzaGluZyBvbiBvdGhlciB0cmFuc3Bv cnRzIGFuZCBhZGRpbmcgdG8gdGhlIExCIHBhdGhzLCB2ZXJzdXMgY3JlYXRpbmcgYSBuZXcgZW5j YXBzdWxhdGlvbi4NCg0KW1hpYW9odV0gR2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIHRlY2hub2xv Z2llcyBhbmQgdGhlIG1vdGl2YXRpb24gZm9yIE1QTFMtaW4tVURQIGhhdmUgYmVlbiBleHBsYWlu ZWQgbW9yZSBjbGVhcmx5IGluIHRoZSAtMDQgdmVyc2lvbiwgcGxlYXNlIHNlZSB3aGV0aGVyIGl0 oa9zIE9LLg0KDQoNCjMuIEVuY2Fwc3VsYXRpb24gaW4gVURQDQoNCg0KDQouLi4NCg0KICAgICAg ICAgICAgU291cmNlIFBvcnQgb2YgVURQDQoNCg0KDQogICAgICAgICAgICAgICAgVG8gZW5zdXJl IHRoYXQgdGhlIHNvdXJjZQ0KDQogICAgICAgICAgICAgICAgcG9ydCBudW1iZXIgaXMgYWx3YXlz IGluIHRoZSByYW5nZSA0OTE1MiB0byA2NTUzNSB3aGljaA0KDQogICAgICAgICAgICAgICAgbWF5 IGJlIHJlcXVpcmVkIGluIHNvbWUgY2FzZXMsIGluc3RlYWQgb2YgY2FsY3VsYXRpbmcgYQ0KDQog ICAgICAgICAgICAgICAgMTYtYml0IGhhc2gsIHRoZSBpbmdyZXNzIFBFIHJvdXRlciBjb3VsZCBj YWxjdWxhdGUgYSAxNC0NCg0KICAgICAgICAgICAgICAgIGJpdCBoYXNoIGFuZCB1c2UgdGhvc2Ug MTQgYml0cyBhcyB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQNCg0KICAgICAgICAgICAgICAgIGJpdHMg b2YgdGhlIHNvdXJjZSBwb3J0IGZpZWxkIHdoaWxlIHRoZSBtb3N0IHNpZ25pZmljYW50DQoNCiAg ICAgICAgICAgICAgICB0d28gYml0cyB3b3VsZCBiZSBzZXQgdG8gYmluYXJ5IDExLiBUaGF0IHN0 aWxsIGNvbnZleXMNCg0KICAgICAgICAgICAgICAgIDE0IGJpdHMgb2YgZW50cm9weSBpbmZvcm1h dGlvbiB3aGljaCB3b3VsZCBiZSBlbm91Z2ggYXMNCg0KICAgICAgICAgICAgICAgIHdlbGwgaW4g cHJhY3RpY2UuDQpJcyB0aGVyZSBhbiBpbXBsaWNhdGlvbiBvZiAxNCBiaXRzIG9mIGVudHJvcHkg dmVyc3VzIDMyIGJpdHMgb2YgS2V5LCAyMCBiaXRzIG9mIEZsb3cgTGFiZWwvTVBMUyBMYWJlbCwg ZXRjPw0KDQpbWGlhb2h1XSBXaWxsIGFkZCBhIGRlc2NyaXB0aW9uIG9mIHRoaXMgaW1wbGljYXRp b24gaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCg0KICAgICAgICAgICAgVURQIENoZWNrc3VtDQoN Cg0KDQogICAgICAgICAgICAgICAgVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMgaW4gYWNjb3Jk YW5jZSB3aXRoIHRoZQ0KDQogICAgICAgICAgICAgICAgY3VycmVudCBVRFAgc3BlY2lmaWNhdGlv bi4gVG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBvbg0KDQogICAgICAgICAgICAgICAgZWdyZXNz IFBFIHJvdXRlciwgdGhpcyBmaWVsZCBpcyByZWNvbW1lbmRlZCB0byBiZSBzZXQgdG8NCg0KICAg ICAgICAgICAgICAgIHplcm8uDQoNCkFuZCBmb3IgTVBMUy1vdmVyLVVEUC1vdmVyLUlQdjY/IGRy YWZ0LWlldGYtNm1hbi11ZHB6ZXJvLTA3IGFuZCBkcmFmdC1pZXRmLTZtYW4tdWRwY2hlY2tzdW1z LTA0Pw0KDQpbWGlhb2h1XSBXaWxsIGFkZCByZWZlcmVuY2VzIHRvIHRoZSBhYm92ZSB0d28gZHJh ZnRzIGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQoNCjQuIFNpZ25hbGluZyBmb3IgRW5jYXBzdWxh dGlvbiBpbiBVRFANCkkgYWdyZWUgd2l0aCBFcmljIE9zYm9ybmUncyBvYnNlcnZhdGlvbnMgb24g dGhpcyBzZWN0aW9uLiBBZGRpdGlvbmFsbHksIHRoaXMgc2VjdGlvbiByZWFsbHkgcG9sbHV0ZXMg YW4gImVuY2Fwc3VsYXRpb24iIGRyYWZ0Lg0KDQpbWGlhb2h1XSAgVGhpcyBzZWN0aW9uIGhhcyBi ZWVuIHNpbXBsaWZpZWQgZ3JlYXRseSBpbiB0aGUgMDQgdmVyc2lvbi4gSWYgdGhlIFdHIGNvbnNl bnN1cyBpcyB0aGF0IHRoaXMgc2VjdGlvbiBzaG91bGQgYmUgcmVtb3ZlZCBjb21wbGV0ZWx5LCB3 ZSBjYW4gZG8gdGhhdCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KDQo4LiBJQU5BIENvbnNpZGVy YXRpb25zDQoNCg0KDQogICBUd28gZGlzdGluY3QgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVy cyBpbmRpY2F0aW5nIE1QTFMgYW5kIE1QTFMNCg0KICAgd2l0aCB1cHN0cmVhbS1hc3NpZ25lZCBs YWJlbCByZXNwZWN0aXZlbHkgbmVlZCB0byBiZSBhc3NpZ25lZCBieQ0KDQogICBJQU5BLg0KSXQg aXMgbm90IGV2aWRlbnQgKG9yIGV4cGxpY2l0KSBpbiB0aGUgZG9jdW1lbnQgd2h5IHR3byBwb3J0 cywgd2hlbiBvdGhlciBNUExTLWluLUlQIGVuY2FwcyBkbyBub3QgaGF2ZSBzZXBhcmF0ZSBvbmVz Lg0KDQoNCltYaWFvaHVdIE1QTFMtaW4tR1JFIGFsc28gbmVlZHMgdHdvIHByb3RvdHlwZSBjb2Rl cyB0byByZXByZXNlbnQgTVBMUyBhbmQgTVBMUyB3aXRoIGEgdXBzdHJlYW0tYXNzaWduZWQgbGFi ZWwgcmVzcGVjdGl2ZWx5LiBQbGVhc2Ugc2VlIHNlY3Rpb24gNCBvZiBSRkM0MDIzLCBpdCBzYWlk IKGwVGhlIHByb3RvY29sIHR5cGUgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgIE1VU1QgYmUgc2V0 IHRvIHRoZSBFdGhlcnR5cGUgdmFsdWUgZm9yIE1QTFMgVW5pY2FzdCAoMHg4ODQ3KSBvciAgTXVs dGljYXN0ICgweDg4NDgpLqGxDQoNCk1vcmUgZWRpdG9yaWFsOg0KDQoNCiAgIFtSRkM1NjQwXSBk ZXNjcmliZXMgYSBtZXRob2QgZm9yIGltcHJvdmluZyB0aGUgbG9hZC1iYWxhbmNpbmcgaW4NCg0K ICAgU29mdHdpcmUgbWVzaCBuZXR3b3JrcyBbUkZDNTU2NV0uIEhvd2V2ZXIsIHRoaXMgbWV0aG9k IHJlcXVpcmVzIGNvcmUNCg0KICAgcm91dGVycyB0byBiZSBhYmxlIHRvIHBlcmZvcm0gaGFzaCBj YWxjdWxhdGlvbiBvbiB0aGUgZmllbGRzDQoNCiAgIGluY2x1ZGluZyB0aGUgImxvYWQtYmFsYW5j aW5nIiBmaWVsZCBjb250YWluZWQgaW4gdGhlIEwyVFB2MyBvciBHUkUNCg0KICAgdHVubmVsIGhl YWRlci4NClNpbmNlIHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHZhcmlvdXMgTVBMUy1pbi1JUCBl bmNhcHN1bGF0aW9ucyBhbmQgdGhlaXIgY2FwYWJpbGl0aWVzIGZvciBMQiwgc2hvdWxkIHByb2Jh Ymx5IGFsc28gaW5jbHVkZSBhbmQgY2l0ZSBbUkZDIDQ4MTddDQoNCltYaWFvaHVdIFRoZSByZWZl cmVuY2UgdG8gW1JGQyA0ODE3XSBoYXMgYmVlbiBhZGRlZCBpbiB0aGUgLTA0IHZlcnNpb24gYWNj b3JkaW5nIHRvIHlvdXIgcHJldmlvdXMgc3VnZ2VzdGlvbi4NCg0KDQo1LiBQcm9jZXNzaW5nIEZ1 bmN0aW9ucw0KDQoNCg0KDQoNCiAgIFAgcm91dGVycywgdXBvbiByZWNlaXZpbmcgdGhlc2UgVURQ IGVuY2Fwc3VsYXRlZCBwYWNrZXRzLCBjb3VsZA0KDQogICBiYWxhbmNlIHRoZXNlIHBhY2tldHMg YmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUtdHVwbGUgb2YgVURQDQoNCiAgIHBhY2tldHMu DQpJcyB0aGlzIHNldHRpbmcgYSBuZXcgcmVxdWlyZW1lbnQgZm9yICJQIHJvdXRlcnMiLCBtYWtp bmcgYSBzdGF0ZW1lbnQgb2YgZXhpc3RpbmcgdWJpcXVpdG91cyBzdXBwb3J0IChjaXRhdGlvbiks IG9yIGRlc2NyaWJpbmcgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yIHRoZSBlbmNhcHN1 bGF0aW9uPw0KDQpbWGlhb2h1XSBObyBuZXcgcmVxdWlyZW1lbnQgZm9yIFAgcm91dGVycy4gSXQg anVzdCBkZXNjcmliZXMgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQuDQoNCg0KICAgVXBvbiBy ZWNlaXZpbmcgdGhlc2UgVURQIGVuY2Fwc3VsYXRlZCBwYWNrZXRzLCBlZ3Jlc3MgUEUgcm91dGVy cw0KDQogICB3b3VsZCBkZWNhcHN1bGF0ZSB0aGVtIGJ5IHJlbW92aW5nIHRoZSBVRFAgaGVhZGVy cyBhbmQgdGhlbiBwcm9jZXNzDQoNCiAgIHRoZW0gYWNjb3JkaW5nbHkuDQoNClRoZSBkb2N1bWVu dCBzaG91bGQgYWxzbyBkaXNjdXNzIHBhY2tldCBzaXplIGlzc3VlcywgUE1UVUQsIE1UVSwgZXRj Lg0KDQpbWGlhb2h1XSBZb3VyIG9ic2VydmF0aW9uIGlzIGNvcnJlY3QuIFRoaXMgaGFzIGJlZW4g YWRkcmVzc2VkIGluIHRoZSAtMDQgdmVyc2lvbiBhY2NvcmRpbmcgdG8gRXJpYyBPc2Jvcm5lJ3Mg Y29tbWVudC4NCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KVGhhbmtzLA0KDQotLSBDYXJsb3MuDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

Thanks a l= ot for your comments. Please see my response in line.

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bo= unces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA= =B1=ED Carlos Pignataro (cpignata)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C23=C8=D5 10:11
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org
=D6=F7=CC=E2: [mpls] Technical Review of draft-xu-mpls-in-udp-03

 

Hi,

 

Please find a set of observatio= ns, comments and suggestions regarding draft-xu-mpls-in-udp-03, from reading and reviewing = the document. I do find the document very well written, and while the requirements are well articulated, there are some a= pparent leaps as described below.

 

More substantive:

 

1. Introduction 
 
   However, with existing IP-based 
   encapsulation methods as define=
d in [RFC4023] (e.g., MPLS-in-IP and 
   MPLS-in-GRE), distinct customer=
 traffic flows of various MPLS 
   applications (e.g., MPLS-based =
L2VPN or L3VPN) between a given PE 
   pair would be encapsulated with=
 the same IP or GRE tunnel header 
   prior to traversing the IP core=
. Since the encapsulating traffic is 
   neither TCP nor UDP traffic, co=
re routers could only perform hash 
   calculation on the fields in th=
e IP header of IP or GRE tunnels.

The Introduction in this docume= nt makes some fairly strong statements supporting its conclusion. For example, "Since the e= ncapsulation is neither TCP nor UDP, core routers could only perform a hash on IP header fields". I am not sure of the = intended meaning of the "could" in that sentence -- however from = a technical perspective, it's incomplete. Certainly, core routers "cou= ld" perform a hash calculation for load-balancing from other fields. For MPLS-in-IP, and in particular for the case of MPLS-in-IP= v6, the IPv6 Flow Label "could" be used [RFC 6438]. F= or GRE, the GRC Key can be used [RFC 5640<= /span>].

 = ;

 = ;

 = ;

   As 
   a result, core routers could no=
t achieve an effective load-balancing 
   for these traffic flows in the =
network due to the lack of adequate 
   entropy information.

Consequently, "lack of ent= ropy information" is not a reason. The fields and entropy exist already.

&n= bsp;

[Xiaohu] T= he above statement is about the MPLS-in-GRE encap without using the Key fie= ld as a =A1=B0load-balancing=A1=B1 field. As for the load-balancing approach for MPLS-in-GRE using Key field as a =A1=B0load-balancing=A1=B1 f= ield, it is discussed in the subsequent paragraph. BTW, these statements ha= ve been reorganized for readability in the -04 version. Please see whether = it=A1=AFs OK.

 = ;

Furth= er, the case made in this document is based on two requirements: i. MPLS-in= -some_form_of-IP, and ii., IP load-balancing based on UDP/TCP transport por= ts. It would be useful to have citations that would qualify, quantify, and better substantiate these requirements. = Pointers?

 

Additionally, this document pro= poses the creation of a new MPLS-in-IP encapsulation. This new encapsulatio= n requires not only specification but also development. However, the requir= ements that drive the document, by implication, seem to be under the premise that core loadbalancing of other entropy fiel= ds is not a solution as it is not developed. It would be interesting to und= erstand a comparative analysis of hashing on other transports and adding to= the LB paths, versus creating a new encapsulation.

 

[Xiaohu] G= ap analysis of existing technologies and the motivation for MPLS-in-UDP hav= e been explained more clearly in the -04 version, please see whether it=A1=AFs OK.

 = ;

3. Encapsulation in UDP 
 
...
        &=
nbsp;   Source Port of UDP 
 
        &=
nbsp;       To ensure that the source 
        &=
nbsp;       port number is always in the=
 range 49152 to 65535 which 
        &=
nbsp;       may be required in some case=
s, instead of calculating a 
        &=
nbsp;       16-bit hash, the ingress PE =
router could calculate a 14-
        &=
nbsp;       bit hash and use those 14 bits as=
 the least significant 
        &=
nbsp;       bits of the source port fiel=
d while the most significant 
        &=
nbsp;       two bits would be set to bin=
ary 11. That still conveys 
        &=
nbsp;       14 bits of entropy informati=
on which would be enough as 
        &=
nbsp;       well in practice.  =
;    

Is there an implication of 14 b= its of entropy versus 32 bits of Key, 20 bits of Flow Label/MPLS Label, etc= ?

 = ;

[Xiaohu] W= ill add a description of this implication in the next revision.<= /span>

 

        &=
nbsp;   UDP Checksum        
 
        &=
nbsp;       The usage of this field is in acc=
ordance with the 
        &=
nbsp;       current UDP specification. T=
o simplify the operation on 
        &=
nbsp;       egress PE router, this field=
 is recommended to be set to 
        &=
nbsp;       zero.    =
;

 

And f= or MPLS-over-UDP-over-IPv6? draft-ietf-6ma= n-udpzero-07 and draft-ietf-6man-udpchecksums-04?

 = ;

[Xiaohu] W= ill add references to the above two drafts in the next revision.=

 

4. Signaling for Encapsulation in UDP =

I agree with Eric Osborne's obs= ervations on this section. Additionally, this section really pollutes an &q= uot;encapsulation" draft.

&n= bsp;

[Xiaohu]&n= bsp; This section has been simplified greatly in the 04 version. If the WG = consensus is that this section should be removed completely, we can do that in the next revision.

 = ;

8. IANA Considerations 
 
   Two distinct UDP destination port nu=
mbers indicating MPLS and MPLS 
   with upstream-assigned label re=
spectively need to be assigned by 
   IANA.

It is not evident (or explicit)= in the document why two ports, when other MPLS-in-IP encaps do not have se= parate ones.

 = ;

[Xiaohu] MPLS-in-GRE also needs two prototype codes to represent MPL=
S and MPLS with a upstream-assigned label respectively. Please see section =
4 of RFC4023, it said =A1=B0The protocol type field in the GRE header =
 MUST be set to the Ethertype value for MPLS Unicast (0x8847) or  Mult=
icast (0x8848).=A1=B1

 

More editorial:

 

   [RFC5640] describes a method for imp=
roving the load-balancing in 
   Softwire mesh networks [RFC5565=
]. However, this method requires core 
   routers to be able to perform h=
ash calculation on the fields 
   including the "load-balanc=
ing" field contained in the L2TPv3 or GRE 
   tunnel header.

Since this document describes v= arious MPLS-in-IP encapsulations and their capabilities for LB, should prob= ably also include and cite [RFC 4817]

 = ;

[Xiaohu] T= he reference to [RFC 4817] has been added in the -04 version according to y= our previous suggestion.

 

5. Processing Functions  <=
/pre>

 


 


   P routers, upon receiving these UDP =
encapsulated packets, could 


   balance these packets based on =
the hash of the five-tuple of UDP 


   packets.  




Is this setting a new requireme=
nt for "P routers", making a statement of existing ubiquitous sup=
port (citation), or describing an applicability statement for the encapsula=
tion?


 =
;


[Xiaohu] N=
o new requirement for P routers. It just describes an applicability stateme=
nt.

 

   Upon receiving these UDP encapsulate=
d packets, egress PE routers 
   would decapsulate them by remov=
ing the UDP headers and then process 
   them accordingly.

 

The document should also discus= s packet size issues, PMTUD, MTU, etc.

 = ;

[Xiaohu] Y= our observation is correct. This has been addressed in the -04 version acco= rding to Eric Osborne's comment.

 = ;

Thanks aga= in for your valuable comments.

 = ;

Best regar= ds,

Xiaohu

 

Thanks,

 

-- Carlos.

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332szxeml525mbschi_-- From Rolf.Winter@neclab.eu Mon Dec 3 05:44:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0915121F865F for ; Mon, 3 Dec 2012 05:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqInyM8GZ9cw for ; Mon, 3 Dec 2012 05:44:03 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1022321F8521 for ; Mon, 3 Dec 2012 05:44:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 76180102815; Mon, 3 Dec 2012 14:44:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtn9EEpKMPOU; Mon, 3 Dec 2012 14:44:02 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 55BE4102810; Mon, 3 Dec 2012 14:43:32 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 14:42:45 +0100 From: Rolf Winter To: Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLA= Date: Mon, 3 Dec 2012 13:42:29 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> In-Reply-To: <50B88D2A.30504@pi.nu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:44:04 -0000 Loa, These have been mentioned: 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Freitag, 30. November 2012 11:41 > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; draft-ietf-mpls-tp- > mip-mep-map@tools.ietf.org; mpls-ads@tools.ietf.org > Subject: Re: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Authors, >=20 > Can you plese give me an indication of which OAM functions the > separation of in and out MIPs are intended for? >=20 > /Loa >=20 >=20 >=20 > On 2012-11-14 16:16, Loa Andersson wrote: > > > > Working Group, > > > > This is to start a 2 week working group last call on > > draft-ietf-mpls-tp-mip-mep-map. > > > > Please send your comments to the mpls working group mailing list > > (mpls@ietf.org). > > > > Please send both technical comments, and if you are happy with the > > document as is also indications of support. > > > > This working group last call will end on November 28. > > > > /Loa > > for the wg co-chairs > > > > >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From Rolf.Winter@neclab.eu Mon Dec 3 05:53:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFF21F86A4 for ; Mon, 3 Dec 2012 05:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+MlcdH7e2sk for ; Mon, 3 Dec 2012 05:53:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3072A21F861C for ; Mon, 3 Dec 2012 05:53:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5C929102811; Mon, 3 Dec 2012 14:53:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXNB0JDn19tG; Mon, 3 Dec 2012 14:53:21 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3E993102815; Mon, 3 Dec 2012 14:53:06 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 14:52:51 +0100 From: Rolf Winter To: Shahram Davari , Pablo Frank Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNxlMXKWb9xeipk0ykh7jRLlQh+ZfxTQkAgAHCTQCAAOTmgIAAXp2AgABi/fCAAA0igIAHi3cAgAMdCoCAABe0gIAHqEqA Date: Mon, 3 Dec 2012 13:52:50 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broadcom.com> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:53:27 -0000 Hi, sorry for the belated response. I checked with some of our HW people. Here'= s the gist of their response: Of course they wouldn't like parsing TLVs but we established that fact alre= ady. Their answer to the problem is slightly different though. A TTL-expire= d OAM frame can simply be copied and forwarded to the out-MIPs where, if th= e frame is not intended for them, it can safely be dropped. In the P2MP cas= e e.g. this needs to be done anyway, i.e. the implementation must behave in= this exact way in either case. So there is at least one way to implement t= his at line rate without going back and changing a bunch of RFCs. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Mittwoch, 28. November 2012 18:46 > To: Pablo Frank > Cc: mpls@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > Pablo, >=20 >=20 >=20 > That was exactly my point. Let's use a flag to indicate in-MIP or out- > MIP and then the offline processor can do MEPID lookup to determine > whether this is a legitimate OAM packet or not. >=20 >=20 >=20 > Thx > Shahram >=20 >=20 >=20 > From: Pablo Frank [mailto:pabloisnot@gmail.com] > Sent: Wednesday, November 28, 2012 8:22 AM > To: Shahram Davari > Cc: mpls@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 >=20 >=20 > I think Shahram raises a very legitimate concern about how expensive > this could be to implement in hardware. >=20 >=20 >=20 > As I understand it, the logic proposed by this draft is as follows: >=20 >=20 >=20 > At the ingress blade: >=20 >=20 >=20 > IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >=20 > Parse MIP-ID TLV >=20 > Lookup MIP-ID >=20 > IF MIP-is-egress, THEN >=20 > forward normally (but note we must intercept it again on egress) >=20 > ELSE >=20 > punt to OAM processor >=20 >=20 >=20 > At the egress blade: >=20 >=20 >=20 > IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >=20 > Parse MIP-ID TLV >=20 > Lookup MIP-ID >=20 > IF MIP-is-egress, THEN >=20 > punt to OAM processor >=20 > ELSE >=20 > drop >=20 >=20 >=20 > Note all this has to be done in the fast-path now at full line rate > (and hardware guys hate TLVs). Before, the only thing the fast-path > had to do was look for TTL-expiry. >=20 >=20 >=20 > The only reason that ACH reserved bit was rejected (in Appendix A.4 of > -03 version of doc) was because it also required a MIP-ID lookup. But > I don't see anything wrong with combining both mechanisms. Ideally, > hardware could rely on the reserved bit to do the initial filtering at > full line-rate and then a presumably much more cost-efficient OAM > hardware block could perform the MIP-ID lookup. Instead of the complex > logic above, the fast path gets a simple modification to TTL handling > and the OAM block does the heavy lifting of dealing with ACH TLVs, etc. >=20 >=20 >=20 > This seems like a case where practicality should trump elegance. >=20 >=20 >=20 > regards, >=20 > Pablo >=20 >=20 >=20 > On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > wrote: >=20 >=20 >=20 > > Rolf, > > > > I am sure you know that TLVs are not Hardware friendly. And I > think you agree with me that this draft requires deep parsing of all > packets at line rate to get to the MIPID TLV. > > > > I still think the MIPID TLV is required to decide whether an > OAM packet ended up at the right MIP. But may be a simpler solution > could be augmented to decide between In-MIP and Out-MIP. For example > how about using one of the reserved bits in the ACH header. This can > easily be done in hardware with minimum complexity. > > > > Regards, > > Shahram > > > > > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Rolf Winter > > Sent: Wednesday, November 21, 2012 12:13 PM > > To: S. Davari; adrian@olddog.co.uk > > Cc: mpls@ietf.org > > Subject: Re: [mpls] working group last call on draft-ietf-mpls- > tp-mip-mep-map > > > > Hi, > > > >> Hi Adrian, > >> > >> You are right and I should have sent these types of comments > before > >> last call. I completely understand the procedure. > >> > >> One thing I didn't understand in your response is that you > said in-MIP > >> requires to do the MEPID lookup at line rate anyway. Why is > that? > >> > >> My understanding is that before this draft, the process would > have > >> been for the ingress to look at TTL and if it is expired then > send the > >> packet to OAM processor. > > > > Yes (and no). While I assume likely MIP functionality will be > implemented on the ingress, the related RFCs are vague about the actual > placement of the MIP function. See e.g. the OAM Framework (RFC 6371) > "per-node MIPs (i.e., a single MIP per node in an unspecified location > within the node)". > > > > Also, I think "before this draft" is not quite accurate in that > is suggests there is no per-interface MIP addressing possible as of now. > Take RFC 6426. In practice this is where part of the problem lies. We > cannot really go back and change all this. There are other constraints. > E.g. we have a requirement to address a single out-MIP out of a set of > out-MIPs on a P2MP branch point. So this was part of the constraints > we worked with. > > > >> > >> The MEPID that you suggest in this draft is very useful for > filtering > >> out leaked OAM frames from upstream. But lets leave lookup of > the MEPID > >> to the OAM processing module (at slower rate) and add an > indicator to > >> the OAM packet to indicate whether it should be taken out of > the data > >> path in the Ingress or egress. > >> > >> So can I suggest adding the following text to the draft: > >> > >> " In addition to the MEPID, which is used to ultimately accept > or > >> filter out received OAM packets, OAM packets should have a > simple > >> indicator that identifies whether the OAM packet belongs to > in-MIP or > >> Out-MIP". > > > > We also have the question on where to retrofit those bits. I > assume a TLV wouldn't work for the exact reasons you do not like to > have to do a second lookup, since it would require some parsing. All > these constraints and the ones outlined in the document led to where we > are. In a sense this is a non-spec since it rather rules out a number > of things that seem like a good idea at first but then have a catch of > some sort. > > > > Best, > > > > Rolf > > > >> > >> > >> > >> Regards, > >> Shahram > >> > >> > >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > > >> wrote: > >> > >>> > >>> > >>> Hi Shahram, > >>> > >>> I am worried about the precedent of a comment like this > during WG > >> last call. > >>> While comments that improve the document or point out > fundamental > >>> flaws are welcome whenever they arrive, points with the > flavour "I > >>> wouldn't have done it like this" that arrive this late in the > process > >> don't feel very constructive. > >>> But I will leave the chair to worry about process and try to > address > >>> the technical points... > >>> > >>>> Identifying whether to terminate an OAM packet and process > it in In- > >> MIP vs. > >>> Out- > >>>> MIP requires line rate lookup, otherwise the OAM packet will > not > >> take > >>>> the same path as data packets. Therefore any MIP identifier > that is > >>>> proposed in this > >>> draft > >>>> requires one extra lookup and therefore adds significantly > to cost. > >>> > >>> If I am not wrong, this is a feature of an out-MIP. If you > decide to > >>> implement out-MIPs, and if you want the OAM to follow exactly > the > >> same > >>> path as the data, then it is a requirement that the out > interface > >>> inspects the packets (at line > >>> rate) to determine whether they are OAM and targeted at the > interface. > >>> > >>> We cannot change that aspect. All we can do is aim to make > the lookup > >>> as easy as possible. > >>> > >>>> Perhaps a > >>>> similar method to Ethernet MDL/MEL (Maintenance Domain > Level) may be > >>>> used that requires only 3 bits and achieves the same result. > >>> > >>> Perhaps it could. > >>> But before going there, why is the lookup in the current > version of > >>> the I-D arduous? > >>> > >>> Presumably you do not propose making any change to the way > In-MIPs > >> are > >>> currently identified, so the lookups being done at line rate > today on > >>> the incoming interfaces will not be changed. If you are > proposing > >> such > >>> a change, then the discussion is outside the scope of this I- > D and > >>> becomes a much wider question for the working group. > >>> > >>> This leaves me with the trade-off of enabling a *simpler* > lookup on > >>> the outgoing interfaces versus doing identical lookups on > both > >>> interfaces. My assumption was that if the incoming interface > can do > >>> the lookup at line rate, it is not hard to perform the same > lookup on > >>> the outgoing interface. Furthermore, there is a reduction in > >> complexity by having fewer things to look up. > >>> > >>> Another possibility is that the full lookup could be done on > the > >>> incoming interface and the packet marked for easy > interception on the > >> outgoing interface. > >>> The concern with this approach is that the packet would no > longer be > >>> being forwarded exactly as data because it would be being > modified in > >> flight. > >>> Furthermore, in the case of P2MP, it is not enough to flag > the packet > >>> as a local Out-MIP and further identifier-based lookup is > needed. > >>> > >>> Some of these issues were raised and discussed as the I-D > progressed, > >>> and some of the alternative solutions were tracked with their > pros > >> and > >>> cons in Appendix A of the I-D (look at revision -03). > >>> > >>> Thanks, > >>> Adrian > >>>> -----Original Message----- > >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On Behalf > >>>> Of Adrian Farrel > >>>> Sent: Monday, November 19, 2012 8:45 AM > >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > ; > >>> draft-ietf-mpls-tp-mip- > >>>> mep-map@tools.ietf.org > >>>> Subject: Re: [mpls] working group last call on > >>>> draft-ietf-mpls-tp-mip-mep-map > >>>> > >>>> Yeah, it's a boring draft. Did you expect me to co-author > anything > >> else? > >>>> > >>>> The point was that when I started the I-D lots of people > were saying > >>>> "it's complex" and "it can't be done" and "it won't be > backward > >> compatible". > >>>> > >>>> So the I-D says "here it is" > >>>> > >>>> A (sorry not to offer you excitement) > >>>> > >>>>> -----Original Message----- > >>>>> From: t.petch [mailto:ietfc@btconnect.com] > >>>>> Sent: 19 November 2012 12:38 > >>>>> To: Loa Andersson; mpls@ietf.org > >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > ; MPLS-TP ad > >>>>> hoc > >>> team; > >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > >>>>> Subject: Re: [mpls] working group last call on > >>> draft-ietf-mpls-tp-mip-mep-map > >>>>> > >>>>> After getting to section 6 and its features (requirements!), > I find > >>>>> myself underwhelmed; is that it? Well, I suppose so, it is > >>>>> Informational and not Standards Track. > >>>>> > >>>>> Meanwhile, I suggest some editorial issues. > >>>>> > >>>>> Title > >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > [Handling > >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more > >>>>> informative statement unless and until you get to the > definition of > >>>>> Internal in s3; and s6, which is the crux of the document > says The > >>>>> preferred solution to per-interface MIP message handling is > >>>>> presented in this section] > >>>>> > >>>>> s1 > >>>>> two (or more) MIPs per node on both sides of the forwarding > engine. > >>>>> [two on both sides sounds like four in total to me; suggest > 'one on > >>>>> each side of the forwarding engine'] > >>>>> > >>>>> s4 > >>>>> o CV between a MEP and a MIP > >>>>> [expand CV on first use] > >>>>> > >>>>> s5 > >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for > MPLS-TP > >>>>> LSPs and MPLS-TP PWs, respectively. > >>>>> ['respectively' suggests to me that there should be two > precedents, > >>>>> not just RFC5586; the second paragraph specifies RFC5586 > for LSPs, > >>>>> RFC6423/RFC4385 for PWs, in which case, strike this > sentence as > >>>>> redundant] > >>>>> > >>>>> s6 > >>>>> The appendix of this document contains a > >>>>> few solutions that the authors have discarded which have > been > >> left in > >>>>> the document for informational purposes. > >>>>> [not any more they haven't!] > >>>>> > >>>>> The node itself is addresses > >>>>> [The node itself is addressed] > >>>>> > >>>>> The identification information indside [The identification > >>>>> information inside ] > >>>>> > >>>>> MIP identifiers are not know > >>>>> [MIP identifiers are not known] > >>>>> > >>>>> reserved MIP address > >>>>> [reserved MIP addressses or a reserved MIP address] > >>>>> > >>>>> Tom Petch > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Loa Andersson" > >>>>> To: > >>>>> Cc: ; chairs@tools.ietf.org>; > >>>>> "MPLS-TP ad hoc team" ; > >>>>> > >>>>> Sent: Wednesday, November 14, 2012 3:16 PM > >>>>> > >>>>>> Working Group, > >>>>>> > >>>>>> This is to start a 2 week working group last call on > >>>>>> draft-ietf-mpls-tp-mip-mep-map. > >>>>>> > >>>>>> Please send your comments to the mpls working group > mailing list > >>>>>> (mpls@ietf.org). > >>>>>> > >>>>>> Please send both technical comments, and if you are happy > with the > >>>>>> document as is also indications of support. > >>>>>> > >>>>>> This working group last call will end on November 28. > >>>>>> > >>>>>> /Loa > >>>>>> for the wg co-chairs > >>>> > >>>> > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London W3 6BL | Registered in England 2832014 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From stbryant@cisco.com Mon Dec 3 06:30:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826D921F86F3 for ; Mon, 3 Dec 2012 06:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfFmiMcOlgoF for ; Mon, 3 Dec 2012 06:30:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6051221F86CF for ; Mon, 3 Dec 2012 06:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2808; q=dns/txt; s=iport; t=1354545020; x=1355754620; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=isTVSzCZQKJf8cEqAAE7wblQUL3x0J/t/2APrAynAhM=; b=FkohCmWuG1nCDbbfbooW2EORP4YDbLXLKIT7hetWoZgO/ixoYBSzffgl GytWKm8kLkX72sXKtMpfAinF1FK6Vk9gYcPkfxY6TcVsCr/eCNTaThVfQ wsWnq02wZfbJ6j+QnVtHzQib85f/7KXxhlrAmSs9hm+y7eDCCrZz/yRa8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAu3vFCQ/khN/2dsb2JhbABEwAAWc4IeAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGIDAy+H4xAhEEDlgGFa4pcgnKBYwU X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="147708948" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2012 14:30:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB3EUH5Y011627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 14:30:18 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qB3EUD59016622; Mon, 3 Dec 2012 14:30:15 GMT Message-ID: <50BCB775.2060909@cisco.com> Date: Mon, 03 Dec 2012 14:30:13 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <4FDCDA0D.6010204@joelhalpern.com> <50B34B9D.3040102@cisco.com> <50B39D99.90209@joelhalpern.com> In-Reply-To: <50B39D99.90209@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment on draft-ietf-mpls-tp-ethernet-addressing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:30:20 -0000 Joel I have changed the text to: Another approach which may be considered is to use the Ethernet broadcast address FF-FF-FF-FF-FF-FF as the destination MAC address in frames carrying MPLS-TP packets over a link that is known to be point-to-point. This may, however, lead to excessive frame distribution and processing at the Ethernet layer. Broadcast traffic may also be treated specially by some devices and this may not be desirable for MPLS-TP data frames. In view of the above considerations, the approach which SHOULD be used, is therefore to configure both nodes to use the method descibed in this document which uses, as a destination MAC address, an Ethernet multicast address reserved for MPLS-TP for use over point-to-point links. The address allocated for this purpose by the Internet Assigned Numbers Authority (IANA) is 01-00-5E-90-00-00. An MPLS-TP implementation MUST process Ethernet frames received over a point-to-point link with this destination MAC address by default. Which I think should address your concern - Stewart On 26/11/2012 16:49, Joel M. Halpern wrote: > Stewart, > Your description is what I would have expected. > However, sectio 2 of this document recommends that implementations > use this multicast address on pt-to-pt MLS-TP links. There is no > discussion of negotiation, discovery, or even configuration. The text > as written seems to simply assume that using this multicast address > will work. Your description clearly says that it won't work. > > Yours, > Joel > > On 11/26/2012 5:59 AM, Stewart Bryant wrote: >> On 16/06/2012 20:10, Joel M. Halpern wrote: >>> In reviewing this document (sorry I am a day late for the WG LC end), >>> a question occurred to me regarding the material in section 2. >>> >>> Is there reason to believe that existing implementations will process >>> received frames on pt-to-pt Ethernet links where the destination >>> address is 01-00-5E-90-00-00? If so, should that reason be mentioned >>> (or am I just missing the obvious here?) If not, is this a safe >>> recommendation? >>> >>> Otherwise, this is clear and useful. >>> Thank you, >>> Joel >> >> Hi Joel, I only just noticed that I did not reply on this. >> >> An MPLS-TP LSR will reject all ethernet packets received on addresses >> that it is not configured to receive packets on. This is how Ethernet >> interfaces work. Thus an existing implementation will ignore packets >> sent with a MAC address of 01-00-5E-90-00-00, since the address is not >> meaningful to it and thus will not have been configured for reception. >> >> Regards >> >> Stewart > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From davari@broadcom.com Mon Dec 3 07:26:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CD21F8538 for ; Mon, 3 Dec 2012 07:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.431 X-Spam-Level: X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qvaC0xw0zvP for ; Mon, 3 Dec 2012 07:26:58 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2880F21F845B for ; Mon, 3 Dec 2012 07:26:58 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 07:23:56 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 07:26:43 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 07:26:42 -0800 From: "Shahram Davari" To: "Rolf Winter" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsKeQf/mKl4u0SUtKP+ZUNj/pfxIUQJgADKVACAATqdcIABbJeAgABenYCAAFjlgP//jqnggAgUCACAAx0KgP//kH6wgAghlgD//5QedQ== Date: Mon, 3 Dec 2012 15:26:42 +0000 Message-ID: References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broadcom.com> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA21B863R013864717-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:26:59 -0000 Hi Rolf, Your HW guys are correct as long as the amount of data sent to the in-MIP p= rocessor is not much. But from your previous email to Loa I see that you wa= nt to also terminate CV at MIPs. CVs are fast and high bandwidth and blindl= y dumping them on a CPU or OAM processor that may not be expecting them is= like DoS attack.=20 Regards, Shahram On Dec 3, 2012, at 5:53 AM, "Rolf Winter" wrote: > Hi, >=20 > sorry for the belated response. I checked with some of our HW people. Her= e's the gist of their response: >=20 > Of course they wouldn't like parsing TLVs but we established that fact al= ready. Their answer to the problem is slightly different though. A TTL-expi= red OAM frame can simply be copied and forwarded to the out-MIPs where, if = the frame is not intended for them, it can safely be dropped. In the P2MP c= ase e.g. this needs to be done anyway, i.e. the implementation must behave = in this exact way in either case. So there is at least one way to implement= this at line rate without going back and changing a bunch of RFCs. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Shahram Davari >> Sent: Mittwoch, 28. November 2012 18:46 >> To: Pablo Frank >> Cc: mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >>=20 >> Pablo, >>=20 >>=20 >>=20 >> That was exactly my point. Let's use a flag to indicate in-MIP or out- >> MIP and then the offline processor can do MEPID lookup to determine >> whether this is a legitimate OAM packet or not. >>=20 >>=20 >>=20 >> Thx >> Shahram >>=20 >>=20 >>=20 >> From: Pablo Frank [mailto:pabloisnot@gmail.com] >> Sent: Wednesday, November 28, 2012 8:22 AM >> To: Shahram Davari >> Cc: mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >>=20 >>=20 >>=20 >> I think Shahram raises a very legitimate concern about how expensive >> this could be to implement in hardware. >>=20 >>=20 >>=20 >> As I understand it, the logic proposed by this draft is as follows: >>=20 >>=20 >>=20 >> At the ingress blade: >>=20 >>=20 >>=20 >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>=20 >> Parse MIP-ID TLV >>=20 >> Lookup MIP-ID >>=20 >> IF MIP-is-egress, THEN >>=20 >> forward normally (but note we must intercept it again on egress) >>=20 >> ELSE >>=20 >> punt to OAM processor >>=20 >>=20 >>=20 >> At the egress blade: >>=20 >>=20 >>=20 >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>=20 >> Parse MIP-ID TLV >>=20 >> Lookup MIP-ID >>=20 >> IF MIP-is-egress, THEN >>=20 >> punt to OAM processor >>=20 >> ELSE >>=20 >> drop >>=20 >>=20 >>=20 >> Note all this has to be done in the fast-path now at full line rate >> (and hardware guys hate TLVs). Before, the only thing the fast-path >> had to do was look for TTL-expiry. >>=20 >>=20 >>=20 >> The only reason that ACH reserved bit was rejected (in Appendix A.4 of >> -03 version of doc) was because it also required a MIP-ID lookup. But >> I don't see anything wrong with combining both mechanisms. Ideally, >> hardware could rely on the reserved bit to do the initial filtering at >> full line-rate and then a presumably much more cost-efficient OAM >> hardware block could perform the MIP-ID lookup. Instead of the complex >> logic above, the fast path gets a simple modification to TTL handling >> and the OAM block does the heavy lifting of dealing with ACH TLVs, etc. >>=20 >>=20 >>=20 >> This seems like a case where practicality should trump elegance. >>=20 >>=20 >>=20 >> regards, >>=20 >> Pablo >>=20 >>=20 >>=20 >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >> wrote: >>=20 >>=20 >>=20 >> > Rolf, >> > >> > I am sure you know that TLVs are not Hardware friendly. And I >> think you agree with me that this draft requires deep parsing of all >> packets at line rate to get to the MIPID TLV. >> > >> > I still think the MIPID TLV is required to decide whether an >> OAM packet ended up at the right MIP. But may be a simpler solution >> could be augmented to decide between In-MIP and Out-MIP. For example >> how about using one of the reserved bits in the ACH header. This can >> easily be done in hardware with minimum complexity. >> > >> > Regards, >> > Shahram >> > >> > >> > >> > -----Original Message----- >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> Behalf Of Rolf Winter >> > Sent: Wednesday, November 21, 2012 12:13 PM >> > To: S. Davari; adrian@olddog.co.uk >> > Cc: mpls@ietf.org >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- >> tp-mip-mep-map >> > >> > Hi, >> > >> >> Hi Adrian, >> >> >> >> You are right and I should have sent these types of comments >> before >> >> last call. I completely understand the procedure. >> >> >> >> One thing I didn't understand in your response is that you >> said in-MIP >> >> requires to do the MEPID lookup at line rate anyway. Why is >> that? >> >> >> >> My understanding is that before this draft, the process would >> have >> >> been for the ingress to look at TTL and if it is expired then >> send the >> >> packet to OAM processor. >> > >> > Yes (and no). While I assume likely MIP functionality will be >> implemented on the ingress, the related RFCs are vague about the actual >> placement of the MIP function. See e.g. the OAM Framework (RFC 6371) >> "per-node MIPs (i.e., a single MIP per node in an unspecified location >> within the node)". >> > >> > Also, I think "before this draft" is not quite accurate in that >> is suggests there is no per-interface MIP addressing possible as of now. >> Take RFC 6426. In practice this is where part of the problem lies. We >> cannot really go back and change all this. There are other constraints. >> E.g. we have a requirement to address a single out-MIP out of a set of >> out-MIPs on a P2MP branch point. So this was part of the constraints >> we worked with. >> > >> >> >> >> The MEPID that you suggest in this draft is very useful for >> filtering >> >> out leaked OAM frames from upstream. But lets leave lookup of >> the MEPID >> >> to the OAM processing module (at slower rate) and add an >> indicator to >> >> the OAM packet to indicate whether it should be taken out of >> the data >> >> path in the Ingress or egress. >> >> >> >> So can I suggest adding the following text to the draft: >> >> >> >> " In addition to the MEPID, which is used to ultimately accept >> or >> >> filter out received OAM packets, OAM packets should have a >> simple >> >> indicator that identifies whether the OAM packet belongs to >> in-MIP or >> >> Out-MIP". >> > >> > We also have the question on where to retrofit those bits. I >> assume a TLV wouldn't work for the exact reasons you do not like to >> have to do a second lookup, since it would require some parsing. All >> these constraints and the ones outlined in the document led to where we >> are. In a sense this is a non-spec since it rather rules out a number >> of things that seem like a good idea at first but then have a catch of >> some sort. >> > >> > Best, >> > >> > Rolf >> > >> >> >> >> >> >> >> >> Regards, >> >> Shahram >> >> >> >> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >> >> >> wrote: >> >> >> >>> >> >>> >> >>> Hi Shahram, >> >>> >> >>> I am worried about the precedent of a comment like this >> during WG >> >> last call. >> >>> While comments that improve the document or point out >> fundamental >> >>> flaws are welcome whenever they arrive, points with the >> flavour "I >> >>> wouldn't have done it like this" that arrive this late in the >> process >> >> don't feel very constructive. >> >>> But I will leave the chair to worry about process and try to >> address >> >>> the technical points... >> >>> >> >>>> Identifying whether to terminate an OAM packet and process >> it in In- >> >> MIP vs. >> >>> Out- >> >>>> MIP requires line rate lookup, otherwise the OAM packet will >> not >> >> take >> >>>> the same path as data packets. Therefore any MIP identifier >> that is >> >>>> proposed in this >> >>> draft >> >>>> requires one extra lookup and therefore adds significantly >> to cost. >> >>> >> >>> If I am not wrong, this is a feature of an out-MIP. If you >> decide to >> >>> implement out-MIPs, and if you want the OAM to follow exactly >> the >> >> same >> >>> path as the data, then it is a requirement that the out >> interface >> >>> inspects the packets (at line >> >>> rate) to determine whether they are OAM and targeted at the >> interface. >> >>> >> >>> We cannot change that aspect. All we can do is aim to make >> the lookup >> >>> as easy as possible. >> >>> >> >>>> Perhaps a >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain >> Level) may be >> >>>> used that requires only 3 bits and achieves the same result. >> >>> >> >>> Perhaps it could. >> >>> But before going there, why is the lookup in the current >> version of >> >>> the I-D arduous? >> >>> >> >>> Presumably you do not propose making any change to the way >> In-MIPs >> >> are >> >>> currently identified, so the lookups being done at line rate >> today on >> >>> the incoming interfaces will not be changed. If you are >> proposing >> >> such >> >>> a change, then the discussion is outside the scope of this I- >> D and >> >>> becomes a much wider question for the working group. >> >>> >> >>> This leaves me with the trade-off of enabling a *simpler* >> lookup on >> >>> the outgoing interfaces versus doing identical lookups on >> both >> >>> interfaces. My assumption was that if the incoming interface >> can do >> >>> the lookup at line rate, it is not hard to perform the same >> lookup on >> >>> the outgoing interface. Furthermore, there is a reduction in >> >> complexity by having fewer things to look up. >> >>> >> >>> Another possibility is that the full lookup could be done on >> the >> >>> incoming interface and the packet marked for easy >> interception on the >> >> outgoing interface. >> >>> The concern with this approach is that the packet would no >> longer be >> >>> being forwarded exactly as data because it would be being >> modified in >> >> flight. >> >>> Furthermore, in the case of P2MP, it is not enough to flag >> the packet >> >>> as a local Out-MIP and further identifier-based lookup is >> needed. >> >>> >> >>> Some of these issues were raised and discussed as the I-D >> progressed, >> >>> and some of the alternative solutions were tracked with their >> pros >> >> and >> >>> cons in Appendix A of the I-D (look at revision -03). >> >>> >> >>> Thanks, >> >>> Adrian >> >>>> -----Original Message----- >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On Behalf >> >>>> Of Adrian Farrel >> >>>> Sent: Monday, November 19, 2012 8:45 AM >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> ; >> >>> draft-ietf-mpls-tp-mip- >> >>>> mep-map@tools.ietf.org >> >>>> Subject: Re: [mpls] working group last call on >> >>>> draft-ietf-mpls-tp-mip-mep-map >> >>>> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author >> anything >> >> else? >> >>>> >> >>>> The point was that when I started the I-D lots of people >> were saying >> >>>> "it's complex" and "it can't be done" and "it won't be >> backward >> >> compatible". >> >>>> >> >>>> So the I-D says "here it is" >> >>>> >> >>>> A (sorry not to offer you excitement) >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] >> >>>>> Sent: 19 November 2012 12:38 >> >>>>> To: Loa Andersson; mpls@ietf.org >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> ; MPLS-TP ad >> >>>>> hoc >> >>> team; >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >> >>>>> Subject: Re: [mpls] working group last call on >> >>> draft-ietf-mpls-tp-mip-mep-map >> >>>>> >> >>>>> After getting to section 6 and its features (requirements!), >> I find >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is >> >>>>> Informational and not Standards Track. >> >>>>> >> >>>>> Meanwhile, I suggest some editorial issues. >> >>>>> >> >>>>> Title >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >> [Handling >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >> >>>>> informative statement unless and until you get to the >> definition of >> >>>>> Internal in s3; and s6, which is the crux of the document >> says The >> >>>>> preferred solution to per-interface MIP message handling is >> >>>>> presented in this section] >> >>>>> >> >>>>> s1 >> >>>>> two (or more) MIPs per node on both sides of the forwarding >> engine. >> >>>>> [two on both sides sounds like four in total to me; suggest >> 'one on >> >>>>> each side of the forwarding engine'] >> >>>>> >> >>>>> s4 >> >>>>> o CV between a MEP and a MIP >> >>>>> [expand CV on first use] >> >>>>> >> >>>>> s5 >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >> MPLS-TP >> >>>>> LSPs and MPLS-TP PWs, respectively. >> >>>>> ['respectively' suggests to me that there should be two >> precedents, >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 >> for LSPs, >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this >> sentence as >> >>>>> redundant] >> >>>>> >> >>>>> s6 >> >>>>> The appendix of this document contains a >> >>>>> few solutions that the authors have discarded which have >> been >> >> left in >> >>>>> the document for informational purposes. >> >>>>> [not any more they haven't!] >> >>>>> >> >>>>> The node itself is addresses >> >>>>> [The node itself is addressed] >> >>>>> >> >>>>> The identification information indside [The identification >> >>>>> information inside ] >> >>>>> >> >>>>> MIP identifiers are not know >> >>>>> [MIP identifiers are not known] >> >>>>> >> >>>>> reserved MIP address >> >>>>> [reserved MIP addressses or a reserved MIP address] >> >>>>> >> >>>>> Tom Petch >> >>>>> >> >>>>> >> >>>>> ----- Original Message ----- >> >>>>> From: "Loa Andersson" >> >>>>> To: >> >>>>> Cc: ; > chairs@tools.ietf.org>; >> >>>>> "MPLS-TP ad hoc team" ; >> >>>>> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM >> >>>>> >> >>>>>> Working Group, >> >>>>>> >> >>>>>> This is to start a 2 week working group last call on >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. >> >>>>>> >> >>>>>> Please send your comments to the mpls working group >> mailing list >> >>>>>> (mpls@ietf.org). >> >>>>>> >> >>>>>> Please send both technical comments, and if you are happy >> with the >> >>>>>> document as is also indications of support. >> >>>>>> >> >>>>>> This working group last call will end on November 28. >> >>>>>> >> >>>>>> /Loa >> >>>>>> for the wg co-chairs >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> mpls mailing list >> >>>> mpls@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mpls >> >>> >> >>> >> >>> _______________________________________________ >> >>> mpls mailing list >> >>> mpls@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> Road, London W3 6BL | Registered in England 2832014 >> > _______________________________________________ >> > mpls mailing list >> > mpls@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls >> > >> > >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From jmh@joelhalpern.com Mon Dec 3 07:57:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91E21F86C3 for ; Mon, 3 Dec 2012 07:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlkH9UiX6FTy for ; Mon, 3 Dec 2012 07:57:43 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9388421F86B5 for ; Mon, 3 Dec 2012 07:57:43 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8D092A6814 for ; Mon, 3 Dec 2012 07:57:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 988EB1BDA437; Mon, 3 Dec 2012 07:57:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-174.clppva.btas.verizon.net [71.161.50.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BE9991BDA3EB; Mon, 3 Dec 2012 07:57:39 -0800 (PST) Message-ID: <50BCCBE4.7010606@joelhalpern.com> Date: Mon, 03 Dec 2012 10:57:24 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: stbryant@cisco.com References: <4FDCDA0D.6010204@joelhalpern.com> <50B34B9D.3040102@cisco.com> <50B39D99.90209@joelhalpern.com> <50BCB775.2060909@cisco.com> In-Reply-To: <50BCB775.2060909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" Subject: Re: [mpls] Comment on draft-ietf-mpls-tp-ethernet-addressing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:57:44 -0000 That suffices. Thank you, Joel PS: My personal guess is that on a link known correctly to be point-to-point FF-FF-FF-FF-FF-FF would work fine. But that is a WG call, and the new text is sufficient. On 12/3/2012 9:30 AM, Stewart Bryant wrote: > Joel > > I have changed the text to: > > Another approach which may be considered is to use the Ethernet > broadcast address FF-FF-FF-FF-FF-FF as the destination MAC address in > frames carrying MPLS-TP packets over a link that is known to be > point-to-point. This may, however, lead to excessive frame distribution > and processing at the Ethernet layer. Broadcast traffic may also be > treated specially by some devices and this may not be desirable for > MPLS-TP data frames. > > In view of the above considerations, the approach which SHOULD be used, > is therefore to configure both nodes to use the method descibed in this > document which uses, as a destination MAC address, an Ethernet multicast > address reserved for MPLS-TP for use over point-to-point links. The > address allocated for this purpose by the Internet Assigned Numbers > Authority (IANA) is 01-00-5E-90-00-00. An MPLS-TP implementation MUST > process Ethernet frames received over a point-to-point link with this > destination MAC address by default. > > Which I think should address your concern > > - Stewart > > > > On 26/11/2012 16:49, Joel M. Halpern wrote: >> Stewart, >> Your description is what I would have expected. >> However, sectio 2 of this document recommends that implementations >> use this multicast address on pt-to-pt MLS-TP links. There is no >> discussion of negotiation, discovery, or even configuration. The text >> as written seems to simply assume that using this multicast address >> will work. Your description clearly says that it won't work. >> >> Yours, >> Joel >> >> On 11/26/2012 5:59 AM, Stewart Bryant wrote: >>> On 16/06/2012 20:10, Joel M. Halpern wrote: >>>> In reviewing this document (sorry I am a day late for the WG LC end), >>>> a question occurred to me regarding the material in section 2. >>>> >>>> Is there reason to believe that existing implementations will process >>>> received frames on pt-to-pt Ethernet links where the destination >>>> address is 01-00-5E-90-00-00? If so, should that reason be mentioned >>>> (or am I just missing the obvious here?) If not, is this a safe >>>> recommendation? >>>> >>>> Otherwise, this is clear and useful. >>>> Thank you, >>>> Joel >>> >>> Hi Joel, I only just noticed that I did not reply on this. >>> >>> An MPLS-TP LSR will reject all ethernet packets received on addresses >>> that it is not configured to receive packets on. This is how Ethernet >>> interfaces work. Thus an existing implementation will ignore packets >>> sent with a MAC address of 01-00-5E-90-00-00, since the address is not >>> meaningful to it and thus will not have been configured for reception. >>> >>> Regards >>> >>> Stewart >> . >> > > From iesg-secretary@ietf.org Mon Dec 3 09:26:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299921F845B; Mon, 3 Dec 2012 09:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48ptxEv14rkK; Mon, 3 Dec 2012 09:26:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2521F887D; Mon, 3 Dec 2012 09:26:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203172636.24808.44374.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 09:26:36 -0800 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Protocol Action: 'Label Switched Path (LSP) Ping for Pseudowire FECs Advertised over IPv6' to Proposed Standard (draft-ietf-mpls-ipv6-pw-lsp-ping-04.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:26:37 -0000 The IESG has approved the following document: - 'Label Switched Path (LSP) Ping for Pseudowire FECs Advertised over IPv6' (draft-ietf-mpls-ipv6-pw-lsp-ping-04.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-ipv6-pw-lsp-ping/ Technical Summary Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. Working Group Summary There is a general agreement in the MPLS WG that some of our protocols need to be extended to meet requirements present in IPv6 networks. This is one of such extension to LSP Ping. There is good support for the document in the MPLS WG. This document updates RFC 4379 that was developed in the MPLS WG and which covers LSPs and pseudowires. Nevertheless, this document was specifically drawn to the attention of the PWE3 WG to ensure cross- review. Document Quality We know of several implementations or intents to implement this draft. Personnel: Loa Andersson (loa@pi.nu) is the document shepherd. Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. From gregory.mirsky@ericsson.com Mon Dec 3 10:20:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B7E21F8931 for ; Mon, 3 Dec 2012 10:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UapQPPcYAR3H for ; Mon, 3 Dec 2012 10:20:08 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B719F21F891F for ; Mon, 3 Dec 2012 10:20:07 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qB3IK2mG028283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 12:20:06 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 13:20:05 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 13:20:05 -0500 From: Gregory Mirsky To: Rolf Winter , Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0VxJlaR5XVhT/UaZmQSyL/75l5gHYOjw Date: Mon, 3 Dec 2012 18:20:04 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 18:20:09 -0000 Hi Rolf, Do you envision that multiple MIPs, both in- and out-, required to be suppo= rted on a given LSP/PW? I think that only single MIP required per LSP/P= W on an LSR/PE node. If that is the case, then there might be no apparent n= eed to explicitly address in- and out- MIP as such distinction becomes part= of local configuration. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Rol= f Winter Sent: Monday, December 03, 2012 5:42 AM To: Loa Andersson; mpls@ietf.org Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp= -mip-mep-map@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-m= ap Loa, These have been mentioned: 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. d= ata-plane loopback configuration at a MIP 4. diagnostic tests Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Freitag, 30. November 2012 11:41 > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; draft-ietf-mpls-tp-=20 > mip-mep-map@tools.ietf.org; mpls-ads@tools.ietf.org > Subject: Re: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Authors, >=20 > Can you plese give me an indication of which OAM functions the=20 > separation of in and out MIPs are intended for? >=20 > /Loa >=20 >=20 >=20 > On 2012-11-14 16:16, Loa Andersson wrote: > > > > Working Group, > > > > This is to start a 2 week working group last call on=20 > > draft-ietf-mpls-tp-mip-mep-map. > > > > Please send your comments to the mpls working group mailing list=20 > > (mpls@ietf.org). > > > > Please send both technical comments, and if you are happy with the=20 > > document as is also indications of support. > > > > This working group last call will end on November 28. > > > > /Loa > > for the wg co-chairs > > > > >=20 > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Mon Dec 3 11:32:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639A21F884B; Mon, 3 Dec 2012 11:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J81LZoJTPHC4; Mon, 3 Dec 2012 11:32:40 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C347B21F884A; Mon, 3 Dec 2012 11:32:40 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB3JfNFM020104; Mon, 3 Dec 2012 13:41:45 -0600 Received: from EUSAAHC006.ericsson.se (147.117.188.90) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 14:32:31 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 14:32:31 -0500 From: Gregory Mirsky To: Marc Binderberger , Shahram Davari Thread-Topic: Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAqkOwAAChtFQA== Date: Mon, 3 Dec 2012 19:32:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:32:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Shahram, Marc, et al., I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 = WGs have a stake in this discussion. I agree that compatibility with intervals standardized for Ether OAM (CFM/Y= .1731) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless. And I agree with Marc that BFD-based CC is not only for packet or Ethernet = transport applications. And more values of transmission interval are useful= . That is why I believe that we should not standardize any values, at least= not on Standard Track. At most it could be an informational document. Or, = which will be great, have a survey among providers on what interval values = being used (similar to great survey on PWE VCCV Control Channels). Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Marc Binderberger Sent: Monday, December 03, 2012 11:08 AM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: Re: Commenst on draft-akiya-bfd-intervals-03 Hello Shahram, thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things. I do agree with including the values you mention in the list of BFD support= ed values, although I question the large values. On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world. Regards, Marc On 2012-12-03, at 20:02 , Shahram Davari wrote: Hi, I would like to propose standardizing the same intervals as Y.1731/802.1ag = for BFD. This would make the total L2, L3 OAM more homogeneous. So the prop= osal is: 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min. Thank you, Shharam -- Marc Binderberger > --_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Shahram, Marc, et al.,
I think that since BFD is the CC/= CV part of MPLS-TP OAM both MPLS and PWE3 WGs have a stake in this discussi= on.
I agree that compatibility with i= ntervals standardized for Ether OAM (CFM/Y.1731) makes sense and might be h= elpful in interworking. But I'll note that even with the same transmission intervals failure detection in BFD-based CC/CV = and Ether OAM is different time interval. Not by much but different neverth= eless.
And I agree with Marc that BFD-ba= sed CC is not only for packet or Ethernet transport applications. And more = values of transmission interval are useful. That is why I believe that we should not standardize any values, at least = not on Standard Track. At most it could be an informational document. Or, w= hich will be great, have a survey among providers on what interval values b= eing used (similar to great survey on PWE VCCV Control Channels).
 
    Regards,
     &nb= sp;  Greg

From: rtg-bfd-bounces@ietf.org [mai= lto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderberger
Sent: Monday, December 03, 2012 11:08 AM
To: Shahram Davari
Cc: rtg-bfd@ietf.org
Subject: Re: Commenst on draft-akiya-bfd-intervals-03

Hello Shahram,

thanks for re-vitalizing this discussion - must admit I was busy with = too many other things.

I do agree with including the values you mention in the list of BFD su= pported values, although I question the large values.

On the other hand: we are not re-inventing Ethernet OAM and we _have_ = BFD implementations out there. So we likely need to support other values as= well to fit into the existing world.


Regards, Marc





On 2012-12-03, at 20:02 , Shahram Davari wrote:

Hi,
I would like to propose standardizing the same intervals as Y.1731/802.1ag = for BFD. This would make the total L2, L3 OAM more homogeneous. So the prop= osal is:
3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.
Thank you,
 Shharam

--<= /div>
Marc Binderberger           <marc@sniff.de>

--_000_7347100B5761DC41A166AC17F22DF11201E91Eeusaamb103ericsso_-- From saalvare@cisco.com Mon Dec 3 11:48:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A7721F8811; Mon, 3 Dec 2012 11:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d03X4vcIk8T3; Mon, 3 Dec 2012 11:48:06 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AFCB421F880B; Mon, 3 Dec 2012 11:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14069; q=dns/txt; s=iport; t=1354564085; x=1355773685; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QffO5VomvQjpkO2DZYnJQIU3Je5ohYF7Q9Qm/rqcySE=; b=j0lYGy1HyScNZWVrC7YYJbdu32tdygUCNpILRhYG99KTvln6zqZ5QVeL OkpFd6vla1L1nJ5By9dZprNKsmm+cpDsXGyWFFT7HhlJRqLSSLkqY7eBD iLzB5jw37wJIqJQPTrjb65CPec182WY53F5bLJogNiONRBCwBd9h/BtZs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAgBvVCtJXG//2dsb2JhbABEgkm8HBZzgh4BAQEEGBVMEAIBCBEEAQELHQcyFAkIAQEEAQ0FCIgIvk2MQINgYQOmSIJygiE X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="148852149" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 03 Dec 2012 19:48:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB3Jm3sC010470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 19:48:03 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.123]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 13:48:03 -0600 From: "Santiago Alvarez (saalvare)" To: Gregory Mirsky , Marc Binderberger , Shahram Davari Thread-Topic: Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAqkOwAAChtFQAATgFsg Date: Mon, 3 Dec 2012 19:48:02 +0000 Message-ID: <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.53] Content-Type: multipart/alternative; boundary="_000_0C8935EE66D53445A3D3982BD9BE546815573400xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" , "Santiago Alvarez \(saalvare\)" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:48:11 -0000 --_000_0C8935EE66D53445A3D3982BD9BE546815573400xmbalnx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Applicability of BFD is pretty wide. Mandating a set of intervals driven b= y Y.1731 doesn't sound like a good idea to me. Having lived through most o= f the BFD CC interop testing in the context of MPLS-TP, I can see some valu= e in having an informational doc that would discuss interval configuration = and interoperability. Cheers. SA -- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gre= gory Mirsky Sent: Monday, December 03, 2012 11:33 AM To: Marc Binderberger; Shahram Davari Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 Dear Shahram, Marc, et al., I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 = WGs have a stake in this discussion. I agree that compatibility with intervals standardized for Ether OAM (CFM/Y= .1731) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless. And I agree with Marc that BFD-based CC is not only for packet or Ethernet = transport applications. And more values of transmission interval are useful= . That is why I believe that we should not standardize any values, at least= not on Standard Track. At most it could be an informational document. Or, = which will be great, have a survey among providers on what interval values = being used (similar to great survey on PWE VCCV Control Channels). Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg= -bfd-bounces@ietf.org] On Behalf Of Marc Binderberger Sent: Monday, December 03, 2012 11:08 AM To: Shahram Davari Cc: rtg-bfd@ietf.org Subject: Re: Commenst on draft-akiya-bfd-intervals-03 Hello Shahram, thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things. I do agree with including the values you mention in the list of BFD support= ed values, although I question the large values. On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world. Regards, Marc On 2012-12-03, at 20:02 , Shahram Davari wrote: Hi, I would like to propose standardizing the same intervals as Y.1731/802.1ag = for BFD. This would make the total L2, L3 OAM more homogeneous. So the prop= osal is: 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min. Thank you, Shharam -- Marc Binderberger > --_000_0C8935EE66D53445A3D3982BD9BE546815573400xmbalnx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Applicability of BFD is p= retty wide.  Mandating a set of intervals driven by Y.1731 doesn’= ;t sound like a good idea to me.  Having lived through most of the BFD CC interop testing in the context of MPLS-TP, I can see some value in = having an informational doc that would discuss interval configuration and i= nteroperability.

Cheers.=

 <= /p>

SA

--

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, December 03, 2012 11:33 AM
To: Marc Binderberger; Shahram Davari
Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03

 

Dear Shahram, Marc, et al.,

I think that since BFD is the = CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs have a stake in this discu= ssion.

I agree that compatibility wit= h intervals standardized for Ether OAM (CFM/Y.1731) makes sense and might b= e helpful in interworking. But I'll note that even with the same transmission intervals failure detection in BFD-based CC/CV and E= ther OAM is different time interval. Not by much but different nevertheless= .

And I agree with Marc that BFD= -based CC is not only for packet or Ethernet transport applications. And mo= re values of transmission interval are useful. That is why I believe that we should not standardize any values, at least not on Stand= ard Track. At most it could be an informational document. Or, which will be= great, have a survey among providers on what interval values being used (s= imilar to great survey on PWE VCCV Control Channels).

 

    Regards,

     =    Greg

 

From:<= /span> rtg-bfd-bounces@ietf.org [<= a href=3D"mailto:rtg-bfd-bounces@ietf.org">mailto:rtg-bfd-bounces@ietf.org<= /a>] On Behalf Of Marc Binderberger
Sent: Monday, December 03, 2012 11:08 AM
To: Shahram Davari
Cc: rtg-bfd@ietf.org
Subject: Re: Commenst on draft-akiya-bfd-intervals-03

Hello Shahram,

 

thanks for re-vitalizing this discussion - must admi= t I was busy with too many other things.

 

I do agree with including the values you mention in = the list of BFD supported values, although I question the large values.

 

On the other hand: we are not re-inventing Ethernet = OAM and we _have_ BFD implementations out there. So we likely need to suppo= rt other values as well to fit into the existing world.

 

 

Regards, Marc

 

 

 

 

 

On 2012-12-03, at 20:02 , Shahram Davari wrote:=



Hi,

I would like to propose standardizing t= he same intervals as Y.1731/802.1ag for BFD. This would make the total L2, = L3 OAM more homogeneous. So the proposal is:

3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min= , 10min.

Thank you,

 Shharam

 

--

Marc Binderberger           <marc@sniff.de>

 

--_000_0C8935EE66D53445A3D3982BD9BE546815573400xmbalnx09ciscoc_-- From aldrin.ietf@gmail.com Mon Dec 3 11:53:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FF21F87EE; Mon, 3 Dec 2012 11:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAdJPb75mkRw; Mon, 3 Dec 2012 11:53:34 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8B21F8809; Mon, 3 Dec 2012 11:53:33 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1349619dae.31 for ; Mon, 03 Dec 2012 11:53:32 -0800 (PST) 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:x-mailer; bh=E/waLi5LQEi/SlyjGrZKCjimRHHrL4aod4PGJALJZhY=; b=CJPFZVZiL3eo0ZrD1SJ8ar5NE1T6hzJdB+b1EBSM46fkPzs99kAazw17j8/AcEuiAF 7QCQhBMTFgQ8iMhdz9DWgLe6M+TsfphB3z/jJqKzr99hP3bYN9g7Es8ym5l2DRwnEAXJ QmW0t96nOWN/WY3+PwbFtwy8BA47u8ybKyel9Byd9VqRBcev/GaGNk0SHGXXVKSm6pul 8XyJ+4V+j/N8oJwAwvyVnjxG5wF5Q4z/X4zzZVY0r3B02n4laQ3Wp8kI4JJ7oUtMEkH3 A9IALb4DA2zl+/qvgCHSAQ/SStGkPivS+0sBsF9C4C7dewIUd+xX+5kmwceBdKFOhrUJ r8jA== Received: by 10.68.131.8 with SMTP id oi8mr32121644pbb.29.1354564412342; Mon, 03 Dec 2012 11:53:32 -0800 (PST) Received: from [192.168.255.135] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by mx.google.com with ESMTPS id s7sm8538920paz.7.2012.12.03.11.53.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 11:53:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> Date: Mon, 3 Dec 2012 11:53:47 -0800 Message-Id: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> To: "Santiago Alvarez (saalvare)" X-Mailer: Apple Mail (2.1499) Cc: "mpls@ietf.org" , "pwe3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:53:35 -0000 --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I echo what Santiago had said in his email. Good to have an = informational document and do not support the idea of standardizing the = intervals. -sam On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" = wrote: > Applicability of BFD is pretty wide. Mandating a set of intervals = driven by Y.1731 doesn=92t sound like a good idea to me. Having lived = through most of the BFD CC interop testing in the context of MPLS-TP, I = can see some value in having an informational doc that would discuss = interval configuration and interoperability. > Cheers. > =20 > SA > -- > =20 > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Gregory Mirsky > Sent: Monday, December 03, 2012 11:33 AM > To: Marc Binderberger; Shahram Davari > Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 > =20 > Dear Shahram, Marc, et al., > I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and = PWE3 WGs have a stake in this discussion. > I agree that compatibility with intervals standardized for Ether OAM = (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll = note that even with the same transmission intervals failure detection in = BFD-based CC/CV and Ether OAM is different time interval. Not by much = but different nevertheless. > And I agree with Marc that BFD-based CC is not only for packet or = Ethernet transport applications. And more values of transmission = interval are useful. That is why I believe that we should not = standardize any values, at least not on Standard Track. At most it could = be an informational document. Or, which will be great, have a survey = among providers on what interval values being used (similar to great = survey on PWE VCCV Control Channels). > =20 > Regards, > Greg > =20 > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Marc Binderberger > Sent: Monday, December 03, 2012 11:08 AM > To: Shahram Davari > Cc: rtg-bfd@ietf.org > Subject: Re: Commenst on draft-akiya-bfd-intervals-03 >=20 > Hello Shahram, > =20 > thanks for re-vitalizing this discussion - must admit I was busy with = too many other things. > =20 > I do agree with including the values you mention in the list of BFD = supported values, although I question the large values. > =20 > On the other hand: we are not re-inventing Ethernet OAM and we _have_ = BFD implementations out there. So we likely need to support other values = as well to fit into the existing world. > =20 > =20 > Regards, Marc > =20 > =20 > =20 > =20 > =20 > On 2012-12-03, at 20:02 , Shahram Davari wrote: >=20 >=20 > Hi, > I would like to propose standardizing the same intervals as = Y.1731/802.1ag for BFD. This would make the total L2, L3 OAM more = homogeneous. So the proposal is: > 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min. > Thank you, > Shharam > =20 > -- > Marc Binderberger > =20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I echo what Santiago had said = in his email. Good to have an informational document and do not support = the idea of standardizing the = intervals.

-sam
On Dec 3, 2012, at 11:48 = AM, "Santiago Alvarez (saalvare)" <saalvare@cisco.com> = wrote:

Applicability of BFD is = pretty wide.  Mandating a set of intervals driven by Y.1731 doesn=92t= sound like a good idea to me.  Having lived through most of the = BFD CC interop testing in the context of MPLS-TP, I can see some value = in having an informational doc that would discuss interval configuration = and interoperability.
Cheers.
 
--
 
 mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Monday, December 03, 2012 = 11:33 AM
To: Marc Binderberger; Shahram = Davari
Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Commenst on = draft-akiya-bfd-intervals-03
 
Dear Shahram, Marc, et al.,
I think that since BFD is the CC/CV part of = MPLS-TP OAM both MPLS and PWE3 WGs have a stake in this = discussion.
I agree that compatibility with intervals standardized for Ether = OAM (CFM/Y.1731) makes sense and might be helpful in interworking. But = I'll note that even with the same transmission intervals failure = detection in BFD-based CC/CV and Ether OAM is different time interval. = Not by much but different nevertheless.
And I agree with Marc that BFD-based CC is = not only for packet or Ethernet transport applications. And more values = of transmission interval are useful. That is why I believe that we = should not standardize any values, at least not on Standard Track. At = most it could be an informational document. Or, which will be great, = have a survey among providers on what interval values being used = (similar to great survey on PWE VCCV Control = Channels).
        = Greg

 rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc = Binderberger
Sent: Monday, December 03, 2012 = 11:08 AM
To: Shahram = Davari
Cc:  Re: Commenst on = draft-akiya-bfd-intervals-03


= --Apple-Mail=_4F8976CD-6F1E-4E09-A3D6-12385AED612B-- From Rolf.Winter@neclab.eu Mon Dec 3 12:10:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CACA21F885A for ; Mon, 3 Dec 2012 12:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPql7BLThBbr for ; Mon, 3 Dec 2012 12:10:32 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B0BB621F884A for ; Mon, 3 Dec 2012 12:10:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A6576102820; Mon, 3 Dec 2012 21:10:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1W8lSGneuEy; Mon, 3 Dec 2012 21:10:30 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7AF0110281F; Mon, 3 Dec 2012 21:10:15 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 21:10:01 +0100 From: Rolf Winter To: Shahram Davari Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNxlMXKWb9xeipk0ykh7jRLlQh+ZfxTQkAgAHCTQCAAOTmgIAAXp2AgABi/fCAAA0igIAHi3cAgAMdCoCAABe0gIAHqEqAgAAMUACAAF+SUA== Date: Mon, 3 Dec 2012 20:10:01 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broadcom.com> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:10:33 -0000 But the MIP that is addressed needs to be able to handle this _plus_ take a= n appropriate action and in the P2MP case this will always be the case sinc= e there are 2 or more out MIPs. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Montag, 3. Dezember 2012 16:27 > To: Rolf Winter > Cc: Pablo Frank; mpls@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > Hi Rolf, >=20 > Your HW guys are correct as long as the amount of data sent to the in- > MIP processor is not much. But from your previous email to Loa I see > that you want to also terminate CV at MIPs. CVs are fast and high > bandwidth and blindly dumping them on a CPU or OAM processor that may > not be expecting them is like DoS attack. >=20 >=20 >=20 > Regards, > Shahram >=20 >=20 > On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > wrote: >=20 > > Hi, > > > > sorry for the belated response. I checked with some of our HW people. > Here's the gist of their response: > > > > Of course they wouldn't like parsing TLVs but we established that > fact already. Their answer to the problem is slightly different though. > A TTL-expired OAM frame can simply be copied and forwarded to the out- > MIPs where, if the frame is not intended for them, it can safely be > dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the > implementation must behave in this exact way in either case. So there > is at least one way to implement this at line rate without going back > and changing a bunch of RFCs. > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of Shahram Davari > >> Sent: Mittwoch, 28. November 2012 18:46 > >> To: Pablo Frank > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-mip- mep-map > >> > >> Pablo, > >> > >> > >> > >> That was exactly my point. Let's use a flag to indicate in-MIP or > >> out- MIP and then the offline processor can do MEPID lookup to > >> determine whether this is a legitimate OAM packet or not. > >> > >> > >> > >> Thx > >> Shahram > >> > >> > >> > >> From: Pablo Frank [mailto:pabloisnot@gmail.com] > >> Sent: Wednesday, November 28, 2012 8:22 AM > >> To: Shahram Davari > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-mip- mep-map > >> > >> > >> > >> I think Shahram raises a very legitimate concern about how expensive > >> this could be to implement in hardware. > >> > >> > >> > >> As I understand it, the logic proposed by this draft is as follows: > >> > >> > >> > >> At the ingress blade: > >> > >> > >> > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> > >> Parse MIP-ID TLV > >> > >> Lookup MIP-ID > >> > >> IF MIP-is-egress, THEN > >> > >> forward normally (but note we must intercept it again on > egress) > >> > >> ELSE > >> > >> punt to OAM processor > >> > >> > >> > >> At the egress blade: > >> > >> > >> > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> > >> Parse MIP-ID TLV > >> > >> Lookup MIP-ID > >> > >> IF MIP-is-egress, THEN > >> > >> punt to OAM processor > >> > >> ELSE > >> > >> drop > >> > >> > >> > >> Note all this has to be done in the fast-path now at full line rate > >> (and hardware guys hate TLVs). Before, the only thing the fast-path > >> had to do was look for TTL-expiry. > >> > >> > >> > >> The only reason that ACH reserved bit was rejected (in Appendix A.4 > >> of > >> -03 version of doc) was because it also required a MIP-ID lookup. > >> But I don't see anything wrong with combining both mechanisms. > >> Ideally, hardware could rely on the reserved bit to do the initial > >> filtering at full line-rate and then a presumably much more > >> cost-efficient OAM hardware block could perform the MIP-ID lookup. > >> Instead of the complex logic above, the fast path gets a simple > >> modification to TTL handling and the OAM block does the heavy > lifting of dealing with ACH TLVs, etc. > >> > >> > >> > >> This seems like a case where practicality should trump elegance. > >> > >> > >> > >> regards, > >> > >> Pablo > >> > >> > >> > >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > >> > >> wrote: > >> > >> > >> > >> > Rolf, > >> > > >> > I am sure you know that TLVs are not Hardware friendly. And I > >> think you agree with me that this draft requires deep parsing of all > >> packets at line rate to get to the MIPID TLV. > >> > > >> > I still think the MIPID TLV is required to decide whether an > OAM > >> packet ended up at the right MIP. But may be a simpler solution > >> could be augmented to decide between In-MIP and Out-MIP. For example > >> how about using one of the reserved bits in the ACH header. This > can > >> easily be done in hardware with minimum complexity. > >> > > >> > Regards, > >> > Shahram > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf Of Rolf Winter > >> > Sent: Wednesday, November 21, 2012 12:13 PM > >> > To: S. Davari; adrian@olddog.co.uk > >> > Cc: mpls@ietf.org > >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- > >> tp-mip-mep-map > >> > > >> > Hi, > >> > > >> >> Hi Adrian, > >> >> > >> >> You are right and I should have sent these types of comments > >> before > >> >> last call. I completely understand the procedure. > >> >> > >> >> One thing I didn't understand in your response is that you > said > >> in-MIP > >> >> requires to do the MEPID lookup at line rate anyway. Why is > >> that? > >> >> > >> >> My understanding is that before this draft, the process would > >> have > >> >> been for the ingress to look at TTL and if it is expired then > >> send the > >> >> packet to OAM processor. > >> > > >> > Yes (and no). While I assume likely MIP functionality will be > >> implemented on the ingress, the related RFCs are vague about the > >> actual placement of the MIP function. See e.g. the OAM Framework > (RFC > >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified > >> location within the node)". > >> > > >> > Also, I think "before this draft" is not quite accurate in that > >> is suggests there is no per-interface MIP addressing possible as of > now. > >> Take RFC 6426. In practice this is where part of the problem lies. > We > >> cannot really go back and change all this. There are other > constraints. > >> E.g. we have a requirement to address a single out-MIP out of a set > >> of out-MIPs on a P2MP branch point. So this was part of the > >> constraints we worked with. > >> > > >> >> > >> >> The MEPID that you suggest in this draft is very useful for > >> filtering > >> >> out leaked OAM frames from upstream. But lets leave lookup of > >> the MEPID > >> >> to the OAM processing module (at slower rate) and add an > >> indicator to > >> >> the OAM packet to indicate whether it should be taken out of > >> the data > >> >> path in the Ingress or egress. > >> >> > >> >> So can I suggest adding the following text to the draft: > >> >> > >> >> " In addition to the MEPID, which is used to ultimately accept > >> or > >> >> filter out received OAM packets, OAM packets should have a > >> simple > >> >> indicator that identifies whether the OAM packet belongs to > >> in-MIP or > >> >> Out-MIP". > >> > > >> > We also have the question on where to retrofit those bits. I > >> assume a TLV wouldn't work for the exact reasons you do not like to > >> have to do a second lookup, since it would require some parsing. All > >> these constraints and the ones outlined in the document led to where > >> we are. In a sense this is a non-spec since it rather rules out a > >> number of things that seem like a good idea at first but then have a > >> catch of some sort. > >> > > >> > Best, > >> > > >> > Rolf > >> > > >> >> > >> >> > >> >> > >> >> Regards, > >> >> Shahram > >> >> > >> >> > >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > >> > >> >> wrote: > >> >> > >> >>> > >> >>> > >> >>> Hi Shahram, > >> >>> > >> >>> I am worried about the precedent of a comment like this > during > >> WG > >> >> last call. > >> >>> While comments that improve the document or point out > >> fundamental > >> >>> flaws are welcome whenever they arrive, points with the > >> flavour "I > >> >>> wouldn't have done it like this" that arrive this late in the > >> process > >> >> don't feel very constructive. > >> >>> But I will leave the chair to worry about process and try to > >> address > >> >>> the technical points... > >> >>> > >> >>>> Identifying whether to terminate an OAM packet and process > it > >> in In- > >> >> MIP vs. > >> >>> Out- > >> >>>> MIP requires line rate lookup, otherwise the OAM packet will > >> not > >> >> take > >> >>>> the same path as data packets. Therefore any MIP identifier > >> that is > >> >>>> proposed in this > >> >>> draft > >> >>>> requires one extra lookup and therefore adds significantly > to > >> cost. > >> >>> > >> >>> If I am not wrong, this is a feature of an out-MIP. If you > >> decide to > >> >>> implement out-MIPs, and if you want the OAM to follow exactly > >> the > >> >> same > >> >>> path as the data, then it is a requirement that the out > >> interface > >> >>> inspects the packets (at line > >> >>> rate) to determine whether they are OAM and targeted at the > >> interface. > >> >>> > >> >>> We cannot change that aspect. All we can do is aim to make > the > >> lookup > >> >>> as easy as possible. > >> >>> > >> >>>> Perhaps a > >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain > >> Level) may be > >> >>>> used that requires only 3 bits and achieves the same result. > >> >>> > >> >>> Perhaps it could. > >> >>> But before going there, why is the lookup in the current > >> version of > >> >>> the I-D arduous? > >> >>> > >> >>> Presumably you do not propose making any change to the way > >> In-MIPs > >> >> are > >> >>> currently identified, so the lookups being done at line rate > >> today on > >> >>> the incoming interfaces will not be changed. If you are > >> proposing > >> >> such > >> >>> a change, then the discussion is outside the scope of this I- > >> D and > >> >>> becomes a much wider question for the working group. > >> >>> > >> >>> This leaves me with the trade-off of enabling a *simpler* > >> lookup on > >> >>> the outgoing interfaces versus doing identical lookups on > both > >> >>> interfaces. My assumption was that if the incoming interface > >> can do > >> >>> the lookup at line rate, it is not hard to perform the same > >> lookup on > >> >>> the outgoing interface. Furthermore, there is a reduction in > >> >> complexity by having fewer things to look up. > >> >>> > >> >>> Another possibility is that the full lookup could be done on > >> the > >> >>> incoming interface and the packet marked for easy > interception > >> on the > >> >> outgoing interface. > >> >>> The concern with this approach is that the packet would no > >> longer be > >> >>> being forwarded exactly as data because it would be being > >> modified in > >> >> flight. > >> >>> Furthermore, in the case of P2MP, it is not enough to flag > the > >> packet > >> >>> as a local Out-MIP and further identifier-based lookup is > >> needed. > >> >>> > >> >>> Some of these issues were raised and discussed as the I-D > >> progressed, > >> >>> and some of the alternative solutions were tracked with their > >> pros > >> >> and > >> >>> cons in Appendix A of the I-D (look at revision -03). > >> >>> > >> >>> Thanks, > >> >>> Adrian > >> >>>> -----Original Message----- > >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >> Behalf > >> >>>> Of Adrian Farrel > >> >>>> Sent: Monday, November 19, 2012 8:45 AM > >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> ; > >> >>> draft-ietf-mpls-tp-mip- > >> >>>> mep-map@tools.ietf.org > >> >>>> Subject: Re: [mpls] working group last call on > >> >>>> draft-ietf-mpls-tp-mip-mep-map > >> >>>> > >> >>>> Yeah, it's a boring draft. Did you expect me to co-author > >> anything > >> >> else? > >> >>>> > >> >>>> The point was that when I started the I-D lots of people > were > >> saying > >> >>>> "it's complex" and "it can't be done" and "it won't be > >> backward > >> >> compatible". > >> >>>> > >> >>>> So the I-D says "here it is" > >> >>>> > >> >>>> A (sorry not to offer you excitement) > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] > >> >>>>> Sent: 19 November 2012 12:38 > >> >>>>> To: Loa Andersson; mpls@ietf.org > >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> ; MPLS-TP ad > >> >>>>> hoc > >> >>> team; > >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > >> >>>>> Subject: Re: [mpls] working group last call on > >> >>> draft-ietf-mpls-tp-mip-mep-map > >> >>>>> > >> >>>>> After getting to section 6 and its features (requirements!), > >> I find > >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is > >> >>>>> Informational and not Standards Track. > >> >>>>> > >> >>>>> Meanwhile, I suggest some editorial issues. > >> >>>>> > >> >>>>> Title > >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > >> [Handling > >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more > >> >>>>> informative statement unless and until you get to the > >> definition of > >> >>>>> Internal in s3; and s6, which is the crux of the document > >> says The > >> >>>>> preferred solution to per-interface MIP message handling is > >> >>>>> presented in this section] > >> >>>>> > >> >>>>> s1 > >> >>>>> two (or more) MIPs per node on both sides of the forwarding > >> engine. > >> >>>>> [two on both sides sounds like four in total to me; suggest > >> 'one on > >> >>>>> each side of the forwarding engine'] > >> >>>>> > >> >>>>> s4 > >> >>>>> o CV between a MEP and a MIP > >> >>>>> [expand CV on first use] > >> >>>>> > >> >>>>> s5 > >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for > >> MPLS-TP > >> >>>>> LSPs and MPLS-TP PWs, respectively. > >> >>>>> ['respectively' suggests to me that there should be two > >> precedents, > >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 > for > >> LSPs, > >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this > sentence > >> as > >> >>>>> redundant] > >> >>>>> > >> >>>>> s6 > >> >>>>> The appendix of this document contains a > >> >>>>> few solutions that the authors have discarded which have > >> been > >> >> left in > >> >>>>> the document for informational purposes. > >> >>>>> [not any more they haven't!] > >> >>>>> > >> >>>>> The node itself is addresses > >> >>>>> [The node itself is addressed] > >> >>>>> > >> >>>>> The identification information indside [The identification > >> >>>>> information inside ] > >> >>>>> > >> >>>>> MIP identifiers are not know > >> >>>>> [MIP identifiers are not known] > >> >>>>> > >> >>>>> reserved MIP address > >> >>>>> [reserved MIP addressses or a reserved MIP address] > >> >>>>> > >> >>>>> Tom Petch > >> >>>>> > >> >>>>> > >> >>>>> ----- Original Message ----- > >> >>>>> From: "Loa Andersson" > >> >>>>> To: > >> >>>>> Cc: ; >> chairs@tools.ietf.org>; > >> >>>>> "MPLS-TP ad hoc team" ; > >> >>>>> > >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM > >> >>>>> > >> >>>>>> Working Group, > >> >>>>>> > >> >>>>>> This is to start a 2 week working group last call on > >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. > >> >>>>>> > >> >>>>>> Please send your comments to the mpls working group > mailing > >> list > >> >>>>>> (mpls@ietf.org). > >> >>>>>> > >> >>>>>> Please send both technical comments, and if you are happy > >> with the > >> >>>>>> document as is also indications of support. > >> >>>>>> > >> >>>>>> This working group last call will end on November 28. > >> >>>>>> > >> >>>>>> /Loa > >> >>>>>> for the wg co-chairs > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> mpls mailing list > >> >>>> mpls@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/mpls > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> mpls mailing list > >> >>> mpls@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mpls > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > >> Road, London W3 6BL | Registered in England 2832014 > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > From Rolf.Winter@neclab.eu Mon Dec 3 12:15:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7361721F884A for ; Mon, 3 Dec 2012 12:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCWl7LOxcz4E for ; Mon, 3 Dec 2012 12:15:57 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3B021F8775 for ; Mon, 3 Dec 2012 12:15:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BC76A102823; Mon, 3 Dec 2012 21:15:56 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3Pv4nKbpOAm; Mon, 3 Dec 2012 21:15:56 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9120110281F; Mon, 3 Dec 2012 21:15:26 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 21:15:05 +0100 From: Rolf Winter To: Gregory Mirsky , Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLCAAD1PAIAAL8Jw Date: Mon, 3 Dec 2012 20:14:51 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:15:58 -0000 Hi Greg, But that's the whole point of the document. There can be multiple in- and o= ut-MIPs per LSP plus in the P2MP case there can be multiple out-MIPs per no= de. It cannot be based local configuration. There has to be information ins= ide the OAM frame to address the respective MIP. Section 4 of the document = has a (I believe) pretty good example of this. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Montag, 3. Dezember 2012 19:20 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Rolf, > Do you envision that multiple MIPs, both in- and out-, required to be > supported on a given LSP/PW? I think that only single MIP required > per LSP/PW on an LSR/PE node. If that is the case, then there might be > no apparent need to explicitly address in- and out- MIP as such > distinction becomes part of local configuration. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Monday, December 03, 2012 5:42 AM > To: Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > Loa, >=20 > These have been mentioned: >=20 > 1. CV between a MEP and a MIP > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs > 3. data-plane loopback configuration at a MIP 4. diagnostic tests >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Freitag, 30. November 2012 11:41 > > To: mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; draft-ietf-mpls-tp- > > mip-mep-map@tools.ietf.org; mpls-ads@tools.ietf.org > > Subject: Re: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Authors, > > > > Can you plese give me an indication of which OAM functions the > > separation of in and out MIPs are intended for? > > > > /Loa > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > Working Group, > > > > > > This is to start a 2 week working group last call on > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > Please send your comments to the mpls working group mailing list > > > (mpls@ietf.org). > > > > > > Please send both technical comments, and if you are happy with the > > > document as is also indications of support. > > > > > > This working group last call will end on November 28. > > > > > > /Loa > > > for the wg co-chairs > > > > > > > > > > -- > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Mon Dec 3 12:46:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C06021F8890 for ; Mon, 3 Dec 2012 12:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brjhw1c7x0JB for ; Mon, 3 Dec 2012 12:46:47 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA94F21F888E for ; Mon, 3 Dec 2012 12:46:46 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB3KtpF3005168; Mon, 3 Dec 2012 14:55:53 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0712.eamcs.ericsson.se (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Dec 2012 15:46:39 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 15:46:39 -0500 From: Gregory Mirsky To: Rolf Winter , Loa Andersson , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0VxJlaR5XVhT/UaZmQSyL/75l5gHYOjwgAB15ID//6/AQA== Date: Mon, 3 Dec 2012 20:46:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11201E9F9eusaamb103ericsso_" MIME-Version: 1.0 Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 20:46:48 -0000 --_000_7347100B5761DC41A166AC17F22DF11201E9F9eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, I've been thinking about that requirement for some time and am not convince= d that such requirement, support multiple MIP per LSP/PW on given LSR/PE, e= xists. AFAIK, in Ethernet OAM only support of single MIP per MD/MEG Level i= s required and support of multiple MIPs is optional. True, multiple MIPs of= different MD/MEG Levels might be enabled on a node but in MPLS-TP we use S= PME to model MD/MEG Levels and thus such MIPs are on different LSPs. As for= p2mp case, I'm not sure how dat-plane loopback can be used on uni-directio= nal construct. Regards, Greg -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] Sent: Monday, December 03, 2012 12:15 PM To: Gregory Mirsky; Loa Andersson; mpls@ietf.org Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp= -mip-mep-map@tools.ietf.org Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map Hi Greg, But that's the whole point of the document. There can be multiple in- and o= ut-MIPs per LSP plus in the P2MP case there can be multiple out-MIPs per no= de. It cannot be based local configuration. There has to be information ins= ide the OAM frame to address the respective MIP. Section 4 of the document = has a (I believe) pretty good example of this. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Montag, 3. Dezember 2012 19:20 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map > > Hi Rolf, > Do you envision that multiple MIPs, both in- and out-, required to be > supported on a given LSP/PW? I think that only single MIP required > per LSP/PW on an LSR/PE node. If that is the case, then there might be > no apparent need to explicitly address in- and out- MIP as such > distinction becomes part of local configuration. > > Regards, > Greg > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Rolf Winter > Sent: Monday, December 03, 2012 5:42 AM > To: Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map > > Loa, > > These have been mentioned: > > 1. CV between a MEP and a MIP > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Freitag, 30. November 2012 11:41 > > To: mpls@ietf.org > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > mpls-ads@tools.ietf.org > > Subject: Re: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Authors, > > > > Can you plese give me an indication of which OAM functions the > > separation of in and out MIPs are intended for? > > > > /Loa > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > Working Group, > > > > > > This is to start a 2 week working group last call on > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > Please send your comments to the mpls working group mailing list > > > (mpls@ietf.org). > > > > > > Please send both technical comments, and if you are happy with the > > > document as is also indications of support. > > > > > > This working group last call will end on November 28. > > > > > > /Loa > > > for the wg co-chairs > > > > > > > > > > -- > > > > > > Loa Andersson email: > loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF11201E9F9eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rolf,
I've been thinking about that requirement for some time and am not con= vinced that such requirement, support multiple MIP per LSP/PW on given LSR/= PE, exists. AFAIK, in Ethernet OAM only support of single MIP per MD/MEG Le= vel is required and support of multiple MIPs is optional. True, multiple MIPs of different MD/MEG Levels might be e= nabled on a node but in MPLS-TP we use SPME to model MD/MEG Levels and thus= such MIPs are on different LSPs. As for p2mp case, I'm not sure how dat-pl= ane loopback can be used on uni-directional construct.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Monday, December 03, 2012 12:15 PM
To: Gregory Mirsky; Loa Andersson; mpls@ietf.org
Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mp= ls-tp-mip-mep-map@tools.ietf.org
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map=
 
Hi Greg,
 
But that's the whole point of the document. There can be multiple in- = and out-MIPs per LSP plus in the P2MP case there can be multiple out-MIPs p= er node. It cannot be based local configuration. There has to be informatio= n inside the OAM frame to address the respective MIP. Section 4 of the document has a (I believe) pretty good= example of this.
 
Best,
 
Rolf
 
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
 
 
> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Montag, 3. Dezember 2012 19:20
> To: Rolf Winter; Loa Andersson; mpls@ietf.org
> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ie= tf-
> mpls-tp-mip-mep-map@tools.ietf.org
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-me= p-map
>
> Hi Rolf,
> Do you envision that multiple MIPs, both in- and out-, required t= o be
> supported on a given LSP/PW? I think that    = only single MIP required
> per LSP/PW on an LSR/PE node. If that is the case, then there mig= ht be
> no apparent need to explicitly address in- and out- MIP as such <= /div>
> distinction becomes part of local configuration.
>
>        Regards,
>           =      Greg
>
> -----Original Message-----
> Of Rolf Winter
> Sent: Monday, December 03, 2012 5:42 AM
> To: Loa Andersson; mpls@ietf.org
> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ie= tf-
> mpls-tp-mip-mep-map@tools.ietf.org
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp= -mip-
> mep-map
>
> Loa,
>
> These have been mentioned:
>
> 1. CV between a MEP and a MIP
> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing= MIPs
> 3. data-plane loopback configuration at a MIP 4. diagnostic tests=
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d,
> London W3 6BL | Registered in England 2832014
>
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.nu]
> > Sent: Freitag, 30. November 2012 11:41
> > To: mpls@ietf.org
> > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux;
> > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org;
> > mpls-ads@tools.ietf.org
> > Subject: Re: working group last call on draft-ietf-mpls-tp-m= ip-mep-
> map
> >
> > Authors,
> >
> > Can you plese give me an indication of which OAM functions t= he
> > separation of in and out MIPs are intended for?
> >
> > /Loa
> >
> >
> >
> > On 2012-11-14 16:16, Loa Andersson wrote:
> > >
> > > Working Group,
> > >
> > > This is to start a 2 week working group last call on
> > > draft-ietf-mpls-tp-mip-mep-map.
> > >
> > > Please send your comments to the mpls working group mai= ling list
> > > (mpls@ietf.org).
> > >
> > > Please send both technical comments, and if you are hap= py with the
> > > document as is also indications of support.
> > >
> > > This working group last call will end on November 28.
> > >
> > > /Loa
> > > for the wg co-chairs
> > >
> > >
> >
> > --
> >
> >
> > Loa Andersson        = ;            &n= bsp;    email:
> loa.andersson@ericsson.com
> > Sr Strategy and Standards Manager    &nb= sp;       loa@pi.nu
> > Ericsson Inc        =             &nb= sp;     phone: +46 10 717 52 13
> >          &= nbsp;           &nbs= p;            &= nbsp;           +46 7= 67 72 92 13
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
 
 --_000_7347100B5761DC41A166AC17F22DF11201E9F9eusaamb103ericsso_-- From davari@broadcom.com Mon Dec 3 15:06:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051021F87DB for ; Mon, 3 Dec 2012 15:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.502 X-Spam-Level: X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLn69wKF8001 for ; Mon, 3 Dec 2012 15:06:39 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id C81C821F87E7 for ; Mon, 3 Dec 2012 15:06:39 -0800 (PST) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 15:03:38 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 15:06:25 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 15:06:25 -0800 From: "Shahram Davari" To: "Rolf Winter" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsKeQf/mKl4u0SUtKP+ZUNj/pfxIUQJgADKVACAATqdcIABbJeAgABenYCAAFjlgP//jqnggAgUCACAAx0KgP//kH6wgAghlgD//5QedQAaqJaAAAusJQA= Date: Mon, 3 Dec 2012 23:06:24 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broadcom.com> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broadcom.com> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CA3F0403R014212020-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 23:06:41 -0000 Rolf, For clarity it is better to use an example. Assume that an LSR has 4 ports = (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from= port A and forwards them to port B. there can only be 3 configurations: 1) MIP on port A (In-MIP), or 2) MIP on port B (out-MIP), or 3) MEIP on Port A and B =20 A single OAM packet can be terminated and processed only by one of these MI= Ps. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). In yo= ur example, you are saying send a copy of the P to the CPU/Processor on Por= t A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop = the packet since the MIP-ID is not A. The issue is that each CPU/processor= has limited resources. By sending all OAM MIP packets to both processor y= ou are losing 1/2 of the capacity of each processor. The practical solutio= n is to have a simple indicator in the packet header that this OAM packet i= s meant for Out-MIP. Then port A just switches the OAM packet to Port B, an= d Port B terminates and sends it to its CPU/processor. Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip f= rom Port A and is sent to ports B, C, D. Also assume that there is In-MIP = on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM = packet is meant for out-MIPs (B, C). In such case the OAM packet should no= t be sent to port A CPU/Processor. It is therefore multicast to ports B, C,= D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packe= ts and does not send it to its CPU, since there is no MIP configured for th= at MPLS label. So the Pseudo-code is like this: Ingress Port: If packet is OAM and TTL=3D1 If MIP is enabled If packet indicates In-MIP Send to local CPU Else Forward to egress port End Else Forward normally End Else Egress Port: If packet is OAM and TTL=3D1 If MIP is enabled If packet indicates In-MIP Drop packet Else If packet indicates Out-MIP Send to local CPU End Else Drop packet End End =09 Using this example could you please describe your reasoning for not requiri= ng HW to identify In-MEP vs out-MIPs? Thanks Shahram -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 Sent: Monday, December 03, 2012 12:10 PM To: Shahram Davari Cc: Pablo Frank; mpls@ietf.org Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-m= ap But the MIP that is addressed needs to be able to handle this _plus_ take a= n appropriate action and in the P2MP case this will always be the case sinc= e there are 2 or more out MIPs. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Montag, 3. Dezember 2012 16:27 > To: Rolf Winter > Cc: Pablo Frank; mpls@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > Hi Rolf, >=20 > Your HW guys are correct as long as the amount of data sent to the in- > MIP processor is not much. But from your previous email to Loa I see > that you want to also terminate CV at MIPs. CVs are fast and high > bandwidth and blindly dumping them on a CPU or OAM processor that may > not be expecting them is like DoS attack. >=20 >=20 >=20 > Regards, > Shahram >=20 >=20 > On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > wrote: >=20 > > Hi, > > > > sorry for the belated response. I checked with some of our HW people. > Here's the gist of their response: > > > > Of course they wouldn't like parsing TLVs but we established that > fact already. Their answer to the problem is slightly different though. > A TTL-expired OAM frame can simply be copied and forwarded to the out- > MIPs where, if the frame is not intended for them, it can safely be > dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the > implementation must behave in this exact way in either case. So there > is at least one way to implement this at line rate without going back > and changing a bunch of RFCs. > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of Shahram Davari > >> Sent: Mittwoch, 28. November 2012 18:46 > >> To: Pablo Frank > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-mip- mep-map > >> > >> Pablo, > >> > >> > >> > >> That was exactly my point. Let's use a flag to indicate in-MIP or > >> out- MIP and then the offline processor can do MEPID lookup to > >> determine whether this is a legitimate OAM packet or not. > >> > >> > >> > >> Thx > >> Shahram > >> > >> > >> > >> From: Pablo Frank [mailto:pabloisnot@gmail.com] > >> Sent: Wednesday, November 28, 2012 8:22 AM > >> To: Shahram Davari > >> Cc: mpls@ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-mip- mep-map > >> > >> > >> > >> I think Shahram raises a very legitimate concern about how expensive > >> this could be to implement in hardware. > >> > >> > >> > >> As I understand it, the logic proposed by this draft is as follows: > >> > >> > >> > >> At the ingress blade: > >> > >> > >> > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> > >> Parse MIP-ID TLV > >> > >> Lookup MIP-ID > >> > >> IF MIP-is-egress, THEN > >> > >> forward normally (but note we must intercept it again on > egress) > >> > >> ELSE > >> > >> punt to OAM processor > >> > >> > >> > >> At the egress blade: > >> > >> > >> > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> > >> Parse MIP-ID TLV > >> > >> Lookup MIP-ID > >> > >> IF MIP-is-egress, THEN > >> > >> punt to OAM processor > >> > >> ELSE > >> > >> drop > >> > >> > >> > >> Note all this has to be done in the fast-path now at full line rate > >> (and hardware guys hate TLVs). Before, the only thing the fast-path > >> had to do was look for TTL-expiry. > >> > >> > >> > >> The only reason that ACH reserved bit was rejected (in Appendix A.4 > >> of > >> -03 version of doc) was because it also required a MIP-ID lookup. > >> But I don't see anything wrong with combining both mechanisms. > >> Ideally, hardware could rely on the reserved bit to do the initial > >> filtering at full line-rate and then a presumably much more > >> cost-efficient OAM hardware block could perform the MIP-ID lookup. > >> Instead of the complex logic above, the fast path gets a simple > >> modification to TTL handling and the OAM block does the heavy > lifting of dealing with ACH TLVs, etc. > >> > >> > >> > >> This seems like a case where practicality should trump elegance. > >> > >> > >> > >> regards, > >> > >> Pablo > >> > >> > >> > >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > >> > >> wrote: > >> > >> > >> > >> > Rolf, > >> > > >> > I am sure you know that TLVs are not Hardware friendly. And I > >> think you agree with me that this draft requires deep parsing of all > >> packets at line rate to get to the MIPID TLV. > >> > > >> > I still think the MIPID TLV is required to decide whether an > OAM > >> packet ended up at the right MIP. But may be a simpler solution > >> could be augmented to decide between In-MIP and Out-MIP. For example > >> how about using one of the reserved bits in the ACH header. This > can > >> easily be done in hardware with minimum complexity. > >> > > >> > Regards, > >> > Shahram > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> Behalf Of Rolf Winter > >> > Sent: Wednesday, November 21, 2012 12:13 PM > >> > To: S. Davari; adrian@olddog.co.uk > >> > Cc: mpls@ietf.org > >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- > >> tp-mip-mep-map > >> > > >> > Hi, > >> > > >> >> Hi Adrian, > >> >> > >> >> You are right and I should have sent these types of comments > >> before > >> >> last call. I completely understand the procedure. > >> >> > >> >> One thing I didn't understand in your response is that you > said > >> in-MIP > >> >> requires to do the MEPID lookup at line rate anyway. Why is > >> that? > >> >> > >> >> My understanding is that before this draft, the process would > >> have > >> >> been for the ingress to look at TTL and if it is expired then > >> send the > >> >> packet to OAM processor. > >> > > >> > Yes (and no). While I assume likely MIP functionality will be > >> implemented on the ingress, the related RFCs are vague about the > >> actual placement of the MIP function. See e.g. the OAM Framework > (RFC > >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified > >> location within the node)". > >> > > >> > Also, I think "before this draft" is not quite accurate in that > >> is suggests there is no per-interface MIP addressing possible as of > now. > >> Take RFC 6426. In practice this is where part of the problem lies. > We > >> cannot really go back and change all this. There are other > constraints. > >> E.g. we have a requirement to address a single out-MIP out of a set > >> of out-MIPs on a P2MP branch point. So this was part of the > >> constraints we worked with. > >> > > >> >> > >> >> The MEPID that you suggest in this draft is very useful for > >> filtering > >> >> out leaked OAM frames from upstream. But lets leave lookup of > >> the MEPID > >> >> to the OAM processing module (at slower rate) and add an > >> indicator to > >> >> the OAM packet to indicate whether it should be taken out of > >> the data > >> >> path in the Ingress or egress. > >> >> > >> >> So can I suggest adding the following text to the draft: > >> >> > >> >> " In addition to the MEPID, which is used to ultimately accept > >> or > >> >> filter out received OAM packets, OAM packets should have a > >> simple > >> >> indicator that identifies whether the OAM packet belongs to > >> in-MIP or > >> >> Out-MIP". > >> > > >> > We also have the question on where to retrofit those bits. I > >> assume a TLV wouldn't work for the exact reasons you do not like to > >> have to do a second lookup, since it would require some parsing. All > >> these constraints and the ones outlined in the document led to where > >> we are. In a sense this is a non-spec since it rather rules out a > >> number of things that seem like a good idea at first but then have a > >> catch of some sort. > >> > > >> > Best, > >> > > >> > Rolf > >> > > >> >> > >> >> > >> >> > >> >> Regards, > >> >> Shahram > >> >> > >> >> > >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > >> > >> >> wrote: > >> >> > >> >>> > >> >>> > >> >>> Hi Shahram, > >> >>> > >> >>> I am worried about the precedent of a comment like this > during > >> WG > >> >> last call. > >> >>> While comments that improve the document or point out > >> fundamental > >> >>> flaws are welcome whenever they arrive, points with the > >> flavour "I > >> >>> wouldn't have done it like this" that arrive this late in the > >> process > >> >> don't feel very constructive. > >> >>> But I will leave the chair to worry about process and try to > >> address > >> >>> the technical points... > >> >>> > >> >>>> Identifying whether to terminate an OAM packet and process > it > >> in In- > >> >> MIP vs. > >> >>> Out- > >> >>>> MIP requires line rate lookup, otherwise the OAM packet will > >> not > >> >> take > >> >>>> the same path as data packets. Therefore any MIP identifier > >> that is > >> >>>> proposed in this > >> >>> draft > >> >>>> requires one extra lookup and therefore adds significantly > to > >> cost. > >> >>> > >> >>> If I am not wrong, this is a feature of an out-MIP. If you > >> decide to > >> >>> implement out-MIPs, and if you want the OAM to follow exactly > >> the > >> >> same > >> >>> path as the data, then it is a requirement that the out > >> interface > >> >>> inspects the packets (at line > >> >>> rate) to determine whether they are OAM and targeted at the > >> interface. > >> >>> > >> >>> We cannot change that aspect. All we can do is aim to make > the > >> lookup > >> >>> as easy as possible. > >> >>> > >> >>>> Perhaps a > >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain > >> Level) may be > >> >>>> used that requires only 3 bits and achieves the same result. > >> >>> > >> >>> Perhaps it could. > >> >>> But before going there, why is the lookup in the current > >> version of > >> >>> the I-D arduous? > >> >>> > >> >>> Presumably you do not propose making any change to the way > >> In-MIPs > >> >> are > >> >>> currently identified, so the lookups being done at line rate > >> today on > >> >>> the incoming interfaces will not be changed. If you are > >> proposing > >> >> such > >> >>> a change, then the discussion is outside the scope of this I- > >> D and > >> >>> becomes a much wider question for the working group. > >> >>> > >> >>> This leaves me with the trade-off of enabling a *simpler* > >> lookup on > >> >>> the outgoing interfaces versus doing identical lookups on > both > >> >>> interfaces. My assumption was that if the incoming interface > >> can do > >> >>> the lookup at line rate, it is not hard to perform the same > >> lookup on > >> >>> the outgoing interface. Furthermore, there is a reduction in > >> >> complexity by having fewer things to look up. > >> >>> > >> >>> Another possibility is that the full lookup could be done on > >> the > >> >>> incoming interface and the packet marked for easy > interception > >> on the > >> >> outgoing interface. > >> >>> The concern with this approach is that the packet would no > >> longer be > >> >>> being forwarded exactly as data because it would be being > >> modified in > >> >> flight. > >> >>> Furthermore, in the case of P2MP, it is not enough to flag > the > >> packet > >> >>> as a local Out-MIP and further identifier-based lookup is > >> needed. > >> >>> > >> >>> Some of these issues were raised and discussed as the I-D > >> progressed, > >> >>> and some of the alternative solutions were tracked with their > >> pros > >> >> and > >> >>> cons in Appendix A of the I-D (look at revision -03). > >> >>> > >> >>> Thanks, > >> >>> Adrian > >> >>>> -----Original Message----- > >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >> Behalf > >> >>>> Of Adrian Farrel > >> >>>> Sent: Monday, November 19, 2012 8:45 AM > >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> ; > >> >>> draft-ietf-mpls-tp-mip- > >> >>>> mep-map@tools.ietf.org > >> >>>> Subject: Re: [mpls] working group last call on > >> >>>> draft-ietf-mpls-tp-mip-mep-map > >> >>>> > >> >>>> Yeah, it's a boring draft. Did you expect me to co-author > >> anything > >> >> else? > >> >>>> > >> >>>> The point was that when I started the I-D lots of people > were > >> saying > >> >>>> "it's complex" and "it can't be done" and "it won't be > >> backward > >> >> compatible". > >> >>>> > >> >>>> So the I-D says "here it is" > >> >>>> > >> >>>> A (sorry not to offer you excitement) > >> >>>> > >> >>>>> -----Original Message----- > >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] > >> >>>>> Sent: 19 November 2012 12:38 > >> >>>>> To: Loa Andersson; mpls@ietf.org > >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> ; MPLS-TP ad > >> >>>>> hoc > >> >>> team; > >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > >> >>>>> Subject: Re: [mpls] working group last call on > >> >>> draft-ietf-mpls-tp-mip-mep-map > >> >>>>> > >> >>>>> After getting to section 6 and its features (requirements!), > >> I find > >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is > >> >>>>> Informational and not Standards Track. > >> >>>>> > >> >>>>> Meanwhile, I suggest some editorial issues. > >> >>>>> > >> >>>>> Title > >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > >> [Handling > >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more > >> >>>>> informative statement unless and until you get to the > >> definition of > >> >>>>> Internal in s3; and s6, which is the crux of the document > >> says The > >> >>>>> preferred solution to per-interface MIP message handling is > >> >>>>> presented in this section] > >> >>>>> > >> >>>>> s1 > >> >>>>> two (or more) MIPs per node on both sides of the forwarding > >> engine. > >> >>>>> [two on both sides sounds like four in total to me; suggest > >> 'one on > >> >>>>> each side of the forwarding engine'] > >> >>>>> > >> >>>>> s4 > >> >>>>> o CV between a MEP and a MIP > >> >>>>> [expand CV on first use] > >> >>>>> > >> >>>>> s5 > >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for > >> MPLS-TP > >> >>>>> LSPs and MPLS-TP PWs, respectively. > >> >>>>> ['respectively' suggests to me that there should be two > >> precedents, > >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 > for > >> LSPs, > >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this > sentence > >> as > >> >>>>> redundant] > >> >>>>> > >> >>>>> s6 > >> >>>>> The appendix of this document contains a > >> >>>>> few solutions that the authors have discarded which have > >> been > >> >> left in > >> >>>>> the document for informational purposes. > >> >>>>> [not any more they haven't!] > >> >>>>> > >> >>>>> The node itself is addresses > >> >>>>> [The node itself is addressed] > >> >>>>> > >> >>>>> The identification information indside [The identification > >> >>>>> information inside ] > >> >>>>> > >> >>>>> MIP identifiers are not know > >> >>>>> [MIP identifiers are not known] > >> >>>>> > >> >>>>> reserved MIP address > >> >>>>> [reserved MIP addressses or a reserved MIP address] > >> >>>>> > >> >>>>> Tom Petch > >> >>>>> > >> >>>>> > >> >>>>> ----- Original Message ----- > >> >>>>> From: "Loa Andersson" > >> >>>>> To: > >> >>>>> Cc: ; >> chairs@tools.ietf.org>; > >> >>>>> "MPLS-TP ad hoc team" ; > >> >>>>> > >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM > >> >>>>> > >> >>>>>> Working Group, > >> >>>>>> > >> >>>>>> This is to start a 2 week working group last call on > >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. > >> >>>>>> > >> >>>>>> Please send your comments to the mpls working group > mailing > >> list > >> >>>>>> (mpls@ietf.org). > >> >>>>>> > >> >>>>>> Please send both technical comments, and if you are happy > >> with the > >> >>>>>> document as is also indications of support. > >> >>>>>> > >> >>>>>> This working group last call will end on November 28. > >> >>>>>> > >> >>>>>> /Loa > >> >>>>>> for the wg co-chairs > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> mpls mailing list > >> >>>> mpls@ietf.org > >> >>>> https://www.ietf.org/mailman/listinfo/mpls > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> mpls mailing list > >> >>> mpls@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/mpls > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > >> Road, London W3 6BL | Registered in England 2832014 > >> > _______________________________________________ > >> > mpls mailing list > >> > mpls@ietf.org > >> > https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > From hideki.endo.es@hitachi.com Mon Dec 3 16:48:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ACD1F0C4A for ; Mon, 3 Dec 2012 16:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUmnuoIf4XPC for ; Mon, 3 Dec 2012 16:48:40 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBEC21F88B8 for ; Mon, 3 Dec 2012 16:48:40 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 364EC37AC2; Tue, 4 Dec 2012 09:48:39 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id qB40mdOA031504; Tue, 4 Dec 2012 09:48:39 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB40mcfx019481; Tue, 4 Dec 2012 09:48:38 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id ECA92140054; Tue, 4 Dec 2012 09:48:37 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB40mbH9031924; Tue, 4 Dec 2012 09:48:37 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Tue, 4 Dec 2012 09:48:14 +0900 References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> Priority: normal Importance: normal X400-Content-Identifier: X50BD483F00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121204094759O0P] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:48:42 -0000 Hi Shahram, First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests Here, CV means On-demand CV. You may misunderstand as Proactive CV. Second, you wrote; "The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. " It depends on implementations, and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. Let's consider P2MP case as you pointed out. All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processor at port D loses its capacity. If we consider the larger number of ports in the LSR which has 100 ports, for example, All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processors at the other 98 ports lose those capacities. Even if your solution using ACH header is applied, it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness in the case of P2MP for 100 ports. Thanks, Hideki Endo >Rolf, > >For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: > >1) MIP on port A (In-MIP), or >2) MIP on port B (out-MIP), or >3) MEIP on Port A and B > >A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. > >Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. > >So the Pseudo-code is like this: > >Ingress Port: > >If packet is OAM and TTL=1 > If MIP is enabled > If packet indicates In-MIP > Send to local CPU > Else > Forward to egress port > End > Else > Forward normally > End >Else > >Egress Port: > >If packet is OAM and TTL=1 > If MIP is enabled > If packet indicates In-MIP > Drop packet > Else If packet indicates Out-MIP > Send to local CPU > End > Else > Drop packet > End >End > > >Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? > >Thanks >Shahram > >-----Original Message----- >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >Sent: Monday, December 03, 2012 12:10 PM >To: Shahram Davari >Cc: Pablo Frank; mpls@ietf.org >Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map > >But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Montag, 3. Dezember 2012 16:27 >> To: Rolf Winter >> Cc: Pablo Frank; mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >> >> Hi Rolf, >> >> Your HW guys are correct as long as the amount of data sent to the in- >> MIP processor is not much. But from your previous email to Loa I see >> that you want to also terminate CV at MIPs. CVs are fast and high >> bandwidth and blindly dumping them on a CPU or OAM processor that may >> not be expecting them is like DoS attack. >> >> >> >> Regards, >> Shahram >> >> >> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >> wrote: >> >> > Hi, >> > >> > sorry for the belated response. I checked with some of our HW people. >> Here's the gist of their response: >> > >> > Of course they wouldn't like parsing TLVs but we established that >> fact already. Their answer to the problem is slightly different though. >> A TTL-expired OAM frame can simply be copied and forwarded to the out- >> MIPs where, if the frame is not intended for them, it can safely be >> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >> implementation must behave in this exact way in either case. So there >> is at least one way to implement this at line rate without going back >> and changing a bunch of RFCs. >> > >> > Best, >> > >> > Rolf >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> > London W3 6BL | Registered in England 2832014 >> > >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> >> Of Shahram Davari >> >> Sent: Mittwoch, 28. November 2012 18:46 >> >> To: Pablo Frank >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> Pablo, >> >> >> >> >> >> >> >> That was exactly my point. Let's use a flag to indicate in-MIP or >> >> out- MIP and then the offline processor can do MEPID lookup to >> >> determine whether this is a legitimate OAM packet or not. >> >> >> >> >> >> >> >> Thx >> >> Shahram >> >> >> >> >> >> >> >> From: Pablo Frank [mailto:pabloisnot@gmail.com] >> >> Sent: Wednesday, November 28, 2012 8:22 AM >> >> To: Shahram Davari >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> >> >> >> >> I think Shahram raises a very legitimate concern about how expensive >> >> this could be to implement in hardware. >> >> >> >> >> >> >> >> As I understand it, the logic proposed by this draft is as follows: >> >> >> >> >> >> >> >> At the ingress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> forward normally (but note we must intercept it again on >> egress) >> >> >> >> ELSE >> >> >> >> punt to OAM processor >> >> >> >> >> >> >> >> At the egress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> punt to OAM processor >> >> >> >> ELSE >> >> >> >> drop >> >> >> >> >> >> >> >> Note all this has to be done in the fast-path now at full line rate >> >> (and hardware guys hate TLVs). Before, the only thing the fast-path >> >> had to do was look for TTL-expiry. >> >> >> >> >> >> >> >> The only reason that ACH reserved bit was rejected (in Appendix A.4 >> >> of >> >> -03 version of doc) was because it also required a MIP-ID lookup. >> >> But I don't see anything wrong with combining both mechanisms. >> >> Ideally, hardware could rely on the reserved bit to do the initial >> >> filtering at full line-rate and then a presumably much more >> >> cost-efficient OAM hardware block could perform the MIP-ID lookup. >> >> Instead of the complex logic above, the fast path gets a simple >> >> modification to TTL handling and the OAM block does the heavy >> lifting of dealing with ACH TLVs, etc. >> >> >> >> >> >> >> >> This seems like a case where practicality should trump elegance. >> >> >> >> >> >> >> >> regards, >> >> >> >> Pablo >> >> >> >> >> >> >> >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >> >> >> >> wrote: >> >> >> >> >> >> >> >> > Rolf, >> >> > >> >> > I am sure you know that TLVs are not Hardware friendly. And I >> >> think you agree with me that this draft requires deep parsing of all >> >> packets at line rate to get to the MIPID TLV. >> >> > >> >> > I still think the MIPID TLV is required to decide whether an >> OAM >> >> packet ended up at the right MIP. But may be a simpler solution >> >> could be augmented to decide between In-MIP and Out-MIP. For example >> >> how about using one of the reserved bits in the ACH header. This >> can >> >> easily be done in hardware with minimum complexity. >> >> > >> >> > Regards, >> >> > Shahram >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> >> Behalf Of Rolf Winter >> >> > Sent: Wednesday, November 21, 2012 12:13 PM >> >> > To: S. Davari; adrian@olddog.co.uk >> >> > Cc: mpls@ietf.org >> >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- >> >> tp-mip-mep-map >> >> > >> >> > Hi, >> >> > >> >> >> Hi Adrian, >> >> >> >> >> >> You are right and I should have sent these types of comments >> >> before >> >> >> last call. I completely understand the procedure. >> >> >> >> >> >> One thing I didn't understand in your response is that you >> said >> >> in-MIP >> >> >> requires to do the MEPID lookup at line rate anyway. Why is >> >> that? >> >> >> >> >> >> My understanding is that before this draft, the process would >> >> have >> >> >> been for the ingress to look at TTL and if it is expired then >> >> send the >> >> >> packet to OAM processor. >> >> > >> >> > Yes (and no). While I assume likely MIP functionality will be >> >> implemented on the ingress, the related RFCs are vague about the >> >> actual placement of the MIP function. See e.g. the OAM Framework >> (RFC >> >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >> >> location within the node)". >> >> > >> >> > Also, I think "before this draft" is not quite accurate in that >> >> is suggests there is no per-interface MIP addressing possible as of >> now. >> >> Take RFC 6426. In practice this is where part of the problem lies. >> We >> >> cannot really go back and change all this. There are other >> constraints. >> >> E.g. we have a requirement to address a single out-MIP out of a set >> >> of out-MIPs on a P2MP branch point. So this was part of the >> >> constraints we worked with. >> >> > >> >> >> >> >> >> The MEPID that you suggest in this draft is very useful for >> >> filtering >> >> >> out leaked OAM frames from upstream. But lets leave lookup of >> >> the MEPID >> >> >> to the OAM processing module (at slower rate) and add an >> >> indicator to >> >> >> the OAM packet to indicate whether it should be taken out of >> >> the data >> >> >> path in the Ingress or egress. >> >> >> >> >> >> So can I suggest adding the following text to the draft: >> >> >> >> >> >> " In addition to the MEPID, which is used to ultimately accept >> >> or >> >> >> filter out received OAM packets, OAM packets should have a >> >> simple >> >> >> indicator that identifies whether the OAM packet belongs to >> >> in-MIP or >> >> >> Out-MIP". >> >> > >> >> > We also have the question on where to retrofit those bits. I >> >> assume a TLV wouldn't work for the exact reasons you do not like to >> >> have to do a second lookup, since it would require some parsing. All >> >> these constraints and the ones outlined in the document led to where >> >> we are. In a sense this is a non-spec since it rather rules out a >> >> number of things that seem like a good idea at first but then have a >> >> catch of some sort. >> >> > >> >> > Best, >> >> > >> >> > Rolf >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> Shahram >> >> >> >> >> >> >> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >> >> >> >> >> wrote: >> >> >> >> >> >>> >> >> >>> >> >> >>> Hi Shahram, >> >> >>> >> >> >>> I am worried about the precedent of a comment like this >> during >> >> WG >> >> >> last call. >> >> >>> While comments that improve the document or point out >> >> fundamental >> >> >>> flaws are welcome whenever they arrive, points with the >> >> flavour "I >> >> >>> wouldn't have done it like this" that arrive this late in the >> >> process >> >> >> don't feel very constructive. >> >> >>> But I will leave the chair to worry about process and try to >> >> address >> >> >>> the technical points... >> >> >>> >> >> >>>> Identifying whether to terminate an OAM packet and process >> it >> >> in In- >> >> >> MIP vs. >> >> >>> Out- >> >> >>>> MIP requires line rate lookup, otherwise the OAM packet will >> >> not >> >> >> take >> >> >>>> the same path as data packets. Therefore any MIP identifier >> >> that is >> >> >>>> proposed in this >> >> >>> draft >> >> >>>> requires one extra lookup and therefore adds significantly >> to >> >> cost. >> >> >>> >> >> >>> If I am not wrong, this is a feature of an out-MIP. If you >> >> decide to >> >> >>> implement out-MIPs, and if you want the OAM to follow exactly >> >> the >> >> >> same >> >> >>> path as the data, then it is a requirement that the out >> >> interface >> >> >>> inspects the packets (at line >> >> >>> rate) to determine whether they are OAM and targeted at the >> >> interface. >> >> >>> >> >> >>> We cannot change that aspect. All we can do is aim to make >> the >> >> lookup >> >> >>> as easy as possible. >> >> >>> >> >> >>>> Perhaps a >> >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain >> >> Level) may be >> >> >>>> used that requires only 3 bits and achieves the same result. >> >> >>> >> >> >>> Perhaps it could. >> >> >>> But before going there, why is the lookup in the current >> >> version of >> >> >>> the I-D arduous? >> >> >>> >> >> >>> Presumably you do not propose making any change to the way >> >> In-MIPs >> >> >> are >> >> >>> currently identified, so the lookups being done at line rate >> >> today on >> >> >>> the incoming interfaces will not be changed. If you are >> >> proposing >> >> >> such >> >> >>> a change, then the discussion is outside the scope of this I- >> >> D and >> >> >>> becomes a much wider question for the working group. >> >> >>> >> >> >>> This leaves me with the trade-off of enabling a *simpler* >> >> lookup on >> >> >>> the outgoing interfaces versus doing identical lookups on >> both >> >> >>> interfaces. My assumption was that if the incoming interface >> >> can do >> >> >>> the lookup at line rate, it is not hard to perform the same >> >> lookup on >> >> >>> the outgoing interface. Furthermore, there is a reduction in >> >> >> complexity by having fewer things to look up. >> >> >>> >> >> >>> Another possibility is that the full lookup could be done on >> >> the >> >> >>> incoming interface and the packet marked for easy >> interception >> >> on the >> >> >> outgoing interface. >> >> >>> The concern with this approach is that the packet would no >> >> longer be >> >> >>> being forwarded exactly as data because it would be being >> >> modified in >> >> >> flight. >> >> >>> Furthermore, in the case of P2MP, it is not enough to flag >> the >> >> packet >> >> >>> as a local Out-MIP and further identifier-based lookup is >> >> needed. >> >> >>> >> >> >>> Some of these issues were raised and discussed as the I-D >> >> progressed, >> >> >>> and some of the alternative solutions were tracked with their >> >> pros >> >> >> and >> >> >>> cons in Appendix A of the I-D (look at revision -03). >> >> >>> >> >> >>> Thanks, >> >> >>> Adrian >> >> >>>> -----Original Message----- >> >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On >> >> Behalf >> >> >>>> Of Adrian Farrel >> >> >>>> Sent: Monday, November 19, 2012 8:45 AM >> >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >> >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; >> >> >>> draft-ietf-mpls-tp-mip- >> >> >>>> mep-map@tools.ietf.org >> >> >>>> Subject: Re: [mpls] working group last call on >> >> >>>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>> >> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author >> >> anything >> >> >> else? >> >> >>>> >> >> >>>> The point was that when I started the I-D lots of people >> were >> >> saying >> >> >>>> "it's complex" and "it can't be done" and "it won't be >> >> backward >> >> >> compatible". >> >> >>>> >> >> >>>> So the I-D says "here it is" >> >> >>>> >> >> >>>> A (sorry not to offer you excitement) >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] >> >> >>>>> Sent: 19 November 2012 12:38 >> >> >>>>> To: Loa Andersson; mpls@ietf.org >> >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; MPLS-TP ad >> >> >>>>> hoc >> >> >>> team; >> >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >> >> >>>>> Subject: Re: [mpls] working group last call on >> >> >>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>>> >> >> >>>>> After getting to section 6 and its features (requirements!), >> >> I find >> >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is >> >> >>>>> Informational and not Standards Track. >> >> >>>>> >> >> >>>>> Meanwhile, I suggest some editorial issues. >> >> >>>>> >> >> >>>>> Title >> >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >> >> [Handling >> >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >> >> >>>>> informative statement unless and until you get to the >> >> definition of >> >> >>>>> Internal in s3; and s6, which is the crux of the document >> >> says The >> >> >>>>> preferred solution to per-interface MIP message handling is >> >> >>>>> presented in this section] >> >> >>>>> >> >> >>>>> s1 >> >> >>>>> two (or more) MIPs per node on both sides of the forwarding >> >> engine. >> >> >>>>> [two on both sides sounds like four in total to me; suggest >> >> 'one on >> >> >>>>> each side of the forwarding engine'] >> >> >>>>> >> >> >>>>> s4 >> >> >>>>> o CV between a MEP and a MIP >> >> >>>>> [expand CV on first use] >> >> >>>>> >> >> >>>>> s5 >> >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >> >> MPLS-TP >> >> >>>>> LSPs and MPLS-TP PWs, respectively. >> >> >>>>> ['respectively' suggests to me that there should be two >> >> precedents, >> >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 >> for >> >> LSPs, >> >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this >> sentence >> >> as >> >> >>>>> redundant] >> >> >>>>> >> >> >>>>> s6 >> >> >>>>> The appendix of this document contains a >> >> >>>>> few solutions that the authors have discarded which have >> >> been >> >> >> left in >> >> >>>>> the document for informational purposes. >> >> >>>>> [not any more they haven't!] >> >> >>>>> >> >> >>>>> The node itself is addresses >> >> >>>>> [The node itself is addressed] >> >> >>>>> >> >> >>>>> The identification information indside [The identification >> >> >>>>> information inside ] >> >> >>>>> >> >> >>>>> MIP identifiers are not know >> >> >>>>> [MIP identifiers are not known] >> >> >>>>> >> >> >>>>> reserved MIP address >> >> >>>>> [reserved MIP addressses or a reserved MIP address] >> >> >>>>> >> >> >>>>> Tom Petch >> >> >>>>> >> >> >>>>> >> >> >>>>> ----- Original Message ----- >> >> >>>>> From: "Loa Andersson" >> >> >>>>> To: >> >> >>>>> Cc: ; > >> chairs@tools.ietf.org>; >> >> >>>>> "MPLS-TP ad hoc team" ; >> >> >>>>> >> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM >> >> >>>>> >> >> >>>>>> Working Group, >> >> >>>>>> >> >> >>>>>> This is to start a 2 week working group last call on >> >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. >> >> >>>>>> >> >> >>>>>> Please send your comments to the mpls working group >> mailing >> >> list >> >> >>>>>> (mpls@ietf.org). >> >> >>>>>> >> >> >>>>>> Please send both technical comments, and if you are happy >> >> with the >> >> >>>>>> document as is also indications of support. >> >> >>>>>> >> >> >>>>>> This working group last call will end on November 28. >> >> >>>>>> >> >> >>>>>> /Loa >> >> >>>>>> for the wg co-chairs >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> mpls mailing list >> >> >>>> mpls@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> mpls mailing list >> >> >>> mpls@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> >> >> mpls mailing list >> >> >> mpls@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> >> Road, London W3 6BL | Registered in England 2832014 >> >> > _______________________________________________ >> >> > mpls mailing list >> >> > mpls@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > >> > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From davari@broadcom.com Mon Dec 3 16:53:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D176311E809B for ; Mon, 3 Dec 2012 16:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.24 X-Spam-Level: X-Spam-Status: No, score=-5.24 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wPZZJWvPG5T for ; Mon, 3 Dec 2012 16:53:33 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1285921F8905 for ; Mon, 3 Dec 2012 16:53:33 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 16:51:20 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 16:53:14 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 16:53:13 -0800 From: "Shahram Davari" To: "hideki.endo.es@hitachi.com" Thread-Topic: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsKeQf/mKl4u0SUtKP+ZUNj/pfxIUQJgADKVACAATqdcIABbJeAgABenYCAAFjlgP//jqnggAgUCACAAx0KgP//kH6wgAghlgD//5QedQAaqJaA///HyQb///8xYA== Date: Tue, 4 Dec 2012 00:53:13 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CA396821QK14831200-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:53:34 -0000 Hi Hideki, I think you need to look at my p-code. F a MIP is not configured in the Egr= ess port, then that egress port won't sent the OAM packet to its processor = and drops it. So there is no issue with my proposed method. Thx Shahram -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]=20 Sent: Monday, December 03, 2012 4:48 PM To: Shahram Davari Cc: Rolf.Winter@neclab.eu; mpls@ietf.org Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-me= p-map Hi Shahram, First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests Here, CV means On-demand CV. You may misunderstand as Proactive CV. Second, you wrote; "The issue is that each CPU/processor has limited resources.=20 By sending all OAM MIP packets to both processor you are=20 losing 1/2 of the capacity of each processor. " It depends on implementations, and this issue could NOT be resolved by even your solution that uses ACH he= ader to indicate in/out-MIP. Let's consider P2MP case as you pointed out. All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processor at port D loses its capacity. If we consider the larger number of ports in the LSR which has 100 ports, f= or example, All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processors at the other 98 ports lose those capacit= ies. Even if your solution using ACH header is applied, it can reduce OAM packets only for in-MIP, which means only 1/101 effective= ness in the case of P2MP for 100 ports. Thanks, Hideki Endo >Rolf, > >For clarity it is better to use an example. Assume that an LSR has 4 ports= (A, B, C, D). Now assume that it receives packets on a unicast LSP-X fro= m port A and forwards them to port B. there can only be 3 configurations: > >1) MIP on port A (In-MIP), or >2) MIP on port B (out-MIP), or >3) MEIP on Port A and B >=20 >A single OAM packet can be terminated and processed only by one of these M= IPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). In y= our example, you are saying send a copy of the P to the CPU/Processor on Po= rt A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop= the packet since the MIP-ID is not A. The issue is that each CPU/processo= r has limited resources. By sending all OAM MIP packets to both processor = you are losing 1/2 of the capacity of each processor. The practical soluti= on is to have a simple indicator in the packet header that this OAM packet = is meant for Out-MIP. Then port A just switches the OAM packet to Port B, a= nd Port B terminates and sends it to its CPU/processor. > >Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip = from Port A and is sent to ports B, C, D. Also assume that there is In-MIP= on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM= packet is meant for out-MIPs (B, C). In such case the OAM packet should n= ot be sent to port A CPU/Processor. It is therefore multicast to ports B, C= , D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM pack= ets and does not send it to its CPU, since there is no MIP configured for t= hat MPLS label. > >So the Pseudo-code is like this: > >Ingress Port: > >If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Send to local CPU > Else > Forward to egress port > End > Else > Forward normally > End >Else > >Egress Port: > >If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Drop packet > Else If packet indicates Out-MIP > Send to local CPU > End > Else > Drop packet > End >End >=09 > >Using this example could you please describe your reasoning for not requir= ing HW to identify In-MEP vs out-MIPs? > >Thanks >Shahram > >-----Original Message----- >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >Sent: Monday, December 03, 2012 12:10 PM >To: Shahram Davari >Cc: Pablo Frank; mpls@ietf.org >Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-= map > >But the MIP that is addressed needs to be able to handle this _plus_ take = an appropriate action and in the P2MP case this will always be the case sin= ce there are 2 or more out MIPs. > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014=20 > > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Montag, 3. Dezember 2012 16:27 >> To: Rolf Winter >> Cc: Pablo Frank; mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >>=20 >> Hi Rolf, >>=20 >> Your HW guys are correct as long as the amount of data sent to the in- >> MIP processor is not much. But from your previous email to Loa I see >> that you want to also terminate CV at MIPs. CVs are fast and high >> bandwidth and blindly dumping them on a CPU or OAM processor that may >> not be expecting them is like DoS attack. >>=20 >>=20 >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >> wrote: >>=20 >> > Hi, >> > >> > sorry for the belated response. I checked with some of our HW people. >> Here's the gist of their response: >> > >> > Of course they wouldn't like parsing TLVs but we established that >> fact already. Their answer to the problem is slightly different though. >> A TTL-expired OAM frame can simply be copied and forwarded to the out- >> MIPs where, if the frame is not intended for them, it can safely be >> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >> implementation must behave in this exact way in either case. So there >> is at least one way to implement this at line rate without going back >> and changing a bunch of RFCs. >> > >> > Best, >> > >> > Rolf >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> > London W3 6BL | Registered in England 2832014 >> > >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> >> Of Shahram Davari >> >> Sent: Mittwoch, 28. November 2012 18:46 >> >> To: Pablo Frank >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> Pablo, >> >> >> >> >> >> >> >> That was exactly my point. Let's use a flag to indicate in-MIP or >> >> out- MIP and then the offline processor can do MEPID lookup to >> >> determine whether this is a legitimate OAM packet or not. >> >> >> >> >> >> >> >> Thx >> >> Shahram >> >> >> >> >> >> >> >> From: Pablo Frank [mailto:pabloisnot@gmail.com] >> >> Sent: Wednesday, November 28, 2012 8:22 AM >> >> To: Shahram Davari >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> >> >> >> >> I think Shahram raises a very legitimate concern about how expensive >> >> this could be to implement in hardware. >> >> >> >> >> >> >> >> As I understand it, the logic proposed by this draft is as follows: >> >> >> >> >> >> >> >> At the ingress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> forward normally (but note we must intercept it again on >> egress) >> >> >> >> ELSE >> >> >> >> punt to OAM processor >> >> >> >> >> >> >> >> At the egress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> punt to OAM processor >> >> >> >> ELSE >> >> >> >> drop >> >> >> >> >> >> >> >> Note all this has to be done in the fast-path now at full line rate >> >> (and hardware guys hate TLVs). Before, the only thing the fast-path >> >> had to do was look for TTL-expiry. >> >> >> >> >> >> >> >> The only reason that ACH reserved bit was rejected (in Appendix A.4 >> >> of >> >> -03 version of doc) was because it also required a MIP-ID lookup. >> >> But I don't see anything wrong with combining both mechanisms. >> >> Ideally, hardware could rely on the reserved bit to do the initial >> >> filtering at full line-rate and then a presumably much more >> >> cost-efficient OAM hardware block could perform the MIP-ID lookup. >> >> Instead of the complex logic above, the fast path gets a simple >> >> modification to TTL handling and the OAM block does the heavy >> lifting of dealing with ACH TLVs, etc. >> >> >> >> >> >> >> >> This seems like a case where practicality should trump elegance. >> >> >> >> >> >> >> >> regards, >> >> >> >> Pablo >> >> >> >> >> >> >> >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >> >> >> >> wrote: >> >> >> >> >> >> >> >> > Rolf, >> >> > >> >> > I am sure you know that TLVs are not Hardware friendly. And I >> >> think you agree with me that this draft requires deep parsing of all >> >> packets at line rate to get to the MIPID TLV. >> >> > >> >> > I still think the MIPID TLV is required to decide whether an >> OAM >> >> packet ended up at the right MIP. But may be a simpler solution >> >> could be augmented to decide between In-MIP and Out-MIP. For example >> >> how about using one of the reserved bits in the ACH header. This >> can >> >> easily be done in hardware with minimum complexity. >> >> > >> >> > Regards, >> >> > Shahram >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> >> Behalf Of Rolf Winter >> >> > Sent: Wednesday, November 21, 2012 12:13 PM >> >> > To: S. Davari; adrian@olddog.co.uk >> >> > Cc: mpls@ietf.org >> >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- >> >> tp-mip-mep-map >> >> > >> >> > Hi, >> >> > >> >> >> Hi Adrian, >> >> >> >> >> >> You are right and I should have sent these types of comments >> >> before >> >> >> last call. I completely understand the procedure. >> >> >> >> >> >> One thing I didn't understand in your response is that you >> said >> >> in-MIP >> >> >> requires to do the MEPID lookup at line rate anyway. Why is >> >> that? >> >> >> >> >> >> My understanding is that before this draft, the process would >> >> have >> >> >> been for the ingress to look at TTL and if it is expired then >> >> send the >> >> >> packet to OAM processor. >> >> > >> >> > Yes (and no). While I assume likely MIP functionality will be >> >> implemented on the ingress, the related RFCs are vague about the >> >> actual placement of the MIP function. See e.g. the OAM Framework >> (RFC >> >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >> >> location within the node)". >> >> > >> >> > Also, I think "before this draft" is not quite accurate in that >> >> is suggests there is no per-interface MIP addressing possible as of >> now. >> >> Take RFC 6426. In practice this is where part of the problem lies. >> We >> >> cannot really go back and change all this. There are other >> constraints. >> >> E.g. we have a requirement to address a single out-MIP out of a set >> >> of out-MIPs on a P2MP branch point. So this was part of the >> >> constraints we worked with. >> >> > >> >> >> >> >> >> The MEPID that you suggest in this draft is very useful for >> >> filtering >> >> >> out leaked OAM frames from upstream. But lets leave lookup of >> >> the MEPID >> >> >> to the OAM processing module (at slower rate) and add an >> >> indicator to >> >> >> the OAM packet to indicate whether it should be taken out of >> >> the data >> >> >> path in the Ingress or egress. >> >> >> >> >> >> So can I suggest adding the following text to the draft: >> >> >> >> >> >> " In addition to the MEPID, which is used to ultimately accept >> >> or >> >> >> filter out received OAM packets, OAM packets should have a >> >> simple >> >> >> indicator that identifies whether the OAM packet belongs to >> >> in-MIP or >> >> >> Out-MIP". >> >> > >> >> > We also have the question on where to retrofit those bits. I >> >> assume a TLV wouldn't work for the exact reasons you do not like to >> >> have to do a second lookup, since it would require some parsing. All >> >> these constraints and the ones outlined in the document led to where >> >> we are. In a sense this is a non-spec since it rather rules out a >> >> number of things that seem like a good idea at first but then have a >> >> catch of some sort. >> >> > >> >> > Best, >> >> > >> >> > Rolf >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> Shahram >> >> >> >> >> >> >> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >> >> >> >> >> wrote: >> >> >> >> >> >>> >> >> >>> >> >> >>> Hi Shahram, >> >> >>> >> >> >>> I am worried about the precedent of a comment like this >> during >> >> WG >> >> >> last call. >> >> >>> While comments that improve the document or point out >> >> fundamental >> >> >>> flaws are welcome whenever they arrive, points with the >> >> flavour "I >> >> >>> wouldn't have done it like this" that arrive this late in the >> >> process >> >> >> don't feel very constructive. >> >> >>> But I will leave the chair to worry about process and try to >> >> address >> >> >>> the technical points... >> >> >>> >> >> >>>> Identifying whether to terminate an OAM packet and process >> it >> >> in In- >> >> >> MIP vs. >> >> >>> Out- >> >> >>>> MIP requires line rate lookup, otherwise the OAM packet will >> >> not >> >> >> take >> >> >>>> the same path as data packets. Therefore any MIP identifier >> >> that is >> >> >>>> proposed in this >> >> >>> draft >> >> >>>> requires one extra lookup and therefore adds significantly >> to >> >> cost. >> >> >>> >> >> >>> If I am not wrong, this is a feature of an out-MIP. If you >> >> decide to >> >> >>> implement out-MIPs, and if you want the OAM to follow exactly >> >> the >> >> >> same >> >> >>> path as the data, then it is a requirement that the out >> >> interface >> >> >>> inspects the packets (at line >> >> >>> rate) to determine whether they are OAM and targeted at the >> >> interface. >> >> >>> >> >> >>> We cannot change that aspect. All we can do is aim to make >> the >> >> lookup >> >> >>> as easy as possible. >> >> >>> >> >> >>>> Perhaps a >> >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain >> >> Level) may be >> >> >>>> used that requires only 3 bits and achieves the same result. >> >> >>> >> >> >>> Perhaps it could. >> >> >>> But before going there, why is the lookup in the current >> >> version of >> >> >>> the I-D arduous? >> >> >>> >> >> >>> Presumably you do not propose making any change to the way >> >> In-MIPs >> >> >> are >> >> >>> currently identified, so the lookups being done at line rate >> >> today on >> >> >>> the incoming interfaces will not be changed. If you are >> >> proposing >> >> >> such >> >> >>> a change, then the discussion is outside the scope of this I- >> >> D and >> >> >>> becomes a much wider question for the working group. >> >> >>> >> >> >>> This leaves me with the trade-off of enabling a *simpler* >> >> lookup on >> >> >>> the outgoing interfaces versus doing identical lookups on >> both >> >> >>> interfaces. My assumption was that if the incoming interface >> >> can do >> >> >>> the lookup at line rate, it is not hard to perform the same >> >> lookup on >> >> >>> the outgoing interface. Furthermore, there is a reduction in >> >> >> complexity by having fewer things to look up. >> >> >>> >> >> >>> Another possibility is that the full lookup could be done on >> >> the >> >> >>> incoming interface and the packet marked for easy >> interception >> >> on the >> >> >> outgoing interface. >> >> >>> The concern with this approach is that the packet would no >> >> longer be >> >> >>> being forwarded exactly as data because it would be being >> >> modified in >> >> >> flight. >> >> >>> Furthermore, in the case of P2MP, it is not enough to flag >> the >> >> packet >> >> >>> as a local Out-MIP and further identifier-based lookup is >> >> needed. >> >> >>> >> >> >>> Some of these issues were raised and discussed as the I-D >> >> progressed, >> >> >>> and some of the alternative solutions were tracked with their >> >> pros >> >> >> and >> >> >>> cons in Appendix A of the I-D (look at revision -03). >> >> >>> >> >> >>> Thanks, >> >> >>> Adrian >> >> >>>> -----Original Message----- >> >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On >> >> Behalf >> >> >>>> Of Adrian Farrel >> >> >>>> Sent: Monday, November 19, 2012 8:45 AM >> >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >> >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; >> >> >>> draft-ietf-mpls-tp-mip- >> >> >>>> mep-map@tools.ietf.org >> >> >>>> Subject: Re: [mpls] working group last call on >> >> >>>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>> >> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author >> >> anything >> >> >> else? >> >> >>>> >> >> >>>> The point was that when I started the I-D lots of people >> were >> >> saying >> >> >>>> "it's complex" and "it can't be done" and "it won't be >> >> backward >> >> >> compatible". >> >> >>>> >> >> >>>> So the I-D says "here it is" >> >> >>>> >> >> >>>> A (sorry not to offer you excitement) >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] >> >> >>>>> Sent: 19 November 2012 12:38 >> >> >>>>> To: Loa Andersson; mpls@ietf.org >> >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; MPLS-TP ad >> >> >>>>> hoc >> >> >>> team; >> >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >> >> >>>>> Subject: Re: [mpls] working group last call on >> >> >>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>>> >> >> >>>>> After getting to section 6 and its features (requirements!), >> >> I find >> >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is >> >> >>>>> Informational and not Standards Track. >> >> >>>>> >> >> >>>>> Meanwhile, I suggest some editorial issues. >> >> >>>>> >> >> >>>>> Title >> >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >> >> [Handling >> >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >> >> >>>>> informative statement unless and until you get to the >> >> definition of >> >> >>>>> Internal in s3; and s6, which is the crux of the document >> >> says The >> >> >>>>> preferred solution to per-interface MIP message handling is >> >> >>>>> presented in this section] >> >> >>>>> >> >> >>>>> s1 >> >> >>>>> two (or more) MIPs per node on both sides of the forwarding >> >> engine. >> >> >>>>> [two on both sides sounds like four in total to me; suggest >> >> 'one on >> >> >>>>> each side of the forwarding engine'] >> >> >>>>> >> >> >>>>> s4 >> >> >>>>> o CV between a MEP and a MIP >> >> >>>>> [expand CV on first use] >> >> >>>>> >> >> >>>>> s5 >> >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >> >> MPLS-TP >> >> >>>>> LSPs and MPLS-TP PWs, respectively. >> >> >>>>> ['respectively' suggests to me that there should be two >> >> precedents, >> >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 >> for >> >> LSPs, >> >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this >> sentence >> >> as >> >> >>>>> redundant] >> >> >>>>> >> >> >>>>> s6 >> >> >>>>> The appendix of this document contains a >> >> >>>>> few solutions that the authors have discarded which have >> >> been >> >> >> left in >> >> >>>>> the document for informational purposes. >> >> >>>>> [not any more they haven't!] >> >> >>>>> >> >> >>>>> The node itself is addresses >> >> >>>>> [The node itself is addressed] >> >> >>>>> >> >> >>>>> The identification information indside [The identification >> >> >>>>> information inside ] >> >> >>>>> >> >> >>>>> MIP identifiers are not know >> >> >>>>> [MIP identifiers are not known] >> >> >>>>> >> >> >>>>> reserved MIP address >> >> >>>>> [reserved MIP addressses or a reserved MIP address] >> >> >>>>> >> >> >>>>> Tom Petch >> >> >>>>> >> >> >>>>> >> >> >>>>> ----- Original Message ----- >> >> >>>>> From: "Loa Andersson" >> >> >>>>> To: >> >> >>>>> Cc: ; > >> chairs@tools.ietf.org>; >> >> >>>>> "MPLS-TP ad hoc team" ; >> >> >>>>> >> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM >> >> >>>>> >> >> >>>>>> Working Group, >> >> >>>>>> >> >> >>>>>> This is to start a 2 week working group last call on >> >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. >> >> >>>>>> >> >> >>>>>> Please send your comments to the mpls working group >> mailing >> >> list >> >> >>>>>> (mpls@ietf.org). >> >> >>>>>> >> >> >>>>>> Please send both technical comments, and if you are happy >> >> with the >> >> >>>>>> document as is also indications of support. >> >> >>>>>> >> >> >>>>>> This working group last call will end on November 28. >> >> >>>>>> >> >> >>>>>> /Loa >> >> >>>>>> for the wg co-chairs >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> mpls mailing list >> >> >>>> mpls@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> mpls mailing list >> >> >>> mpls@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> >> >> mpls mailing list >> >> >> mpls@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> >> Road, London W3 6BL | Registered in England 2832014 >> >> > _______________________________________________ >> >> > mpls mailing list >> >> > mpls@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > >> > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From davari@broadcom.com Mon Dec 3 16:58:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9321F882E for ; Mon, 3 Dec 2012 16:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.252 X-Spam-Level: X-Spam-Status: No, score=-5.252 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN5sU7Hr9iQw for ; Mon, 3 Dec 2012 16:58:50 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3E11E809A for ; Mon, 3 Dec 2012 16:58:50 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 16:54:11 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 16:58:36 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 16:58:16 -0800 From: "Shahram Davari" To: "hideki.endo.es@hitachi.com" Thread-Topic: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsKeQf/mKl4u0SUtKP+ZUNj/pfxIUQJgADKVACAATqdcIABbJeAgABenYCAAFjlgP//jqnggAgUCACAAx0KgP//kH6wgAghlgD//5QedQAaqJaA///HyQb///8xYP///csA Date: Tue, 4 Dec 2012 00:58:15 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broadcom.com> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CA3963939W4776725-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 00:58:52 -0000 Hi, Using MIP ID as the only method to filter OAM packets to CPU/Processor is n= ot practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM,= etc. Each has its own format and the TLV can be anywhere. Using MIP ID as = the only identifier requires unnecessarily parsing of all these different p= acket types at line rate in HW. Why not just use a simple bit in the ACH header? We need a n indicator in a= fixed location or the solution is not going to be practical in HW. Thanks, Shahram -----Original Message----- From: Shahram Davari=20 Sent: Monday, December 03, 2012 4:53 PM To: 'hideki.endo.es@hitachi.com' Cc: Rolf.Winter@neclab.eu; mpls@ietf.org Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mi= p-mep-map Hi Hideki, I think you need to look at my p-code. F a MIP is not configured in the Egr= ess port, then that egress port won't sent the OAM packet to its processor = and drops it. So there is no issue with my proposed method. Thx Shahram -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]=20 Sent: Monday, December 03, 2012 4:48 PM To: Shahram Davari Cc: Rolf.Winter@neclab.eu; mpls@ietf.org Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-me= p-map Hi Shahram, First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests Here, CV means On-demand CV. You may misunderstand as Proactive CV. Second, you wrote; "The issue is that each CPU/processor has limited resources.=20 By sending all OAM MIP packets to both processor you are=20 losing 1/2 of the capacity of each processor. " It depends on implementations, and this issue could NOT be resolved by even your solution that uses ACH he= ader to indicate in/out-MIP. Let's consider P2MP case as you pointed out. All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processor at port D loses its capacity. If we consider the larger number of ports in the LSR which has 100 ports, f= or example, All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processors at the other 98 ports lose those capacit= ies. Even if your solution using ACH header is applied, it can reduce OAM packets only for in-MIP, which means only 1/101 effective= ness in the case of P2MP for 100 ports. Thanks, Hideki Endo >Rolf, > >For clarity it is better to use an example. Assume that an LSR has 4 ports= (A, B, C, D). Now assume that it receives packets on a unicast LSP-X fro= m port A and forwards them to port B. there can only be 3 configurations: > >1) MIP on port A (In-MIP), or >2) MIP on port B (out-MIP), or >3) MEIP on Port A and B >=20 >A single OAM packet can be terminated and processed only by one of these M= IPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). In y= our example, you are saying send a copy of the P to the CPU/Processor on Po= rt A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop= the packet since the MIP-ID is not A. The issue is that each CPU/processo= r has limited resources. By sending all OAM MIP packets to both processor = you are losing 1/2 of the capacity of each processor. The practical soluti= on is to have a simple indicator in the packet header that this OAM packet = is meant for Out-MIP. Then port A just switches the OAM packet to Port B, a= nd Port B terminates and sends it to its CPU/processor. > >Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip = from Port A and is sent to ports B, C, D. Also assume that there is In-MIP= on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM= packet is meant for out-MIPs (B, C). In such case the OAM packet should n= ot be sent to port A CPU/Processor. It is therefore multicast to ports B, C= , D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM pack= ets and does not send it to its CPU, since there is no MIP configured for t= hat MPLS label. > >So the Pseudo-code is like this: > >Ingress Port: > >If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Send to local CPU > Else > Forward to egress port > End > Else > Forward normally > End >Else > >Egress Port: > >If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Drop packet > Else If packet indicates Out-MIP > Send to local CPU > End > Else > Drop packet > End >End >=09 > >Using this example could you please describe your reasoning for not requir= ing HW to identify In-MEP vs out-MIPs? > >Thanks >Shahram > >-----Original Message----- >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >Sent: Monday, December 03, 2012 12:10 PM >To: Shahram Davari >Cc: Pablo Frank; mpls@ietf.org >Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-= map > >But the MIP that is addressed needs to be able to handle this _plus_ take = an appropriate action and in the P2MP case this will always be the case sin= ce there are 2 or more out MIPs. > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014=20 > > >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Montag, 3. Dezember 2012 16:27 >> To: Rolf Winter >> Cc: Pablo Frank; mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >>=20 >> Hi Rolf, >>=20 >> Your HW guys are correct as long as the amount of data sent to the in- >> MIP processor is not much. But from your previous email to Loa I see >> that you want to also terminate CV at MIPs. CVs are fast and high >> bandwidth and blindly dumping them on a CPU or OAM processor that may >> not be expecting them is like DoS attack. >>=20 >>=20 >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >> wrote: >>=20 >> > Hi, >> > >> > sorry for the belated response. I checked with some of our HW people. >> Here's the gist of their response: >> > >> > Of course they wouldn't like parsing TLVs but we established that >> fact already. Their answer to the problem is slightly different though. >> A TTL-expired OAM frame can simply be copied and forwarded to the out- >> MIPs where, if the frame is not intended for them, it can safely be >> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >> implementation must behave in this exact way in either case. So there >> is at least one way to implement this at line rate without going back >> and changing a bunch of RFCs. >> > >> > Best, >> > >> > Rolf >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> > London W3 6BL | Registered in England 2832014 >> > >> > >> >> -----Original Message----- >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >> >> Of Shahram Davari >> >> Sent: Mittwoch, 28. November 2012 18:46 >> >> To: Pablo Frank >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> Pablo, >> >> >> >> >> >> >> >> That was exactly my point. Let's use a flag to indicate in-MIP or >> >> out- MIP and then the offline processor can do MEPID lookup to >> >> determine whether this is a legitimate OAM packet or not. >> >> >> >> >> >> >> >> Thx >> >> Shahram >> >> >> >> >> >> >> >> From: Pablo Frank [mailto:pabloisnot@gmail.com] >> >> Sent: Wednesday, November 28, 2012 8:22 AM >> >> To: Shahram Davari >> >> Cc: mpls@ietf.org >> >> Subject: Re: [mpls] working group last call on >> >> draft-ietf-mpls-tp-mip- mep-map >> >> >> >> >> >> >> >> I think Shahram raises a very legitimate concern about how expensive >> >> this could be to implement in hardware. >> >> >> >> >> >> >> >> As I understand it, the logic proposed by this draft is as follows: >> >> >> >> >> >> >> >> At the ingress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> forward normally (but note we must intercept it again on >> egress) >> >> >> >> ELSE >> >> >> >> punt to OAM processor >> >> >> >> >> >> >> >> At the egress blade: >> >> >> >> >> >> >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >> >> >> >> Parse MIP-ID TLV >> >> >> >> Lookup MIP-ID >> >> >> >> IF MIP-is-egress, THEN >> >> >> >> punt to OAM processor >> >> >> >> ELSE >> >> >> >> drop >> >> >> >> >> >> >> >> Note all this has to be done in the fast-path now at full line rate >> >> (and hardware guys hate TLVs). Before, the only thing the fast-path >> >> had to do was look for TTL-expiry. >> >> >> >> >> >> >> >> The only reason that ACH reserved bit was rejected (in Appendix A.4 >> >> of >> >> -03 version of doc) was because it also required a MIP-ID lookup. >> >> But I don't see anything wrong with combining both mechanisms. >> >> Ideally, hardware could rely on the reserved bit to do the initial >> >> filtering at full line-rate and then a presumably much more >> >> cost-efficient OAM hardware block could perform the MIP-ID lookup. >> >> Instead of the complex logic above, the fast path gets a simple >> >> modification to TTL handling and the OAM block does the heavy >> lifting of dealing with ACH TLVs, etc. >> >> >> >> >> >> >> >> This seems like a case where practicality should trump elegance. >> >> >> >> >> >> >> >> regards, >> >> >> >> Pablo >> >> >> >> >> >> >> >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >> >> >> >> wrote: >> >> >> >> >> >> >> >> > Rolf, >> >> > >> >> > I am sure you know that TLVs are not Hardware friendly. And I >> >> think you agree with me that this draft requires deep parsing of all >> >> packets at line rate to get to the MIPID TLV. >> >> > >> >> > I still think the MIPID TLV is required to decide whether an >> OAM >> >> packet ended up at the right MIP. But may be a simpler solution >> >> could be augmented to decide between In-MIP and Out-MIP. For example >> >> how about using one of the reserved bits in the ACH header. This >> can >> >> easily be done in hardware with minimum complexity. >> >> > >> >> > Regards, >> >> > Shahram >> >> > >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >> >> Behalf Of Rolf Winter >> >> > Sent: Wednesday, November 21, 2012 12:13 PM >> >> > To: S. Davari; adrian@olddog.co.uk >> >> > Cc: mpls@ietf.org >> >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- >> >> tp-mip-mep-map >> >> > >> >> > Hi, >> >> > >> >> >> Hi Adrian, >> >> >> >> >> >> You are right and I should have sent these types of comments >> >> before >> >> >> last call. I completely understand the procedure. >> >> >> >> >> >> One thing I didn't understand in your response is that you >> said >> >> in-MIP >> >> >> requires to do the MEPID lookup at line rate anyway. Why is >> >> that? >> >> >> >> >> >> My understanding is that before this draft, the process would >> >> have >> >> >> been for the ingress to look at TTL and if it is expired then >> >> send the >> >> >> packet to OAM processor. >> >> > >> >> > Yes (and no). While I assume likely MIP functionality will be >> >> implemented on the ingress, the related RFCs are vague about the >> >> actual placement of the MIP function. See e.g. the OAM Framework >> (RFC >> >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >> >> location within the node)". >> >> > >> >> > Also, I think "before this draft" is not quite accurate in that >> >> is suggests there is no per-interface MIP addressing possible as of >> now. >> >> Take RFC 6426. In practice this is where part of the problem lies. >> We >> >> cannot really go back and change all this. There are other >> constraints. >> >> E.g. we have a requirement to address a single out-MIP out of a set >> >> of out-MIPs on a P2MP branch point. So this was part of the >> >> constraints we worked with. >> >> > >> >> >> >> >> >> The MEPID that you suggest in this draft is very useful for >> >> filtering >> >> >> out leaked OAM frames from upstream. But lets leave lookup of >> >> the MEPID >> >> >> to the OAM processing module (at slower rate) and add an >> >> indicator to >> >> >> the OAM packet to indicate whether it should be taken out of >> >> the data >> >> >> path in the Ingress or egress. >> >> >> >> >> >> So can I suggest adding the following text to the draft: >> >> >> >> >> >> " In addition to the MEPID, which is used to ultimately accept >> >> or >> >> >> filter out received OAM packets, OAM packets should have a >> >> simple >> >> >> indicator that identifies whether the OAM packet belongs to >> >> in-MIP or >> >> >> Out-MIP". >> >> > >> >> > We also have the question on where to retrofit those bits. I >> >> assume a TLV wouldn't work for the exact reasons you do not like to >> >> have to do a second lookup, since it would require some parsing. All >> >> these constraints and the ones outlined in the document led to where >> >> we are. In a sense this is a non-spec since it rather rules out a >> >> number of things that seem like a good idea at first but then have a >> >> catch of some sort. >> >> > >> >> > Best, >> >> > >> >> > Rolf >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> Shahram >> >> >> >> >> >> >> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >> >> >> >> >> wrote: >> >> >> >> >> >>> >> >> >>> >> >> >>> Hi Shahram, >> >> >>> >> >> >>> I am worried about the precedent of a comment like this >> during >> >> WG >> >> >> last call. >> >> >>> While comments that improve the document or point out >> >> fundamental >> >> >>> flaws are welcome whenever they arrive, points with the >> >> flavour "I >> >> >>> wouldn't have done it like this" that arrive this late in the >> >> process >> >> >> don't feel very constructive. >> >> >>> But I will leave the chair to worry about process and try to >> >> address >> >> >>> the technical points... >> >> >>> >> >> >>>> Identifying whether to terminate an OAM packet and process >> it >> >> in In- >> >> >> MIP vs. >> >> >>> Out- >> >> >>>> MIP requires line rate lookup, otherwise the OAM packet will >> >> not >> >> >> take >> >> >>>> the same path as data packets. Therefore any MIP identifier >> >> that is >> >> >>>> proposed in this >> >> >>> draft >> >> >>>> requires one extra lookup and therefore adds significantly >> to >> >> cost. >> >> >>> >> >> >>> If I am not wrong, this is a feature of an out-MIP. If you >> >> decide to >> >> >>> implement out-MIPs, and if you want the OAM to follow exactly >> >> the >> >> >> same >> >> >>> path as the data, then it is a requirement that the out >> >> interface >> >> >>> inspects the packets (at line >> >> >>> rate) to determine whether they are OAM and targeted at the >> >> interface. >> >> >>> >> >> >>> We cannot change that aspect. All we can do is aim to make >> the >> >> lookup >> >> >>> as easy as possible. >> >> >>> >> >> >>>> Perhaps a >> >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain >> >> Level) may be >> >> >>>> used that requires only 3 bits and achieves the same result. >> >> >>> >> >> >>> Perhaps it could. >> >> >>> But before going there, why is the lookup in the current >> >> version of >> >> >>> the I-D arduous? >> >> >>> >> >> >>> Presumably you do not propose making any change to the way >> >> In-MIPs >> >> >> are >> >> >>> currently identified, so the lookups being done at line rate >> >> today on >> >> >>> the incoming interfaces will not be changed. If you are >> >> proposing >> >> >> such >> >> >>> a change, then the discussion is outside the scope of this I- >> >> D and >> >> >>> becomes a much wider question for the working group. >> >> >>> >> >> >>> This leaves me with the trade-off of enabling a *simpler* >> >> lookup on >> >> >>> the outgoing interfaces versus doing identical lookups on >> both >> >> >>> interfaces. My assumption was that if the incoming interface >> >> can do >> >> >>> the lookup at line rate, it is not hard to perform the same >> >> lookup on >> >> >>> the outgoing interface. Furthermore, there is a reduction in >> >> >> complexity by having fewer things to look up. >> >> >>> >> >> >>> Another possibility is that the full lookup could be done on >> >> the >> >> >>> incoming interface and the packet marked for easy >> interception >> >> on the >> >> >> outgoing interface. >> >> >>> The concern with this approach is that the packet would no >> >> longer be >> >> >>> being forwarded exactly as data because it would be being >> >> modified in >> >> >> flight. >> >> >>> Furthermore, in the case of P2MP, it is not enough to flag >> the >> >> packet >> >> >>> as a local Out-MIP and further identifier-based lookup is >> >> needed. >> >> >>> >> >> >>> Some of these issues were raised and discussed as the I-D >> >> progressed, >> >> >>> and some of the alternative solutions were tracked with their >> >> pros >> >> >> and >> >> >>> cons in Appendix A of the I-D (look at revision -03). >> >> >>> >> >> >>> Thanks, >> >> >>> Adrian >> >> >>>> -----Original Message----- >> >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On >> >> Behalf >> >> >>>> Of Adrian Farrel >> >> >>>> Sent: Monday, November 19, 2012 8:45 AM >> >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >> >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; >> >> >>> draft-ietf-mpls-tp-mip- >> >> >>>> mep-map@tools.ietf.org >> >> >>>> Subject: Re: [mpls] working group last call on >> >> >>>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>> >> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author >> >> anything >> >> >> else? >> >> >>>> >> >> >>>> The point was that when I started the I-D lots of people >> were >> >> saying >> >> >>>> "it's complex" and "it can't be done" and "it won't be >> >> backward >> >> >> compatible". >> >> >>>> >> >> >>>> So the I-D says "here it is" >> >> >>>> >> >> >>>> A (sorry not to offer you excitement) >> >> >>>> >> >> >>>>> -----Original Message----- >> >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] >> >> >>>>> Sent: 19 November 2012 12:38 >> >> >>>>> To: Loa Andersson; mpls@ietf.org >> >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >> >> ; MPLS-TP ad >> >> >>>>> hoc >> >> >>> team; >> >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >> >> >>>>> Subject: Re: [mpls] working group last call on >> >> >>> draft-ietf-mpls-tp-mip-mep-map >> >> >>>>> >> >> >>>>> After getting to section 6 and its features (requirements!), >> >> I find >> >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is >> >> >>>>> Informational and not Standards Track. >> >> >>>>> >> >> >>>>> Meanwhile, I suggest some editorial issues. >> >> >>>>> >> >> >>>>> Title >> >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >> >> [Handling >> >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >> >> >>>>> informative statement unless and until you get to the >> >> definition of >> >> >>>>> Internal in s3; and s6, which is the crux of the document >> >> says The >> >> >>>>> preferred solution to per-interface MIP message handling is >> >> >>>>> presented in this section] >> >> >>>>> >> >> >>>>> s1 >> >> >>>>> two (or more) MIPs per node on both sides of the forwarding >> >> engine. >> >> >>>>> [two on both sides sounds like four in total to me; suggest >> >> 'one on >> >> >>>>> each side of the forwarding engine'] >> >> >>>>> >> >> >>>>> s4 >> >> >>>>> o CV between a MEP and a MIP >> >> >>>>> [expand CV on first use] >> >> >>>>> >> >> >>>>> s5 >> >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >> >> MPLS-TP >> >> >>>>> LSPs and MPLS-TP PWs, respectively. >> >> >>>>> ['respectively' suggests to me that there should be two >> >> precedents, >> >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 >> for >> >> LSPs, >> >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this >> sentence >> >> as >> >> >>>>> redundant] >> >> >>>>> >> >> >>>>> s6 >> >> >>>>> The appendix of this document contains a >> >> >>>>> few solutions that the authors have discarded which have >> >> been >> >> >> left in >> >> >>>>> the document for informational purposes. >> >> >>>>> [not any more they haven't!] >> >> >>>>> >> >> >>>>> The node itself is addresses >> >> >>>>> [The node itself is addressed] >> >> >>>>> >> >> >>>>> The identification information indside [The identification >> >> >>>>> information inside ] >> >> >>>>> >> >> >>>>> MIP identifiers are not know >> >> >>>>> [MIP identifiers are not known] >> >> >>>>> >> >> >>>>> reserved MIP address >> >> >>>>> [reserved MIP addressses or a reserved MIP address] >> >> >>>>> >> >> >>>>> Tom Petch >> >> >>>>> >> >> >>>>> >> >> >>>>> ----- Original Message ----- >> >> >>>>> From: "Loa Andersson" >> >> >>>>> To: >> >> >>>>> Cc: ; > >> chairs@tools.ietf.org>; >> >> >>>>> "MPLS-TP ad hoc team" ; >> >> >>>>> >> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM >> >> >>>>> >> >> >>>>>> Working Group, >> >> >>>>>> >> >> >>>>>> This is to start a 2 week working group last call on >> >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. >> >> >>>>>> >> >> >>>>>> Please send your comments to the mpls working group >> mailing >> >> list >> >> >>>>>> (mpls@ietf.org). >> >> >>>>>> >> >> >>>>>> Please send both technical comments, and if you are happy >> >> with the >> >> >>>>>> document as is also indications of support. >> >> >>>>>> >> >> >>>>>> This working group last call will end on November 28. >> >> >>>>>> >> >> >>>>>> /Loa >> >> >>>>>> for the wg co-chairs >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> mpls mailing list >> >> >>>> mpls@ietf.org >> >> >>>> https://www.ietf.org/mailman/listinfo/mpls >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> mpls mailing list >> >> >>> mpls@ietf.org >> >> >>> https://www.ietf.org/mailman/listinfo/mpls >> >> >> _______________________________________________ >> >> >> mpls mailing list >> >> >> mpls@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> >> Road, London W3 6BL | Registered in England 2832014 >> >> > _______________________________________________ >> >> > mpls mailing list >> >> > mpls@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/mpls >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> mpls mailing list >> >> mpls@ietf.org >> >> https://www.ietf.org/mailman/listinfo/mpls >> > >> > > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From hideki.endo.es@hitachi.com Mon Dec 3 17:24:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8679021F8928 for ; Mon, 3 Dec 2012 17:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqEvkf0wP4mT for ; Mon, 3 Dec 2012 17:24:29 -0800 (PST) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5921F85E2 for ; Mon, 3 Dec 2012 17:24:29 -0800 (PST) Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 48D3433CC5; Tue, 4 Dec 2012 10:24:28 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id qB41OSf9020780; Tue, 4 Dec 2012 10:24:28 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB41ORvZ007972; Tue, 4 Dec 2012 10:24:27 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id DF0DB140046; Tue, 4 Dec 2012 10:24:26 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB41OQA18448564; Tue, 4 Dec 2012 10:24:26 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Tue, 4 Dec 2012 10:24:20 +0900 References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> Priority: normal Importance: normal X400-Content-Identifier: X50BD509300000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121204102331UTG] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 01:24:31 -0000 Hi Shahram, Back and forth. Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not. >I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. Don't you consider the case when MIPs is configured in the Egress port B,C and D? In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D. In that case, your solution has low effectiveness as I pointed out. Do I miss something? Thanks, Hideki Endo >Hi, > >Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW. > >Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW. > >Thanks, >Shahram > >-----Original Message----- >From: Shahram Davari >Sent: Monday, December 03, 2012 4:53 PM >To: 'hideki.endo.es@hitachi.com' >Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map > >Hi Hideki, > >I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. > >Thx >Shahram > >-----Original Message----- >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >Sent: Monday, December 03, 2012 4:48 PM >To: Shahram Davari >Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map > >Hi Shahram, > >First, as Rolf sent, we need in/out-MIP for >1. CV between a MEP and a MIP >2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >3. data-plane loopback configuration at a MIP >4. diagnostic tests >Here, CV means On-demand CV. You may misunderstand as Proactive CV. > >Second, you wrote; >"The issue is that each CPU/processor has limited resources. > By sending all OAM MIP packets to both processor you are > losing 1/2 of the capacity of each processor. " >It depends on implementations, >and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. >Let's consider P2MP case as you pointed out. >All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >This means that the OAM processor at port D loses its capacity. >If we consider the larger number of ports in the LSR which has 100 ports, for example, >All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >This means that the OAM processors at the other 98 ports lose those capacities. >Even if your solution using ACH header is applied, >it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >in the case of P2MP for 100 ports. > >Thanks, >Hideki Endo > > >>Rolf, >> >>For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: >> >>1) MIP on port A (In-MIP), or >>2) MIP on port B (out-MIP), or >>3) MEIP on Port A and B >> >>A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. >> >>Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. >> >>So the Pseudo-code is like this: >> >>Ingress Port: >> >>If packet is OAM and TTL=1 >> If MIP is enabled >> If packet indicates In-MIP >> Send to local CPU >> Else >> Forward to egress port >> End >> Else >> Forward normally >> End >>Else >> >>Egress Port: >> >>If packet is OAM and TTL=1 >> If MIP is enabled >> If packet indicates In-MIP >> Drop packet >> Else If packet indicates Out-MIP >> Send to local CPU >> End >> Else >> Drop packet >> End >>End >> >> >>Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? >> >>Thanks >>Shahram >> >>-----Original Message----- >>From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>Sent: Monday, December 03, 2012 12:10 PM >>To: Shahram Davari >>Cc: Pablo Frank; mpls@ietf.org >>Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >> >>But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. >> >>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: Shahram Davari [mailto:davari@broadcom.com] >>> Sent: Montag, 3. Dezember 2012 16:27 >>> To: Rolf Winter >>> Cc: Pablo Frank; mpls@ietf.org >>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>> mep-map >>> >>> Hi Rolf, >>> >>> Your HW guys are correct as long as the amount of data sent to the in- >>> MIP processor is not much. But from your previous email to Loa I see >>> that you want to also terminate CV at MIPs. CVs are fast and high >>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>> not be expecting them is like DoS attack. >>> >>> >>> >>> Regards, >>> Shahram >>> >>> >>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>> wrote: >>> >>> > Hi, >>> > >>> > sorry for the belated response. I checked with some of our HW people. >>> Here's the gist of their response: >>> > >>> > Of course they wouldn't like parsing TLVs but we established that >>> fact already. Their answer to the problem is slightly different though. >>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>> MIPs where, if the frame is not intended for them, it can safely be >>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>> implementation must behave in this exact way in either case. So there >>> is at least one way to implement this at line rate without going back >>> and changing a bunch of RFCs. >>> > >>> > Best, >>> > >>> > Rolf >>> > >>> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> > London W3 6BL | Registered in England 2832014 >>> > >>> > >>> >> -----Original Message----- >>> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>> >> Of Shahram Davari >>> >> Sent: Mittwoch, 28. November 2012 18:46 >>> >> To: Pablo Frank >>> >> Cc: mpls@ietf.org >>> >> Subject: Re: [mpls] working group last call on >>> >> draft-ietf-mpls-tp-mip- mep-map >>> >> >>> >> Pablo, >>> >> >>> >> >>> >> >>> >> That was exactly my point. Let's use a flag to indicate in-MIP or >>> >> out- MIP and then the offline processor can do MEPID lookup to >>> >> determine whether this is a legitimate OAM packet or not. >>> >> >>> >> >>> >> >>> >> Thx >>> >> Shahram >>> >> >>> >> >>> >> >>> >> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>> >> Sent: Wednesday, November 28, 2012 8:22 AM >>> >> To: Shahram Davari >>> >> Cc: mpls@ietf.org >>> >> Subject: Re: [mpls] working group last call on >>> >> draft-ietf-mpls-tp-mip- mep-map >>> >> >>> >> >>> >> >>> >> I think Shahram raises a very legitimate concern about how expensive >>> >> this could be to implement in hardware. >>> >> >>> >> >>> >> >>> >> As I understand it, the logic proposed by this draft is as follows: >>> >> >>> >> >>> >> >>> >> At the ingress blade: >>> >> >>> >> >>> >> >>> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>> >> >>> >> Parse MIP-ID TLV >>> >> >>> >> Lookup MIP-ID >>> >> >>> >> IF MIP-is-egress, THEN >>> >> >>> >> forward normally (but note we must intercept it again on >>> egress) >>> >> >>> >> ELSE >>> >> >>> >> punt to OAM processor >>> >> >>> >> >>> >> >>> >> At the egress blade: >>> >> >>> >> >>> >> >>> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>> >> >>> >> Parse MIP-ID TLV >>> >> >>> >> Lookup MIP-ID >>> >> >>> >> IF MIP-is-egress, THEN >>> >> >>> >> punt to OAM processor >>> >> >>> >> ELSE >>> >> >>> >> drop >>> >> >>> >> >>> >> >>> >> Note all this has to be done in the fast-path now at full line rate >>> >> (and hardware guys hate TLVs). Before, the only thing the fast-path >>> >> had to do was look for TTL-expiry. >>> >> >>> >> >>> >> >>> >> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>> >> of >>> >> -03 version of doc) was because it also required a MIP-ID lookup. >>> >> But I don't see anything wrong with combining both mechanisms. >>> >> Ideally, hardware could rely on the reserved bit to do the initial >>> >> filtering at full line-rate and then a presumably much more >>> >> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>> >> Instead of the complex logic above, the fast path gets a simple >>> >> modification to TTL handling and the OAM block does the heavy >>> lifting of dealing with ACH TLVs, etc. >>> >> >>> >> >>> >> >>> >> This seems like a case where practicality should trump elegance. >>> >> >>> >> >>> >> >>> >> regards, >>> >> >>> >> Pablo >>> >> >>> >> >>> >> >>> >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>> >> >>> >> wrote: >>> >> >>> >> >>> >> >>> >> > Rolf, >>> >> > >>> >> > I am sure you know that TLVs are not Hardware friendly. And I >>> >> think you agree with me that this draft requires deep parsing of all >>> >> packets at line rate to get to the MIPID TLV. >>> >> > >>> >> > I still think the MIPID TLV is required to decide whether an >>> OAM >>> >> packet ended up at the right MIP. But may be a simpler solution >>> >> could be augmented to decide between In-MIP and Out-MIP. For example >>> >> how about using one of the reserved bits in the ACH header. This >>> can >>> >> easily be done in hardware with minimum complexity. >>> >> > >>> >> > Regards, >>> >> > Shahram >>> >> > >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>> >> Behalf Of Rolf Winter >>> >> > Sent: Wednesday, November 21, 2012 12:13 PM >>> >> > To: S. Davari; adrian@olddog.co.uk >>> >> > Cc: mpls@ietf.org >>> >> > Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>> >> tp-mip-mep-map >>> >> > >>> >> > Hi, >>> >> > >>> >> >> Hi Adrian, >>> >> >> >>> >> >> You are right and I should have sent these types of comments >>> >> before >>> >> >> last call. I completely understand the procedure. >>> >> >> >>> >> >> One thing I didn't understand in your response is that you >>> said >>> >> in-MIP >>> >> >> requires to do the MEPID lookup at line rate anyway. Why is >>> >> that? >>> >> >> >>> >> >> My understanding is that before this draft, the process would >>> >> have >>> >> >> been for the ingress to look at TTL and if it is expired then >>> >> send the >>> >> >> packet to OAM processor. >>> >> > >>> >> > Yes (and no). While I assume likely MIP functionality will be >>> >> implemented on the ingress, the related RFCs are vague about the >>> >> actual placement of the MIP function. See e.g. the OAM Framework >>> (RFC >>> >> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>> >> location within the node)". >>> >> > >>> >> > Also, I think "before this draft" is not quite accurate in that >>> >> is suggests there is no per-interface MIP addressing possible as of >>> now. >>> >> Take RFC 6426. In practice this is where part of the problem lies. >>> We >>> >> cannot really go back and change all this. There are other >>> constraints. >>> >> E.g. we have a requirement to address a single out-MIP out of a set >>> >> of out-MIPs on a P2MP branch point. So this was part of the >>> >> constraints we worked with. >>> >> > >>> >> >> >>> >> >> The MEPID that you suggest in this draft is very useful for >>> >> filtering >>> >> >> out leaked OAM frames from upstream. But lets leave lookup of >>> >> the MEPID >>> >> >> to the OAM processing module (at slower rate) and add an >>> >> indicator to >>> >> >> the OAM packet to indicate whether it should be taken out of >>> >> the data >>> >> >> path in the Ingress or egress. >>> >> >> >>> >> >> So can I suggest adding the following text to the draft: >>> >> >> >>> >> >> " In addition to the MEPID, which is used to ultimately accept >>> >> or >>> >> >> filter out received OAM packets, OAM packets should have a >>> >> simple >>> >> >> indicator that identifies whether the OAM packet belongs to >>> >> in-MIP or >>> >> >> Out-MIP". >>> >> > >>> >> > We also have the question on where to retrofit those bits. I >>> >> assume a TLV wouldn't work for the exact reasons you do not like to >>> >> have to do a second lookup, since it would require some parsing. All >>> >> these constraints and the ones outlined in the document led to where >>> >> we are. In a sense this is a non-spec since it rather rules out a >>> >> number of things that seem like a good idea at first but then have a >>> >> catch of some sort. >>> >> > >>> >> > Best, >>> >> > >>> >> > Rolf >>> >> > >>> >> >> >>> >> >> >>> >> >> >>> >> >> Regards, >>> >> >> Shahram >>> >> >> >>> >> >> >>> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>> >> >>> >> >> wrote: >>> >> >> >>> >> >>> >>> >> >>> >>> >> >>> Hi Shahram, >>> >> >>> >>> >> >>> I am worried about the precedent of a comment like this >>> during >>> >> WG >>> >> >> last call. >>> >> >>> While comments that improve the document or point out >>> >> fundamental >>> >> >>> flaws are welcome whenever they arrive, points with the >>> >> flavour "I >>> >> >>> wouldn't have done it like this" that arrive this late in the >>> >> process >>> >> >> don't feel very constructive. >>> >> >>> But I will leave the chair to worry about process and try to >>> >> address >>> >> >>> the technical points... >>> >> >>> >>> >> >>>> Identifying whether to terminate an OAM packet and process >>> it >>> >> in In- >>> >> >> MIP vs. >>> >> >>> Out- >>> >> >>>> MIP requires line rate lookup, otherwise the OAM packet will >>> >> not >>> >> >> take >>> >> >>>> the same path as data packets. Therefore any MIP identifier >>> >> that is >>> >> >>>> proposed in this >>> >> >>> draft >>> >> >>>> requires one extra lookup and therefore adds significantly >>> to >>> >> cost. >>> >> >>> >>> >> >>> If I am not wrong, this is a feature of an out-MIP. If you >>> >> decide to >>> >> >>> implement out-MIPs, and if you want the OAM to follow exactly >>> >> the >>> >> >> same >>> >> >>> path as the data, then it is a requirement that the out >>> >> interface >>> >> >>> inspects the packets (at line >>> >> >>> rate) to determine whether they are OAM and targeted at the >>> >> interface. >>> >> >>> >>> >> >>> We cannot change that aspect. All we can do is aim to make >>> the >>> >> lookup >>> >> >>> as easy as possible. >>> >> >>> >>> >> >>>> Perhaps a >>> >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>> >> Level) may be >>> >> >>>> used that requires only 3 bits and achieves the same result. >>> >> >>> >>> >> >>> Perhaps it could. >>> >> >>> But before going there, why is the lookup in the current >>> >> version of >>> >> >>> the I-D arduous? >>> >> >>> >>> >> >>> Presumably you do not propose making any change to the way >>> >> In-MIPs >>> >> >> are >>> >> >>> currently identified, so the lookups being done at line rate >>> >> today on >>> >> >>> the incoming interfaces will not be changed. If you are >>> >> proposing >>> >> >> such >>> >> >>> a change, then the discussion is outside the scope of this I- >>> >> D and >>> >> >>> becomes a much wider question for the working group. >>> >> >>> >>> >> >>> This leaves me with the trade-off of enabling a *simpler* >>> >> lookup on >>> >> >>> the outgoing interfaces versus doing identical lookups on >>> both >>> >> >>> interfaces. My assumption was that if the incoming interface >>> >> can do >>> >> >>> the lookup at line rate, it is not hard to perform the same >>> >> lookup on >>> >> >>> the outgoing interface. Furthermore, there is a reduction in >>> >> >> complexity by having fewer things to look up. >>> >> >>> >>> >> >>> Another possibility is that the full lookup could be done on >>> >> the >>> >> >>> incoming interface and the packet marked for easy >>> interception >>> >> on the >>> >> >> outgoing interface. >>> >> >>> The concern with this approach is that the packet would no >>> >> longer be >>> >> >>> being forwarded exactly as data because it would be being >>> >> modified in >>> >> >> flight. >>> >> >>> Furthermore, in the case of P2MP, it is not enough to flag >>> the >>> >> packet >>> >> >>> as a local Out-MIP and further identifier-based lookup is >>> >> needed. >>> >> >>> >>> >> >>> Some of these issues were raised and discussed as the I-D >>> >> progressed, >>> >> >>> and some of the alternative solutions were tracked with their >>> >> pros >>> >> >> and >>> >> >>> cons in Appendix A of the I-D (look at revision -03). >>> >> >>> >>> >> >>> Thanks, >>> >> >>> Adrian >>> >> >>>> -----Original Message----- >>> >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>> On >>> >> Behalf >>> >> >>>> Of Adrian Farrel >>> >> >>>> Sent: Monday, November 19, 2012 8:45 AM >>> >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>> >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>> >> ; >>> >> >>> draft-ietf-mpls-tp-mip- >>> >> >>>> mep-map@tools.ietf.org >>> >> >>>> Subject: Re: [mpls] working group last call on >>> >> >>>> draft-ietf-mpls-tp-mip-mep-map >>> >> >>>> >>> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author >>> >> anything >>> >> >> else? >>> >> >>>> >>> >> >>>> The point was that when I started the I-D lots of people >>> were >>> >> saying >>> >> >>>> "it's complex" and "it can't be done" and "it won't be >>> >> backward >>> >> >> compatible". >>> >> >>>> >>> >> >>>> So the I-D says "here it is" >>> >> >>>> >>> >> >>>> A (sorry not to offer you excitement) >>> >> >>>> >>> >> >>>>> -----Original Message----- >>> >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] >>> >> >>>>> Sent: 19 November 2012 12:38 >>> >> >>>>> To: Loa Andersson; mpls@ietf.org >>> >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>> >> ; MPLS-TP ad >>> >> >>>>> hoc >>> >> >>> team; >>> >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>> >> >>>>> Subject: Re: [mpls] working group last call on >>> >> >>> draft-ietf-mpls-tp-mip-mep-map >>> >> >>>>> >>> >> >>>>> After getting to section 6 and its features (requirements!), >>> >> I find >>> >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>> >> >>>>> Informational and not Standards Track. >>> >> >>>>> >>> >> >>>>> Meanwhile, I suggest some editorial issues. >>> >> >>>>> >>> >> >>>>> Title >>> >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>> >> [Handling >>> >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>> >> >>>>> informative statement unless and until you get to the >>> >> definition of >>> >> >>>>> Internal in s3; and s6, which is the crux of the document >>> >> says The >>> >> >>>>> preferred solution to per-interface MIP message handling is >>> >> >>>>> presented in this section] >>> >> >>>>> >>> >> >>>>> s1 >>> >> >>>>> two (or more) MIPs per node on both sides of the forwarding >>> >> engine. >>> >> >>>>> [two on both sides sounds like four in total to me; suggest >>> >> 'one on >>> >> >>>>> each side of the forwarding engine'] >>> >> >>>>> >>> >> >>>>> s4 >>> >> >>>>> o CV between a MEP and a MIP >>> >> >>>>> [expand CV on first use] >>> >> >>>>> >>> >> >>>>> s5 >>> >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>> >> MPLS-TP >>> >> >>>>> LSPs and MPLS-TP PWs, respectively. >>> >> >>>>> ['respectively' suggests to me that there should be two >>> >> precedents, >>> >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 >>> for >>> >> LSPs, >>> >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>> sentence >>> >> as >>> >> >>>>> redundant] >>> >> >>>>> >>> >> >>>>> s6 >>> >> >>>>> The appendix of this document contains a >>> >> >>>>> few solutions that the authors have discarded which have >>> >> been >>> >> >> left in >>> >> >>>>> the document for informational purposes. >>> >> >>>>> [not any more they haven't!] >>> >> >>>>> >>> >> >>>>> The node itself is addresses >>> >> >>>>> [The node itself is addressed] >>> >> >>>>> >>> >> >>>>> The identification information indside [The identification >>> >> >>>>> information inside ] >>> >> >>>>> >>> >> >>>>> MIP identifiers are not know >>> >> >>>>> [MIP identifiers are not known] >>> >> >>>>> >>> >> >>>>> reserved MIP address >>> >> >>>>> [reserved MIP addressses or a reserved MIP address] >>> >> >>>>> >>> >> >>>>> Tom Petch >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> ----- Original Message ----- >>> >> >>>>> From: "Loa Andersson" >>> >> >>>>> To: >>> >> >>>>> Cc: ; >> >> chairs@tools.ietf.org>; >>> >> >>>>> "MPLS-TP ad hoc team" ; >>> >> >>>>> >>> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>> >> >>>>> >>> >> >>>>>> Working Group, >>> >> >>>>>> >>> >> >>>>>> This is to start a 2 week working group last call on >>> >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. >>> >> >>>>>> >>> >> >>>>>> Please send your comments to the mpls working group >>> mailing >>> >> list >>> >> >>>>>> (mpls@ietf.org). >>> >> >>>>>> >>> >> >>>>>> Please send both technical comments, and if you are happy >>> >> with the >>> >> >>>>>> document as is also indications of support. >>> >> >>>>>> >>> >> >>>>>> This working group last call will end on November 28. >>> >> >>>>>> >>> >> >>>>>> /Loa >>> >> >>>>>> for the wg co-chairs >>> >> >>>> >>> >> >>>> >>> >> >>>> _______________________________________________ >>> >> >>>> mpls mailing list >>> >> >>>> mpls@ietf.org >>> >> >>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >>> >>> >> >>> >>> >> >>> _______________________________________________ >>> >> >>> mpls mailing list >>> >> >>> mpls@ietf.org >>> >> >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> _______________________________________________ >>> >> >> mpls mailing list >>> >> >> mpls@ietf.org >>> >> >> https://www.ietf.org/mailman/listinfo/mpls >>> >> > >>> >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>> >> Road, London W3 6BL | Registered in England 2832014 >>> >> > _______________________________________________ >>> >> > mpls mailing list >>> >> > mpls@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/mpls >>> >> > >>> >> > >>> >> >>> >> _______________________________________________ >>> >> mpls mailing list >>> >> mpls@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/mpls >>> > >>> > >> >> >> >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls >> > > > From pagarwal@broadcom.com Mon Dec 3 21:44:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969BF21E8041 for ; Mon, 3 Dec 2012 21:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDMVeKQe+b6u for ; Mon, 3 Dec 2012 21:44:09 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC25B21E8044 for ; Mon, 3 Dec 2012 21:44:09 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 21:42:00 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 21:43:54 -0800 Received: from SJEXCHMB06.corp.ad.broadcom.com ( [fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 21:43:33 -0800 From: "Puneet Agarwal" To: "hideki.endo.es@hitachi.com" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eJLAQHjC8m1302u6b+ofzm6vQ== Date: Tue, 4 Dec 2012 05:43:32 +0000 Message-ID: <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com> References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA352A21QK14973449-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 05:44:10 -0000 Hi hideki, Is the determination that the mip identifier is present in the same locatio= n always in the pdu or is it variable (based on oam msg type)? Thx Puneet On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" wrote: > draft-ietf-mpls-tp-mip-mep-map From davarish@yahoo.com Mon Dec 3 22:00:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B321F89AD for ; Mon, 3 Dec 2012 22:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkulAvw-cN5K for ; Mon, 3 Dec 2012 22:00:36 -0800 (PST) Received: from nm10-vm1.bullet.mail.gq1.yahoo.com (nm10-vm1.bullet.mail.gq1.yahoo.com [98.136.218.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3010121F89AB for ; Mon, 3 Dec 2012 22:00:36 -0800 (PST) Received: from [98.137.12.174] by nm10.bullet.mail.gq1.yahoo.com with NNFMP; 04 Dec 2012 06:00:31 -0000 Received: from [98.137.0.25] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 04 Dec 2012 06:00:31 -0000 Received: from [127.0.0.1] by smtp118-mob.biz.mail.gq1.yahoo.com with NNFMP; 04 Dec 2012 06:00:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354600831; bh=wwGsq0zPRqrZY6BTGGame4f9Z7mRnjXZADF13D5TNkM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=6dYrhdFdLqw0g21UEc+tOrPPrGjWNB92ceYF8WwhwltbfP6U4x/TyGkOco9tbiIJyjpwgCoveqH5hOEMZBXVOLGXgLFJlW9BnRhP6vNUC4nbvzp1dfl3pIrkg/T40Cz1Mur1c1JEGehIGtr6oXKjtd0UF3YkARFBmuMtbEIcgS4= X-Yahoo-Newman-Id: 678432.21250.bm@smtp118-mob.biz.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LuxnJo8VM1mXNgyxaym2DshL.v5h2YdIdmJZligLw.30oLv iOsw0oGz97GIr546KZFA8s6YX8e2MF0Vf.N9Fdm6EXAUVkfyQuMqI3U1QEAe APioP6mr6bX8O8Ei5SfjrTsisKab_xM2tfL2qeZSR2vcdcOebz4uq3D9WJTv _4xCbV9CwCSFztcSCqgG3c2uvD6.H5lKIPqkhWEU3PVOt5yrl8srCyos6MUF 61QuDlt5lneWXCPRpG_SEenuE3GkeI_H5tN_eUEpYoOMhSJ95j5W8siV9ova N8DTabV518mu0qfWDPTPrRNxohcD9faSgE83Fi7_SZDQsAdi0brlaNE_bPxD TEviwl.dmKFMc.BACbmNlwhcblygtDhvXL3jf9nKr87Pu2s.gnyYs9lXWs_n 1b6HldCp2Muqh6_NuWPnjr9DT4454KL9lqeNpHCCn5qXrXcLtYyQLpJ.K47Y yfe.GOLFp3nBMW7Bsekjm8BQtGNAv7A-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [192.168.0.104] (davarish@98.248.36.11 with xymcookie) by smtp118-mob.biz.mail.gq1.yahoo.com with SMTP; 03 Dec 2012 22:00:31 -0800 PST References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Mon, 3 Dec 2012 22:00:29 -0800 To: "" Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 06:00:38 -0000 Hi Hideki, I think we have a fundamental problem statement difference. Based on your ex= amples I think you are looking in to how to send an OAM packet only to a sin= gle out-MIP out of Nxout-MIPs in a P2MP LSP. But I don't think this is architecturally sound or even required. Imagine th= ere is no in-MIP at all. We want a multicast OAM packet behaves like a data p= acket and be replicated to all egress ports. Now if a MIP is configured in s= ay 2 of the egress ports and not the other 98 ones, then the 98 egress ports= will drop the OAM packet in HW and won't send them to their CPU. For the ot= her 2 ports with Out-MIP, both will send the packets to their CPU and both C= PUs have to process and respond such as with link trace reply or Loopback re= ply, etc. Regards, Shahram On Dec 3, 2012, at 5:24 PM, wrote: > Hi Shahram, >=20 > Back and forth. > Here, let's focus on whether using MIP ID requires unnecessarily parsing i= n HW or not. >=20 >> I think you need to look at my p-code. F a MIP is not configured in the E= gress port, then that egress port won't sent the OAM packet to its processor= and drops it. So there is no issue with my proposed method. > Don't you consider the case when MIPs is configured in the Egress port B,C= and D? > In the case of P2MP, we need to identify the only one out-MIP of these out= -MIPs in port B,C and D. > In that case, your solution has low effectiveness as I pointed out. > Do I miss something? >=20 > Thanks, > Hideki Endo >=20 >=20 >> Hi, >>=20 >> Using MIP ID as the only method to filter OAM packets to CPU/Processor is= not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM= , etc. Each has its own format and the TLV can be anywhere. Using MIP ID as t= he only identifier requires unnecessarily parsing of all these different pac= ket types at line rate in HW. >>=20 >> Why not just use a simple bit in the ACH header? We need a n indicator in= a fixed location or the solution is not going to be practical in HW. >>=20 >> Thanks, >> Shahram >>=20 >> -----Original Message----- >> From: Shahram Davari=20 >> Sent: Monday, December 03, 2012 4:53 PM >> To: 'hideki.endo.es@hitachi.com' >> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-= mip-mep-map >>=20 >> Hi Hideki, >>=20 >> I think you need to look at my p-code. F a MIP is not configured in the E= gress port, then that egress port won't sent the OAM packet to its processor= and drops it. So there is no issue with my proposed method. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]=20 >> Sent: Monday, December 03, 2012 4:48 PM >> To: Shahram Davari >> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-= mep-map >>=20 >> Hi Shahram, >>=20 >> First, as Rolf sent, we need in/out-MIP for >> 1. CV between a MEP and a MIP >> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >> 3. data-plane loopback configuration at a MIP >> 4. diagnostic tests >> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>=20 >> Second, you wrote; >> "The issue is that each CPU/processor has limited resources.=20 >> By sending all OAM MIP packets to both processor you are=20 >> losing 1/2 of the capacity of each processor. " >> It depends on implementations, >> and this issue could NOT be resolved by even your solution that uses ACH h= eader to indicate in/out-MIP. >> Let's consider P2MP case as you pointed out. >> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >> This means that the OAM processor at port D loses its capacity. >> If we consider the larger number of ports in the LSR which has 100 ports,= for example, >> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >> This means that the OAM processors at the other 98 ports lose those capac= ities. >> Even if your solution using ACH header is applied, >> it can reduce OAM packets only for in-MIP, which means only 1/101 effecti= veness >> in the case of P2MP for 100 ports. >>=20 >> Thanks, >> Hideki Endo >>=20 >>=20 >>> Rolf, >>>=20 >>> For clarity it is better to use an example. Assume that an LSR has 4 por= ts (A, B, C, D). Now assume that it receives packets on a unicast LSP-X fr= om port A and forwards them to port B. there can only be 3 configurations:= >>>=20 >>> 1) MIP on port A (In-MIP), or >>> 2) MIP on port B (out-MIP), or >>> 3) MEIP on Port A and B >>>=20 >>> A single OAM packet can be terminated and processed only by one of these= MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). In y= our example, you are saying send a copy of the P to the CPU/Processor on Por= t A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop t= he packet since the MIP-ID is not A. The issue is that each CPU/processor h= as limited resources. By sending all OAM MIP packets to both processor you a= re losing 1/2 of the capacity of each processor. The practical solution is t= o have a simple indicator in the packet header that this OAM packet is meant= for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B= terminates and sends it to its CPU/processor. >>>=20 >>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chi= p from Port A and is sent to ports B, C, D. Also assume that there is In-MI= P on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM= packet is meant for out-MIPs (B, C). In such case the OAM packet should no= t be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D= . Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets a= nd does not send it to its CPU, since there is no MIP configured for that MP= LS label. >>>=20 >>> So the Pseudo-code is like this: >>>=20 >>> Ingress Port: >>>=20 >>> If packet is OAM and TTL=3D1 >>> If MIP is enabled >>> If packet indicates In-MIP >>> Send to local CPU >>> Else >>> Forward to egress port >>> End >>> Else >>> Forward normally >>> End >>> Else >>>=20 >>> Egress Port: >>>=20 >>> If packet is OAM and TTL=3D1 >>> If MIP is enabled >>> If packet indicates In-MIP >>> Drop packet >>> Else If packet indicates Out-MIP >>> Send to local CPU >>> End >>> Else >>> Drop packet >>> End >>> End >>> =20 >>>=20 >>> Using this example could you please describe your reasoning for not requ= iring HW to identify In-MEP vs out-MIPs? >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >>> Sent: Monday, December 03, 2012 12:10 PM >>> To: Shahram Davari >>> Cc: Pablo Frank; mpls@ietf.org >>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-me= p-map >>>=20 >>> But the MIP that is addressed needs to be able to handle this _plus_ tak= e an appropriate action and in the P2MP case this will always be the case si= nce there are 2 or more out MIPs. >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lond= on W3 6BL | Registered in England 2832014=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>> Sent: Montag, 3. Dezember 2012 16:27 >>>> To: Rolf Winter >>>> Cc: Pablo Frank; mpls@ietf.org >>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>>> mep-map >>>>=20 >>>> Hi Rolf, >>>>=20 >>>> Your HW guys are correct as long as the amount of data sent to the in- >>>> MIP processor is not much. But from your previous email to Loa I see >>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>>> not be expecting them is like DoS attack. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> sorry for the belated response. I checked with some of our HW people. >>>> Here's the gist of their response: >>>>>=20 >>>>> Of course they wouldn't like parsing TLVs but we established that >>>> fact already. Their answer to the problem is slightly different though.= >>>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>>> MIPs where, if the frame is not intended for them, it can safely be >>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>> implementation must behave in this exact way in either case. So there >>>> is at least one way to implement this at line rate without going back >>>> and changing a bunch of RFCs. >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Rolf >>>>>=20 >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>>> Of Shahram Davari >>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>> To: Pablo Frank >>>>>> Cc: mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>=20 >>>>>> Pablo, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thx >>>>>> Shahram >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>> To: Shahram Davari >>>>>> Cc: mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think Shahram raises a very legitimate concern about how expensive >>>>>> this could be to implement in hardware. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At the ingress blade: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>=20 >>>>>> Parse MIP-ID TLV >>>>>>=20 >>>>>> Lookup MIP-ID >>>>>>=20 >>>>>> IF MIP-is-egress, THEN >>>>>>=20 >>>>>> forward normally (but note we must intercept it again on >>>> egress) >>>>>>=20 >>>>>> ELSE >>>>>>=20 >>>>>> punt to OAM processor >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At the egress blade: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>=20 >>>>>> Parse MIP-ID TLV >>>>>>=20 >>>>>> Lookup MIP-ID >>>>>>=20 >>>>>> IF MIP-is-egress, THEN >>>>>>=20 >>>>>> punt to OAM processor >>>>>>=20 >>>>>> ELSE >>>>>>=20 >>>>>> drop >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-path >>>>>> had to do was look for TTL-expiry. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>> of >>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>> filtering at full line-rate and then a presumably much more >>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>> modification to TTL handling and the OAM block does the heavy >>>> lifting of dealing with ACH TLVs, etc. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This seems like a case where practicality should trump elegance. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> regards, >>>>>>=20 >>>>>> Pablo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Rolf, >>>>>>>=20 >>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>> think you agree with me that this draft requires deep parsing of all >>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>=20 >>>>>>> I still think the MIPID TLV is required to decide whether an >>>> OAM >>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>> could be augmented to decide between In-MIP and Out-MIP. For example >>>>>> how about using one of the reserved bits in the ACH header. This >>>> can >>>>>> easily be done in hardware with minimum complexity. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Shahram >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>> Behalf Of Rolf Winter >>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>> tp-mip-mep-map >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>>> Hi Adrian, >>>>>>>>=20 >>>>>>>> You are right and I should have sent these types of comments >>>>>> before >>>>>>>> last call. I completely understand the procedure. >>>>>>>>=20 >>>>>>>> One thing I didn't understand in your response is that you >>>> said >>>>>> in-MIP >>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>> that? >>>>>>>>=20 >>>>>>>> My understanding is that before this draft, the process would >>>>>> have >>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>> send the >>>>>>>> packet to OAM processor. >>>>>>>=20 >>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>> (RFC >>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>> location within the node)". >>>>>>>=20 >>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>> is suggests there is no per-interface MIP addressing possible as of >>>> now. >>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>> We >>>>>> cannot really go back and change all this. There are other >>>> constraints. >>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>> constraints we worked with. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>> filtering >>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>> the MEPID >>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>> indicator to >>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>> the data >>>>>>>> path in the Ingress or egress. >>>>>>>>=20 >>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>=20 >>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>> or >>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>> simple >>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>> in-MIP or >>>>>>>> Out-MIP". >>>>>>>=20 >>>>>>> We also have the question on where to retrofit those bits. I >>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>> have to do a second lookup, since it would require some parsing. All >>>>>> these constraints and the ones outlined in the document led to where >>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>> number of things that seem like a good idea at first but then have a >>>>>> catch of some sort. >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Rolf >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Shahram >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> Hi Shahram, >>>>>>>>>=20 >>>>>>>>> I am worried about the precedent of a comment like this >>>> during >>>>>> WG >>>>>>>> last call. >>>>>>>>> While comments that improve the document or point out >>>>>> fundamental >>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>> flavour "I >>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>> process >>>>>>>> don't feel very constructive. >>>>>>>>> But I will leave the chair to worry about process and try to >>>>>> address >>>>>>>>> the technical points... >>>>>>>>>=20 >>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>> it >>>>>> in In- >>>>>>>> MIP vs. >>>>>>>>> Out- >>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>> not >>>>>>>> take >>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>> that is >>>>>>>>>> proposed in this >>>>>>>>> draft >>>>>>>>>> requires one extra lookup and therefore adds significantly >>>> to >>>>>> cost. >>>>>>>>>=20 >>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>> decide to >>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>> the >>>>>>>> same >>>>>>>>> path as the data, then it is a requirement that the out >>>>>> interface >>>>>>>>> inspects the packets (at line >>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>> interface. >>>>>>>>>=20 >>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>> the >>>>>> lookup >>>>>>>>> as easy as possible. >>>>>>>>>=20 >>>>>>>>>> Perhaps a >>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>> Level) may be >>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>=20 >>>>>>>>> Perhaps it could. >>>>>>>>> But before going there, why is the lookup in the current >>>>>> version of >>>>>>>>> the I-D arduous? >>>>>>>>>=20 >>>>>>>>> Presumably you do not propose making any change to the way >>>>>> In-MIPs >>>>>>>> are >>>>>>>>> currently identified, so the lookups being done at line rate >>>>>> today on >>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>> proposing >>>>>>>> such >>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>> D and >>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>=20 >>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>> lookup on >>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>> both >>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>> can do >>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>> lookup on >>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>> complexity by having fewer things to look up. >>>>>>>>>=20 >>>>>>>>> Another possibility is that the full lookup could be done on >>>>>> the >>>>>>>>> incoming interface and the packet marked for easy >>>> interception >>>>>> on the >>>>>>>> outgoing interface. >>>>>>>>> The concern with this approach is that the packet would no >>>>>> longer be >>>>>>>>> being forwarded exactly as data because it would be being >>>>>> modified in >>>>>>>> flight. >>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>> the >>>>>> packet >>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>> needed. >>>>>>>>>=20 >>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>> progressed, >>>>>>>>> and some of the alternative solutions were tracked with their >>>>>> pros >>>>>>>> and >>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Adrian >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>> On >>>>>> Behalf >>>>>>>>>> Of Adrian Farrel >>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>> ; >>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>=20 >>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>> anything >>>>>>>> else? >>>>>>>>>>=20 >>>>>>>>>> The point was that when I started the I-D lots of people >>>> were >>>>>> saying >>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>> backward >>>>>>>> compatible". >>>>>>>>>>=20 >>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>=20 >>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>> ; MPLS-TP ad >>>>>>>>>>> hoc >>>>>>>>> team; >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>=20 >>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>> I find >>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>=20 >>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>=20 >>>>>>>>>>> Title >>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>> [Handling >>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>> informative statement unless and until you get to the >>>>>> definition of >>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>> says The >>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>> presented in this section] >>>>>>>>>>>=20 >>>>>>>>>>> s1 >>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>> engine. >>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>> 'one on >>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>=20 >>>>>>>>>>> s4 >>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>=20 >>>>>>>>>>> s5 >>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>> MPLS-TP >>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>> precedents, >>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>> for >>>>>> LSPs, >>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>> sentence >>>>>> as >>>>>>>>>>> redundant] >>>>>>>>>>>=20 >>>>>>>>>>> s6 >>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>> few solutions that the authors have discarded which have >>>>>> been >>>>>>>> left in >>>>>>>>>>> the document for informational purposes. >>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>=20 >>>>>>>>>>> The node itself is addresses >>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>=20 >>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>> information inside ] >>>>>>>>>>>=20 >>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>=20 >>>>>>>>>>> reserved MIP address >>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>=20 >>>>>>>>>>> Tom Petch >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>> To: >>>>>>>>>>> Cc: ; >>>>> chairs@tools.ietf.org>; >>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>> >>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>=20 >>>>>>>>>>>> Working Group, >>>>>>>>>>>>=20 >>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please send your comments to the mpls working group >>>> mailing >>>>>> list >>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>=20 >>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>> with the >>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>=20 >>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>=20 >>>>>>>>>>>> /Loa >>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>=20 >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Mon Dec 3 22:27:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0341221F8987 for ; Mon, 3 Dec 2012 22:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.261 X-Spam-Level: X-Spam-Status: No, score=-5.261 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx5yqzl59i0c for ; Mon, 3 Dec 2012 22:27:28 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6D21F895E for ; Mon, 3 Dec 2012 22:27:28 -0800 (PST) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 03 Dec 2012 22:22:48 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 3 Dec 2012 22:27:14 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 3 Dec 2012 22:27:14 -0800 From: "Shahram Davari" To: "S. Davari" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eSzpLD1DDXpvkKpSj865WibkJgILQI0 Date: Tue, 4 Dec 2012 06:27:13 +0000 Message-ID: References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> , <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> In-Reply-To: <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA3493239W4907559-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 06:27:31 -0000 Hideki, In summary your requirement is similar to Figure 7 , where you are going to= bypass the normal forwarding engine and do unicast forwarding of a multic= ast OAM packet to a single outgoing port. This kind of behavior is expli= citly rejected in the draft. Regards, Shahram On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: > Hi Hideki, >=20 > I think we have a fundamental problem statement difference. Based on your= examples I think you are looking in to how to send an OAM packet only to a= single out-MIP out of Nxout-MIPs in a P2MP LSP. >=20 > But I don't think this is architecturally sound or even required. Imagine= there is no in-MIP at all. We want a multicast OAM packet behaves like a d= ata packet and be replicated to all egress ports. Now if a MIP is configure= d in say 2 of the egress ports and not the other 98 ones, then the 98 egres= s ports will drop the OAM packet in HW and won't send them to their CPU. Fo= r the other 2 ports with Out-MIP, both will send the packets to their CPU a= nd both CPUs have to process and respond such as with link trace reply or L= oopback reply, etc. >=20 >=20 > Regards, > Shahram >=20 >=20 > On Dec 3, 2012, at 5:24 PM, wrote: >=20 >> Hi Shahram, >>=20 >> Back and forth. >> Here, let's focus on whether using MIP ID requires unnecessarily parsing= in HW or not. >>=20 >>> I think you need to look at my p-code. F a MIP is not configured in the= Egress port, then that egress port won't sent the OAM packet to its proces= sor and drops it. So there is no issue with my proposed method. >> Don't you consider the case when MIPs is configured in the Egress port B= ,C and D? >> In the case of P2MP, we need to identify the only one out-MIP of these o= ut-MIPs in port B,C and D. >> In that case, your solution has low effectiveness as I pointed out. >> Do I miss something? >>=20 >> Thanks, >> Hideki Endo >>=20 >>=20 >>> Hi, >>>=20 >>> Using MIP ID as the only method to filter OAM packets to CPU/Processor = is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM= /DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID= as the only identifier requires unnecessarily parsing of all these differe= nt packet types at line rate in HW. >>>=20 >>> Why not just use a simple bit in the ACH header? We need a n indicator = in a fixed location or the solution is not going to be practical in HW. >>>=20 >>> Thanks, >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Shahram Davari=20 >>> Sent: Monday, December 03, 2012 4:53 PM >>> To: 'hideki.endo.es@hitachi.com' >>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-t= p-mip-mep-map >>>=20 >>> Hi Hideki, >>>=20 >>> I think you need to look at my p-code. F a MIP is not configured in the= Egress port, then that egress port won't sent the OAM packet to its proces= sor and drops it. So there is no issue with my proposed method. >>>=20 >>> Thx >>> Shahram >>>=20 >>> -----Original Message----- >>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]=20 >>> Sent: Monday, December 03, 2012 4:48 PM >>> To: Shahram Davari >>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mi= p-mep-map >>>=20 >>> Hi Shahram, >>>=20 >>> First, as Rolf sent, we need in/out-MIP for >>> 1. CV between a MEP and a MIP >>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >>> 3. data-plane loopback configuration at a MIP >>> 4. diagnostic tests >>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>=20 >>> Second, you wrote; >>> "The issue is that each CPU/processor has limited resources.=20 >>> By sending all OAM MIP packets to both processor you are=20 >>> losing 1/2 of the capacity of each processor. " >>> It depends on implementations, >>> and this issue could NOT be resolved by even your solution that uses AC= H header to indicate in/out-MIP. >>> Let's consider P2MP case as you pointed out. >>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>> This means that the OAM processor at port D loses its capacity. >>> If we consider the larger number of ports in the LSR which has 100 port= s, for example, >>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>> This means that the OAM processors at the other 98 ports lose those cap= acities. >>> Even if your solution using ACH header is applied, >>> it can reduce OAM packets only for in-MIP, which means only 1/101 effec= tiveness >>> in the case of P2MP for 100 ports. >>>=20 >>> Thanks, >>> Hideki Endo >>>=20 >>>=20 >>>> Rolf, >>>>=20 >>>> For clarity it is better to use an example. Assume that an LSR has 4 p= orts (A, B, C, D). Now assume that it receives packets on a unicast LSP-X= from port A and forwards them to port B. there can only be 3 configurati= ons: >>>>=20 >>>> 1) MIP on port A (In-MIP), or >>>> 2) MIP on port B (out-MIP), or >>>> 3) MEIP on Port A and B >>>>=20 >>>> A single OAM packet can be terminated and processed only by one of the= se MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). = In your example, you are saying send a copy of the P to the CPU/Processor o= n Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will = drop the packet since the MIP-ID is not A. The issue is that each CPU/proc= essor has limited resources. By sending all OAM MIP packets to both proces= sor you are losing 1/2 of the capacity of each processor. The practical so= lution is to have a simple indicator in the packet header that this OAM pac= ket is meant for Out-MIP. Then port A just switches the OAM packet to Port = B, and Port B terminates and sends it to its CPU/processor. >>>>=20 >>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the c= hip from Port A and is sent to ports B, C, D. Also assume that there is In= -MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast= OAM packet is meant for out-MIPs (B, C). In such case the OAM packet shou= ld not be sent to port A CPU/Processor. It is therefore multicast to ports = B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM = packets and does not send it to its CPU, since there is no MIP configured f= or that MPLS label. >>>>=20 >>>> So the Pseudo-code is like this: >>>>=20 >>>> Ingress Port: >>>>=20 >>>> If packet is OAM and TTL=3D1 >>>> If MIP is enabled >>>> If packet indicates In-MIP >>>> Send to local CPU >>>> Else >>>> Forward to egress port >>>> End >>>> Else >>>> Forward normally >>>> End >>>> Else >>>>=20 >>>> Egress Port: >>>>=20 >>>> If packet is OAM and TTL=3D1 >>>> If MIP is enabled >>>> If packet indicates In-MIP >>>> Drop packet >>>> Else If packet indicates Out-MIP >>>> Send to local CPU >>>> End >>>> Else >>>> Drop packet >>>> End >>>> End >>>>=20 >>>>=20 >>>> Using this example could you please describe your reasoning for not re= quiring HW to identify In-MEP vs out-MIPs? >>>>=20 >>>> Thanks >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >>>> Sent: Monday, December 03, 2012 12:10 PM >>>> To: Shahram Davari >>>> Cc: Pablo Frank; mpls@ietf.org >>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-= mep-map >>>>=20 >>>> But the MIP that is addressed needs to be able to handle this _plus_ t= ake an appropriate action and in the P2MP case this will always be the case= since there are 2 or more out MIPs. >>>>=20 >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>> To: Rolf Winter >>>>> Cc: Pablo Frank; mpls@ietf.org >>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip= - >>>>> mep-map >>>>>=20 >>>>> Hi Rolf, >>>>>=20 >>>>> Your HW guys are correct as long as the amount of data sent to the in= - >>>>> MIP processor is not much. But from your previous email to Loa I see >>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>> bandwidth and blindly dumping them on a CPU or OAM processor that ma= y >>>>> not be expecting them is like DoS attack. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, >>>>> Shahram >>>>>=20 >>>>>=20 >>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>> wrote: >>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> sorry for the belated response. I checked with some of our HW people= . >>>>> Here's the gist of their response: >>>>>>=20 >>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>> fact already. Their answer to the problem is slightly different thoug= h. >>>>> A TTL-expired OAM frame can simply be copied and forwarded to the out= - >>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>>> implementation must behave in this exact way in either case. So there >>>>> is at least one way to implement this at line rate without going back >>>>> and changing a bunch of RFCs. >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Rolf >>>>>>=20 >>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>> London W3 6BL | Registered in England 2832014 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behal= f >>>>>>> Of Shahram Davari >>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>> To: Pablo Frank >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: Re: [mpls] working group last call on >>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>=20 >>>>>>> Pablo, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thx >>>>>>> Shahram >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>> To: Shahram Davari >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: Re: [mpls] working group last call on >>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I think Shahram raises a very legitimate concern about how expensiv= e >>>>>>> this could be to implement in hardware. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> At the ingress blade: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>=20 >>>>>>> Parse MIP-ID TLV >>>>>>>=20 >>>>>>> Lookup MIP-ID >>>>>>>=20 >>>>>>> IF MIP-is-egress, THEN >>>>>>>=20 >>>>>>> forward normally (but note we must intercept it again on >>>>> egress) >>>>>>>=20 >>>>>>> ELSE >>>>>>>=20 >>>>>>> punt to OAM processor >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> At the egress blade: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>=20 >>>>>>> Parse MIP-ID TLV >>>>>>>=20 >>>>>>> Lookup MIP-ID >>>>>>>=20 >>>>>>> IF MIP-is-egress, THEN >>>>>>>=20 >>>>>>> punt to OAM processor >>>>>>>=20 >>>>>>> ELSE >>>>>>>=20 >>>>>>> drop >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-pat= h >>>>>>> had to do was look for TTL-expiry. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>>> of >>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>>> filtering at full line-rate and then a presumably much more >>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>> modification to TTL handling and the OAM block does the heavy >>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> regards, >>>>>>>=20 >>>>>>> Pablo >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Rolf, >>>>>>>>=20 >>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>> think you agree with me that this draft requires deep parsing of al= l >>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>=20 >>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>> OAM >>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>> could be augmented to decide between In-MIP and Out-MIP. For exampl= e >>>>>>> how about using one of the reserved bits in the ACH header. This >>>>> can >>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Shahram >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>> Behalf Of Rolf Winter >>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>> Cc: mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>> tp-mip-mep-map >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>>> Hi Adrian, >>>>>>>>>=20 >>>>>>>>> You are right and I should have sent these types of comments >>>>>>> before >>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>=20 >>>>>>>>> One thing I didn't understand in your response is that you >>>>> said >>>>>>> in-MIP >>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>> that? >>>>>>>>>=20 >>>>>>>>> My understanding is that before this draft, the process would >>>>>>> have >>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>> send the >>>>>>>>> packet to OAM processor. >>>>>>>>=20 >>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>> (RFC >>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>>> location within the node)". >>>>>>>>=20 >>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>> is suggests there is no per-interface MIP addressing possible as of >>>>> now. >>>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>>> We >>>>>>> cannot really go back and change all this. There are other >>>>> constraints. >>>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>> constraints we worked with. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>> filtering >>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>> the MEPID >>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>> indicator to >>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>> the data >>>>>>>>> path in the Ingress or egress. >>>>>>>>>=20 >>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>=20 >>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>> or >>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>> simple >>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>> in-MIP or >>>>>>>>> Out-MIP". >>>>>>>>=20 >>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>>> have to do a second lookup, since it would require some parsing. Al= l >>>>>>> these constraints and the ones outlined in the document led to wher= e >>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>> number of things that seem like a good idea at first but then have = a >>>>>>> catch of some sort. >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Rolf >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Shahram >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> >>>>>>>>>>=20 >>>>>>>>>> Hi Shahram, >>>>>>>>>>=20 >>>>>>>>>> I am worried about the precedent of a comment like this >>>>> during >>>>>>> WG >>>>>>>>> last call. >>>>>>>>>> While comments that improve the document or point out >>>>>>> fundamental >>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>> flavour "I >>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>> process >>>>>>>>> don't feel very constructive. >>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>> address >>>>>>>>>> the technical points... >>>>>>>>>>=20 >>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>> it >>>>>>> in In- >>>>>>>>> MIP vs. >>>>>>>>>> Out- >>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>> not >>>>>>>>> take >>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>> that is >>>>>>>>>>> proposed in this >>>>>>>>>> draft >>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>> to >>>>>>> cost. >>>>>>>>>>=20 >>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>> decide to >>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>> the >>>>>>>>> same >>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>> interface >>>>>>>>>> inspects the packets (at line >>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>> interface. >>>>>>>>>>=20 >>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>> the >>>>>>> lookup >>>>>>>>>> as easy as possible. >>>>>>>>>>=20 >>>>>>>>>>> Perhaps a >>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>> Level) may be >>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>=20 >>>>>>>>>> Perhaps it could. >>>>>>>>>> But before going there, why is the lookup in the current >>>>>>> version of >>>>>>>>>> the I-D arduous? >>>>>>>>>>=20 >>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>> In-MIPs >>>>>>>>> are >>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>> today on >>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>> proposing >>>>>>>>> such >>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>> D and >>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>=20 >>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>> lookup on >>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>> both >>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>> can do >>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>> lookup on >>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>=20 >>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>> the >>>>>>>>>> incoming interface and the packet marked for easy >>>>> interception >>>>>>> on the >>>>>>>>> outgoing interface. >>>>>>>>>> The concern with this approach is that the packet would no >>>>>>> longer be >>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>> modified in >>>>>>>>> flight. >>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>> the >>>>>>> packet >>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>> needed. >>>>>>>>>>=20 >>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>> progressed, >>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>> pros >>>>>>>>> and >>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Adrian >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>> On >>>>>>> Behalf >>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>> ; >>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>=20 >>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>> anything >>>>>>>>> else? >>>>>>>>>>>=20 >>>>>>>>>>> The point was that when I started the I-D lots of people >>>>> were >>>>>>> saying >>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>> backward >>>>>>>>> compatible". >>>>>>>>>>>=20 >>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>=20 >>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>> ; MPLS-TP ad >>>>>>>>>>>> hoc >>>>>>>>>> team; >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>=20 >>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>> I find >>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>=20 >>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>=20 >>>>>>>>>>>> Title >>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>> [Handling >>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>> informative statement unless and until you get to the >>>>>>> definition of >>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>> says The >>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>> presented in this section] >>>>>>>>>>>>=20 >>>>>>>>>>>> s1 >>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>> engine. >>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>> 'one on >>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>=20 >>>>>>>>>>>> s4 >>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>=20 >>>>>>>>>>>> s5 >>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>> MPLS-TP >>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>> precedents, >>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>> for >>>>>>> LSPs, >>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>> sentence >>>>>>> as >>>>>>>>>>>> redundant] >>>>>>>>>>>>=20 >>>>>>>>>>>> s6 >>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>> been >>>>>>>>> left in >>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>=20 >>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>=20 >>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>> information inside ] >>>>>>>>>>>>=20 >>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>=20 >>>>>>>>>>>> reserved MIP address >>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>=20 >>>>>>>>>>>> Tom Petch >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>> To: >>>>>>>>>>>> Cc: ; >>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>> >>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>=20 >>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please send your comments to the mpls working group >>>>> mailing >>>>>>> list >>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>> with the >>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> /Loa >>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>=20 >>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 From Rolf.Winter@neclab.eu Tue Dec 4 00:00:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A621F896F for ; Tue, 4 Dec 2012 00:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Meggn4bEArGX for ; Tue, 4 Dec 2012 00:00:04 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5836821F896C for ; Tue, 4 Dec 2012 00:00:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5E656102820; Tue, 4 Dec 2012 09:00:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AUwvM4wEHLG; Tue, 4 Dec 2012 09:00:03 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 35C64102826; Tue, 4 Dec 2012 08:59:53 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 08:59:53 +0100 From: Rolf Winter To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLCAAD1PAIAAL8Jw///5M4CAAMon4A== Date: Tue, 4 Dec 2012 07:59:42 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:00:05 -0000 Hi Greg, you might not be convinced but there are operators that have asked for this= functionality based on operational experience.=20 Quoting the OAM framework RFC: " Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets." Clearly having multiple MIPs per LSP is allowed as per the OAM framework. I= think however the sentence "All the intermediate nodes and possibly the en= d nodes host MIP(s)" should really be ""All the intermediate nodes and poss= ibly the end nodes can host MIP(s)" (Is this worth filing an errata?). I do= n't see why one wants to arbitrarily restrict the number of MIPs per LSP. B= TW, as you mention, the support of multiple MIPs in Ethernet is optional. Q= uoting the OAM framework again: "Support of per-interface or per-node MIPs is an implementation choice." So where's the difference? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Montag, 3. Dezember 2012 21:47 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Rolf, > I've been thinking about that requirement for some time and am not > convinced that such requirement, support multiple MIP per LSP/PW on > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single MIP > per MD/MEG Level is required and support of multiple MIPs is optional. > True, multiple MIPs of different MD/MEG Levels might be enabled on a > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus such > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat- > plane loopback can be used on uni-directional construct. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > ] > Sent: Monday, December 03, 2012 12:15 PM > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Greg, >=20 > But that's the whole point of the document. There can be multiple in- > and out-MIPs per LSP plus in the P2MP case there can be multiple out- > MIPs per node. It cannot be based local configuration. There has to be > information inside the OAM frame to address the respective MIP. Section > 4 of the document has a (I believe) pretty good example of this. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > ] > > Sent: Montag, 3. Dezember 2012 19:20 > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Rolf, > > Do you envision that multiple MIPs, both in- and out-, required to be > > supported on a given LSP/PW? I think that only single MIP > required > > per LSP/PW on an LSR/PE node. If that is the case, then there might > be > > no apparent need to explicitly address in- and out- MIP as such > > distinction becomes part of local configuration. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org > > ] On Behalf Of Rolf Winter > > Sent: Monday, December 03, 2012 5:42 AM > > To: Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp- > mip- > > mep-map > > > > Loa, > > > > These have been mentioned: > > > > 1. CV between a MEP and a MIP > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > MIPs > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.nu ] > > > Sent: Freitag, 30. November 2012 11:41 > > > To: mpls@ietf.org > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > > mpls-ads@tools.ietf.org > > > Subject: Re: working group last call on draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Authors, > > > > > > Can you plese give me an indication of which OAM functions the > > > separation of in and out MIPs are intended for? > > > > > > /Loa > > > > > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > > > Working Group, > > > > > > > > This is to start a 2 week working group last call on > > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > > > Please send your comments to the mpls working group mailing list > > > > (mpls@ietf.org). > > > > > > > > Please send both technical comments, and if you are happy with > the > > > > document as is also indications of support. > > > > > > > > This working group last call will end on November 28. > > > > > > > > /Loa > > > > for the wg co-chairs > > > > > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 From xuxiaohu@huawei.com Tue Dec 4 00:26:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBCC21F8464 for ; Tue, 4 Dec 2012 00:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZfCmkzgbg3s for ; Tue, 4 Dec 2012 00:26:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2A21F85E6 for ; Tue, 4 Dec 2012 00:26:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANL76301; Tue, 04 Dec 2012 08:26:50 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 08:26:24 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 16:26:48 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 16:26:46 +0800 From: Xuxiaohu To: "Eric Osborne (eosborne)" , "draft-xu-mpls-in-udp@tools.ietf.org" , "nsheth@contrailsystems.com" , "mpls-chairs@tools.ietf.org" , "martin.vigoureux@alcatel-lucent.com" Thread-Topic: MPLS-RT review of draft-xu-mpls-in-udp-03 Thread-Index: Ac3NfUp39NHPz5QCS56jxBrCvqzmZgEd4Yog Date: Tue, 4 Dec 2012 08:26:46 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586675@szxeml525-mbs.china.huawei.com> References: <20ECF67871905846A80F77F8F4A275721002E05F@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721002E05F@xmb-rcd-x09.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:26:55 -0000 SGkgRXJpYywNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBFcmljIE9zYm9ybmUg KGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTLE 6jEx1MIyOMjVIDIzOjUzDQo+IMrVvP7IyzogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0 Zi5vcmc7IG5zaGV0aEBjb250cmFpbHN5c3RlbXMuY29tOw0KPiBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgbWFydGluLnZpZ291cmV1eEBhbGNhdGVsLWx1Y2VudC5jb20NCj4gs63LzTogbXBs c0BpZXRmLm9yZw0KPiDW98ziOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC14dS1tcGxzLWluLXVk cC0wMw0KPiANCj4gSSAgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50LiAgTGlrZSB0aGUgb3Ro ZXIgcmV2aWV3ZXJzLCBJIGFncmVlIHRoYXQgaXQNCj4gY2xlYXJseSBkZXNjcmliZXMgd2hhdCBp dCB3YW50cyBhbmQgc2hvdWxkIGJlIHByb2dyZXNzZWQgdG8gdGhlIFdHIGFzIGENCj4gcG90ZW50 aWFsIFdHIGRvY3VtZW50Lg0KPiANCj4gVGhhdCBzYWlkLCBJIGhhdmUgc29tZSBjb25jZXJucyBh bmQgY29tbWVudHMuDQo+IA0KPiAjMTogSSdtIG5vdCBzdXJlIGlmIFNlY3Rpb24gNCBkb2VzIG1v cmUgaGFybSB0aGFuIGdvb2QuICBJZiBhbiBhcHBsaWNhdGlvbiBpcw0KPiBnb2luZyB0byByZWNl aXZlIHBhY2tldHMgdG8gYW4gJ01QTFMnIFVEUCBwb3J0LCBpdCBzZWVtcyBsaWtlIGEgZ29vZCBp ZGVhIGZvciBhDQo+IG5vZGUgdG8gYW5ub3VuY2UgdGhhdCBpdCBoYXMgdGhlIGNhcGFiaWxpdHkg dG8gcmVjZWl2ZSB0aGluZ3Mgb24gdGhpcyBwb3J0LiAgVGhpcw0KPiBpcyBub3QgbWFuZGF0b3J5 LCBzbyBpdCBzaG91bGQgYmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiAgSSBub3RlIHRoYXQgcmZj NDAyMw0KPiAoTVBMUyBpbiBHUkUpIGRvZXMgbm90IHByb3ZpZGUgc3VjaCBhIGZ1bmN0aW9uLg0K DQo+IFRoZSBkb2N1bWVudCBzdWdnZXN0cyBvbmUgd2F5IHRoYXQgdGhpcyBtaWdodCBiZSBhY2hp ZXZlZCB1c2luZyBCR1AuICBJdA0KPiBjb21lcyBwcmV0dHkgY2xvc2UgdG8gc3BlY2lmeWluZyBo b3cgaXQgc2hvdWxkIHdvcmssIGJ1dCB0aGUgd2hvbGUgc2VjdGlvbiBpcw0KPiBhcHBhcmVudGx5 IGp1c3QgYW4gZXhhbXBsZSBvciBhIHBsYWNlaG9sZGVyIGZvciBhIGZ1dHVyZSBkb2N1bWVudC4g IFRoaXMNCj4gc2VlbXMgZGFuZ2Vyb3VzLCBhcyBhbiBpbXBsZW1lbnRvciBtYXkgaW1wbGVtZW50 IHRoZSBmdW5jdGlvbiBhcyBkZXNjcmliZWQNCj4gaW4gdGhpcyBzZWN0aW9uIGRlc3BpdGUgaXQg ZXhwbGljaXRseSBiZWluZyBhbiBleGFtcGxlIGFuZCBhIHBsYWNlaG9sZGVyLg0KPiANCj4gSWYg dGhlcmUgaXMgY29uc2Vuc3VzIHRoYXQgYWR2ZXJ0aXNpbmcgKG9yIG5lZ290aWF0aW5nPykgdGhp cyBjYXBhYmlsaXR5IGlzDQo+IHJlcXVpcmVkLCB0aGVuIHRoaXMgY2FwYWJpbGl0eSBzaG91bGQg YmUgc3RhbmRhcmRpemVkIGF0IHRoZSBzYW1lIHRpbWUgYXMgdGhlDQo+IGFjdHVhbCBlbmNhcHN1 bGF0aW9uLiAgSWYgdGhpcyBjYXBhYmlsaXR5IGlzIG5vdCByZXF1aXJlZCB0aGVuIHRoaXMgc2Vj dGlvbiBzaG91bGQNCj4gYmUgcmVtb3ZlZCBmcm9tIHRoZSBkb2N1bWVudC4NCg0KVGhpcyBzZWN0 aW9uIGhhcyBiZWVuIHNpbXBsaWZpZWQgZ3JlYXRseSBpbiB0aGUgLTA0IHZlcnNpb24gYWNjb3Jk aW5nIHRvIHlvdXIgYWJvdmUgY29tbWVudC4gUGxlYXNlIGNoZWNrIHdoZXRoZXIgaXQncyBPSyBu b3cuDQoNCj4gIzI6IHJmYzQwMjMgdG91Y2hlcyBvbiBhIG51bWJlciBvZiBJUCBlbmNhcHN1bGF0 aW9uIGRldGFpbHMgKFRUTCwgUW9TLCBNVFUsDQo+IGV0YykgdGhhdCB0aGlzIGRyYWZ0IGRvZXMg bm90LiAgSXMgdGhlIGludGVudCBmb3IgTVBMUy1pbi1VRFAgdG8gdXNlIHRoZSBzYW1lDQo+IGJl aGF2aW9yIGFzIE1QTFMtaW4tR1JFLCBidXQgd2l0aCBhIFVEUCBlbmNhcD8gIEl0IG1heSBiZSB3 b3J0aCBzcGVsbGluZyBvdXQNCj4gdGhhdCBpZiB0aGVyZSBpcyBhIHF1ZXN0aW9uIGFib3V0IGhv dyBjZXJ0YWluIElQIGZpZWxkcyBzaG91bGQgYmUgZmlsbGVkIGluIHRoYXQNCj4gcmZjNDAyMyBw cm9jZWR1cmVzIHNob3VsZCBiZSBmb2xsb3dlZC4gIEknZCBoYXRlIHRvIGVuZCB1cCB3aXRoIGFu DQo+IE1QTFMtaW4tVURQIGVuY2FwIHRoYXQgZGlkIGRpZmZlcmVudCBJUCBUVEwgdGhpbmdzIHRo YW4gYW4gTVBMUy1pbi1JUCBlbmNhcC4NCg0KRml4ZWQuDQoNCj4gIzM6IEkgc2hhcmUgU2hhaHJh bSdzIGNvbmNlcm4gdGhhdCB0aGlzIGlzIFlldCBBbm90aGVyIFdheSB0byBzb2x2ZSB0aGUgc2Ft ZQ0KPiBwcm9ibGVtLiAgSXQgaXMgdHJ1ZSB0aGF0IG5vdCBhbGwgbm9kZXMgbWF5IGJlIGFibGUg dG8gbG9hZC1iYWxhbmNlIG9uIHRoZSBHUkUNCj4ga2V5IGFzIHNwZWNpZmllZCBpbiByZmM0MDIz LCBidXQgdGhlIHByYWN0aWNlIG9mIGRlZmluaW5nIG5ldyBtZXRob2RzIHRvIHJlcGxhY2UNCj4g c2xpZ2h0bHkgb2xkZXIgbWV0aG9kcyBkdWUgdG8gY3VycmVudCBoYXJkd2FyZSBsaW1pdGF0aW9u cyBzZWVtcyBza2V0Y2h5Lg0KPiBNb3N0IG1vZGVybiBoYXJkd2FyZSBpcyBmaWVsZC1wcm9ncmFt bWFibGUsIGFuZCBhZGRpbmcgYSBwYWNrZXQgZmllbGQgdG8gYQ0KPiBmb3J3YXJkaW5nIGhhc2gg c2hvdWxkIG5vdCByZXF1aXJlIGFueXRoaW5nIG1vcmUgdGhhbiBhIHNvZnR3YXJlIHVwZGF0ZTsN Cj4gY29taW5nIHVwIHdpdGggbmV3IHN0YW5kYXJkcyB0byBhdm9pZCB1cGdyYWRpbmcgc29mdHdh cmUgaXMgYSBiYWQgaWRlYS4NCg0KPiBGb3IgaW1wbGVtZW50YXRpb25zIHdoaWNoIGFyZSBub3Qg c29mdHdhcmUtdXBncmFkYWJsZSwgZ29vZCBzdGFuZGFyZHMgbGFzdCBhDQo+IGxvdCBsb25nZXIg dGhhbiBhIGdpdmVuIGdlbmVyYXRpb24gb2YgaGFyZHdhcmUsIGFuZCB0aGVyZSBhcmUgYSBudW1i ZXIgb2YNCj4gYWR2YW5jZXMgaW4gdGhlIGluZHVzdHJ5IHdoaWNoIG5ldmVyIHdvdWxkIGhhdmUg bWFkZSBpdCBpZiB0aGV5IHdlcmUgaWdub3JlZA0KPiBiZWNhdXNlIGN1cnJlbnQgaGFyZHdhcmUg Y291bGRuJ3QgZG8gdGhlbS4gIEV4YW1wbGVzIGluY2x1ZGUgSVB2NiBhbmQgTVBMUy4NCj4gSG93 ZXZlciwgSSdtIG5vdCBzdXJlIGl0J3Mgd2l0aGluIG15IHB1cnZpZXcgYXMgYSBSVCByZXZpZXdl ciB0byBtYWtlIHRoaXMNCj4gYXJndW1lbnQsIHNvIEknbGwgbWFrZSBpdCBhZ2FpbiB3aGVuIHRo ZSBXRyBwb2xsIGNvbWVzIHVwLg0KDQpUaGUgZHJhZnQgaXMganVzdCBpbnRlbmRlZCB0byBhZGRy ZXNzIHRoZSBjdXJyZW50IHByb2JsZW1zLiBJZiBsb2FkIGJhbGFuY2luZyBiYXNlZCBvbiB0aGUg R1JFIGtleSBiZWNvbWVzIGEgZGVmYXVsdCBjYXBhYmlsaXR5IG9mIG1vc3QgY29yZSByb3V0ZXJz IGluIHRoZSBmdXR1cmUsIHRoaXMgZHJhZnQgY2FuIGJlIGRpc2NhcmRlZCBpZiBuZWNlc3Nhcnku IEFueXdheSwgdGhlIG1hcmtldCB3aWxsIG1ha2UgaXRzIHdpc2UgY2hvaWNlIGFjY29yZGluZyB0 byB0aGUgcHJhY3RpY2FsIGNvbmRpdGlvbnMuDQoNCj4gIzQ6IFRoZSBpbnRybyBzYXlzICJpbiBt b3N0IGNsb3VkIGRhdGENCj4gICAgY2VudGVyIG5ldHdvcmsgZW52aXJvbm1lbnRzLCBkYXRhIGNl bnRlciBvcGVyYXRvcnMgdGVuZCB0byBlbmFibGUgSVANCj4gICAgZm9yd2FyZGluZyBjYXBhYmls aXR5LCByYXRoZXIgdGhhbiBNUExTIGZvcndhcmRpbmcgY2FwYWJpbGl0eSBpbiB0aGUNCj4gICAg dW5kZXJseWluZyBkYXRhIGNlbnRlciBuZXR3b3JrcyBkdWUgdG8gY2VydGFpbiByZWFzb25zLiIN Cg0KPiBJbiBsaW5lIHdpdGggbXkgcG9pbnQgIzMsIHN0YW5kYXJkcyBsYXN0IGxvbmdlciB0aGFu IG1hbnkgY3VycmVudCBwcmFjdGljZXMuDQo+IFdpbGwgdGhpcyBiZSB0cnVlIGluIDIwMjU/ICBX aGF0IGFyZSAnY2VydGFpbiByZWFzb25zJz8gIEkgdGhpbmsgdGhpcyBzZW50ZW5jZQ0KPiB3b3Vs ZCBiZSBiZXR0ZXIgb2ZmIGFzOg0KPiANCj4gImluIGN1cnJlbnQgZGVwbG95bWVudHMsIGRhdGEg Y2VudGVyIG9wZXJhdG9ycyB0ZW5kIHRvIGVuYWJsZSBJUA0KPiAgICBmb3J3YXJkaW5nIGNhcGFi aWxpdHksIHJhdGhlciB0aGFuIE1QTFMgZm9yd2FyZGluZyBjYXBhYmlsaXR5Ig0KPiANCj4gb3Ig c29tZXRoaW5nIGxlc3MgbXVya3kgYW5kIHRpbWUtYm91bmQuDQoNClRvIGF2b2lkIGVuZGxlc3Mg YXJndW1lbnRzIG9uIHdoZXRoZXIgTVBMUy1iYXNlZCBWUE4gdGVjaG5vbG9naWVzIGFyZSBhcHBs aWNhYmxlIHdpdGhpbiBkYXRhIGNlbnRlcnMsIGFub3RoZXIgdXNlIGNhc2Ugb2YgdHJhbnNwb3J0 aW5nIE1QTFMgdHJhZmZpYyBhY3Jvc3MgSVAgbmV0d29ya3MgaXMgZGVzY3JpYmVkIGluIHRoZSBy ZXZpc2lvbi4gVGhhdCBpczogTVBMUy1iYXNlZCBMMlZQTiBvciBMM1ZQTiB0ZWNobm9sb2dpZXMg bWF5IGJlIHVzZWQgZm9yIGludGVyY29ubmVjdGluZyBnZW9ncmFwaGljYWxseSBkaXNwZXJzZWQg ZW50ZXJwcmlzZSBkYXRhIGNlbnRlcnMgb3IgYnJhbmNoIG9mZmljZXMgYWNyb3NzIElQIFdpZGUg QXJlYSBOZXR3b3JrcyAoV0FOKSB3aGVyZSBlbnRlcnByaXNlIG93biByb3V0ZXIgZGV2aWNlcyBh cmUgZGVwbG95ZWQgYXMgTDJWUE4gb3IgTDNWUE4gUEUgcm91dGVycy4gDQoNClBsZWFzZSBjaGVj ayB3aGV0aGVyIGFsbCBvZiB5b3VyIGFib3ZlIGNvbW1lbnRzIGhhdmUgYmVlbiB3ZWxsIGFkZHJl c3NlZCBpbiB0aGUgLTA0IHZlcnNpb24uIE1hbnkgdGhhbmtzLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0KPiANCj4gDQo+IGVyaWMNCg== From Rolf.Winter@neclab.eu Tue Dec 4 00:29:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A2121F8530 for ; Tue, 4 Dec 2012 00:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu3ujGIXn9BL for ; Tue, 4 Dec 2012 00:29:31 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3706021F851C for ; Tue, 4 Dec 2012 00:29:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 624F810282A; Tue, 4 Dec 2012 09:29:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJUTmCe7iZNW; Tue, 4 Dec 2012 09:29:30 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 3F1D4102828; Tue, 4 Dec 2012 09:29:15 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 09:28:54 +0100 From: Rolf Winter To: Shahram Davari Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNxlMXKWb9xeipk0ykh7jRLlQh+ZfxTQkAgAHCTQCAAOTmgIAAXp2AgABi/fCAAA0igIAHi3cAgAMdCoCAABe0gIAHqEqAgAAMUACAAF+SUIAAIN4AgACpYOA= Date: Tue, 4 Dec 2012 08:28:44 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55542A3B@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broadcom.com> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broadcom.com> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:29:33 -0000 Hi, please see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > Rolf, >=20 > For clarity it is better to use an example. Assume that an LSR has 4 > ports (A, B, C, D). Now assume that it receives packets on a unicast > LSP-X from port A and forwards them to port B. there can only be 3 > configurations: >=20 > 1) MIP on port A (In-MIP), or > 2) MIP on port B (out-MIP), or > 3) MEIP on Port A and B >=20 > A single OAM packet can be terminated and processed only by one of > these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport > B). In your example, you are saying send a copy of the P to the > CPU/Processor on Port A, and send a copy also to CPU/Processor on Port > B. Port A CPU will drop the packet since the MIP-ID is not A. The > issue is that each CPU/processor has limited resources. By sending all > OAM MIP packets to both processor you are losing 1/2 of the capacity of > each processor. The practical solution is to have a simple indicator > in the packet header that this OAM packet is meant for Out-MIP. Then > port A just switches the OAM packet to Port B, and Port B terminates > and sends it to its CPU/processor. >=20 > Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the > chip from Port A and is sent to ports B, C, D. Also assume that there > is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a > Multicast OAM packet is meant for out-MIPs (B, C). In such case the > OAM packet should not be sent to port A CPU/Processor. It is therefore > multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. > Port D drops the OAM packets and does not send it to its CPU, since > there is no MIP configured for that MPLS label. I don't think this is how it works. Quoting the OAM framework: "In order to send an OAM packet to M leaves (i.e., a subset of all the leaves), the source MEP sends M different OAM packets targeted to each individual leaf in the group of M leaves. Aggregating or subsetting mechanisms are outside the scope of this document." I read the above in a way that you'd need to send two OAM frames in the sce= nario above. In other words D needs to drop packets at the rate that the ot= hers process it. In this case, a single bit is simply not enough to reduce = the load all out-MIPs. I personally think the pseudo-code is only correct for your scenario 3 BTW.= But either way, my point was that the OAM CPUs - one way or the other - ha= ve to be able to process/drop OAM packets at the rate that they receive it = in either case. Look at the egress port case and given the description of t= he OAM framework above, port B has to drop packets at the rate that port C = receives them and vice versa. In your pseudo code at the egress the OAM fra= mes will always end up in the "send to local CPU" else clause.=20 I think what the WG needs to decide is: a) do we want to go back and change a few RFCs and do a standards action on= grabbing that reserved bit b) go with the document as is and live with a deficiency that will, I guess= , hit us in certain cases even with the bit >=20 > So the Pseudo-code is like this: >=20 > Ingress Port: >=20 > If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Send to local CPU > Else > Forward to egress port > End > Else > Forward normally > End > Else >=20 > Egress Port: >=20 > If packet is OAM and TTL=3D1 > If MIP is enabled > If packet indicates In-MIP > Drop packet > Else If packet indicates Out-MIP > Send to local CPU > End > Else > Drop packet > End > End >=20 >=20 > Using this example could you please describe your reasoning for not > requiring HW to identify In-MEP vs out-MIPs? >=20 > Thanks > Shahram >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > Sent: Monday, December 03, 2012 12:10 PM > To: Shahram Davari > Cc: Pablo Frank; mpls@ietf.org > Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > But the MIP that is addressed needs to be able to handle this _plus_ > take an appropriate action and in the P2MP case this will always be the > case since there are 2 or more out MIPs. >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Shahram Davari [mailto:davari@broadcom.com] > > Sent: Montag, 3. Dezember 2012 16:27 > > To: Rolf Winter > > Cc: Pablo Frank; mpls@ietf.org > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp- > mip- > > mep-map > > > > Hi Rolf, > > > > Your HW guys are correct as long as the amount of data sent to the > in- > > MIP processor is not much. But from your previous email to Loa I see > > that you want to also terminate CV at MIPs. CVs are fast and high > > bandwidth and blindly dumping them on a CPU or OAM processor that > may > > not be expecting them is like DoS attack. > > > > > > > > Regards, > > Shahram > > > > > > On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > > wrote: > > > > > Hi, > > > > > > sorry for the belated response. I checked with some of our HW > people. > > Here's the gist of their response: > > > > > > Of course they wouldn't like parsing TLVs but we established that > > fact already. Their answer to the problem is slightly different > though. > > A TTL-expired OAM frame can simply be copied and forwarded to the > out- > > MIPs where, if the frame is not intended for them, it can safely be > > dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the > > implementation must behave in this exact way in either case. So there > > is at least one way to implement this at line rate without going back > > and changing a bunch of RFCs. > > > > > > Best, > > > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf Of Shahram Davari > > >> Sent: Mittwoch, 28. November 2012 18:46 > > >> To: Pablo Frank > > >> Cc: mpls@ietf.org > > >> Subject: Re: [mpls] working group last call on > > >> draft-ietf-mpls-tp-mip- mep-map > > >> > > >> Pablo, > > >> > > >> > > >> > > >> That was exactly my point. Let's use a flag to indicate in-MIP or > > >> out- MIP and then the offline processor can do MEPID lookup to > > >> determine whether this is a legitimate OAM packet or not. > > >> > > >> > > >> > > >> Thx > > >> Shahram > > >> > > >> > > >> > > >> From: Pablo Frank [mailto:pabloisnot@gmail.com] > > >> Sent: Wednesday, November 28, 2012 8:22 AM > > >> To: Shahram Davari > > >> Cc: mpls@ietf.org > > >> Subject: Re: [mpls] working group last call on > > >> draft-ietf-mpls-tp-mip- mep-map > > >> > > >> > > >> > > >> I think Shahram raises a very legitimate concern about how > > >> expensive this could be to implement in hardware. > > >> > > >> > > >> > > >> As I understand it, the logic proposed by this draft is as > follows: > > >> > > >> > > >> > > >> At the ingress blade: > > >> > > >> > > >> > > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > > >> > > >> Parse MIP-ID TLV > > >> > > >> Lookup MIP-ID > > >> > > >> IF MIP-is-egress, THEN > > >> > > >> forward normally (but note we must intercept it again on > > egress) > > >> > > >> ELSE > > >> > > >> punt to OAM processor > > >> > > >> > > >> > > >> At the egress blade: > > >> > > >> > > >> > > >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > > >> > > >> Parse MIP-ID TLV > > >> > > >> Lookup MIP-ID > > >> > > >> IF MIP-is-egress, THEN > > >> > > >> punt to OAM processor > > >> > > >> ELSE > > >> > > >> drop > > >> > > >> > > >> > > >> Note all this has to be done in the fast-path now at full line > rate > > >> (and hardware guys hate TLVs). Before, the only thing the > > >> fast-path had to do was look for TTL-expiry. > > >> > > >> > > >> > > >> The only reason that ACH reserved bit was rejected (in Appendix > A.4 > > >> of > > >> -03 version of doc) was because it also required a MIP-ID lookup. > > >> But I don't see anything wrong with combining both mechanisms. > > >> Ideally, hardware could rely on the reserved bit to do the initial > > >> filtering at full line-rate and then a presumably much more > > >> cost-efficient OAM hardware block could perform the MIP-ID lookup. > > >> Instead of the complex logic above, the fast path gets a simple > > >> modification to TTL handling and the OAM block does the heavy > > lifting of dealing with ACH TLVs, etc. > > >> > > >> > > >> > > >> This seems like a case where practicality should trump elegance. > > >> > > >> > > >> > > >> regards, > > >> > > >> Pablo > > >> > > >> > > >> > > >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > > >> > > >> wrote: > > >> > > >> > > >> > > >> > Rolf, > > >> > > > >> > I am sure you know that TLVs are not Hardware friendly. And I > > >> think you agree with me that this draft requires deep parsing of > > >> all packets at line rate to get to the MIPID TLV. > > >> > > > >> > I still think the MIPID TLV is required to decide whether an > > OAM > > >> packet ended up at the right MIP. But may be a simpler solution > > >> could be augmented to decide between In-MIP and Out-MIP. For > > >> example how about using one of the reserved bits in the ACH header. > > >> This > > can > > >> easily be done in hardware with minimum complexity. > > >> > > > >> > Regards, > > >> > Shahram > > >> > > > >> > > > >> > > > >> > -----Original Message----- > > >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > > >> Behalf Of Rolf Winter > > >> > Sent: Wednesday, November 21, 2012 12:13 PM > > >> > To: S. Davari; adrian@olddog.co.uk > > >> > Cc: mpls@ietf.org > > >> > Subject: Re: [mpls] working group last call on > > >> draft-ietf-mpls- tp-mip-mep-map > > >> > > > >> > Hi, > > >> > > > >> >> Hi Adrian, > > >> >> > > >> >> You are right and I should have sent these types of comments > > >> before > > >> >> last call. I completely understand the procedure. > > >> >> > > >> >> One thing I didn't understand in your response is that you > > said > > >> in-MIP > > >> >> requires to do the MEPID lookup at line rate anyway. Why is > > >> that? > > >> >> > > >> >> My understanding is that before this draft, the process > > >> would have > > >> >> been for the ingress to look at TTL and if it is expired > then > > >> send the > > >> >> packet to OAM processor. > > >> > > > >> > Yes (and no). While I assume likely MIP functionality will be > > >> implemented on the ingress, the related RFCs are vague about the > > >> actual placement of the MIP function. See e.g. the OAM Framework > > (RFC > > >> 6371) "per-node MIPs (i.e., a single MIP per node in an > unspecified > > >> location within the node)". > > >> > > > >> > Also, I think "before this draft" is not quite accurate in > > >> that is suggests there is no per-interface MIP addressing possible > > >> as of > > now. > > >> Take RFC 6426. In practice this is where part of the problem lies. > > We > > >> cannot really go back and change all this. There are other > > constraints. > > >> E.g. we have a requirement to address a single out-MIP out of a > set > > >> of out-MIPs on a P2MP branch point. So this was part of the > > >> constraints we worked with. > > >> > > > >> >> > > >> >> The MEPID that you suggest in this draft is very useful for > > >> filtering > > >> >> out leaked OAM frames from upstream. But lets leave lookup > of > > >> the MEPID > > >> >> to the OAM processing module (at slower rate) and add an > > >> indicator to > > >> >> the OAM packet to indicate whether it should be taken out of > > >> the data > > >> >> path in the Ingress or egress. > > >> >> > > >> >> So can I suggest adding the following text to the draft: > > >> >> > > >> >> " In addition to the MEPID, which is used to ultimately > > >> accept or > > >> >> filter out received OAM packets, OAM packets should have a > > >> simple > > >> >> indicator that identifies whether the OAM packet belongs to > > >> in-MIP or > > >> >> Out-MIP". > > >> > > > >> > We also have the question on where to retrofit those bits. I > > >> assume a TLV wouldn't work for the exact reasons you do not like > to > > >> have to do a second lookup, since it would require some parsing. > > >> All these constraints and the ones outlined in the document led to > > >> where we are. In a sense this is a non-spec since it rather rules > > >> out a number of things that seem like a good idea at first but > then > > >> have a catch of some sort. > > >> > > > >> > Best, > > >> > > > >> > Rolf > > >> > > > >> >> > > >> >> > > >> >> > > >> >> Regards, > > >> >> Shahram > > >> >> > > >> >> > > >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > > >> > > >> >> wrote: > > >> >> > > >> >>> > > >> >>> > > >> >>> Hi Shahram, > > >> >>> > > >> >>> I am worried about the precedent of a comment like this > > during > > >> WG > > >> >> last call. > > >> >>> While comments that improve the document or point out > > >> fundamental > > >> >>> flaws are welcome whenever they arrive, points with the > > >> flavour "I > > >> >>> wouldn't have done it like this" that arrive this late in > > >> the process > > >> >> don't feel very constructive. > > >> >>> But I will leave the chair to worry about process and try > to > > >> address > > >> >>> the technical points... > > >> >>> > > >> >>>> Identifying whether to terminate an OAM packet and process > > it > > >> in In- > > >> >> MIP vs. > > >> >>> Out- > > >> >>>> MIP requires line rate lookup, otherwise the OAM packet > > >> will not > > >> >> take > > >> >>>> the same path as data packets. Therefore any MIP > > >> identifier that is > > >> >>>> proposed in this > > >> >>> draft > > >> >>>> requires one extra lookup and therefore adds significantly > > to > > >> cost. > > >> >>> > > >> >>> If I am not wrong, this is a feature of an out-MIP. If you > > >> decide to > > >> >>> implement out-MIPs, and if you want the OAM to follow > > >> exactly the > > >> >> same > > >> >>> path as the data, then it is a requirement that the out > > >> interface > > >> >>> inspects the packets (at line > > >> >>> rate) to determine whether they are OAM and targeted at the > > >> interface. > > >> >>> > > >> >>> We cannot change that aspect. All we can do is aim to make > > the > > >> lookup > > >> >>> as easy as possible. > > >> >>> > > >> >>>> Perhaps a > > >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain > > >> Level) may be > > >> >>>> used that requires only 3 bits and achieves the same > result. > > >> >>> > > >> >>> Perhaps it could. > > >> >>> But before going there, why is the lookup in the current > > >> version of > > >> >>> the I-D arduous? > > >> >>> > > >> >>> Presumably you do not propose making any change to the way > > >> In-MIPs > > >> >> are > > >> >>> currently identified, so the lookups being done at line > rate > > >> today on > > >> >>> the incoming interfaces will not be changed. If you are > > >> proposing > > >> >> such > > >> >>> a change, then the discussion is outside the scope of this > > >> I- D and > > >> >>> becomes a much wider question for the working group. > > >> >>> > > >> >>> This leaves me with the trade-off of enabling a *simpler* > > >> lookup on > > >> >>> the outgoing interfaces versus doing identical lookups on > > both > > >> >>> interfaces. My assumption was that if the incoming > interface > > >> can do > > >> >>> the lookup at line rate, it is not hard to perform the same > > >> lookup on > > >> >>> the outgoing interface. Furthermore, there is a reduction > in > > >> >> complexity by having fewer things to look up. > > >> >>> > > >> >>> Another possibility is that the full lookup could be done > on > > >> the > > >> >>> incoming interface and the packet marked for easy > > interception > > >> on the > > >> >> outgoing interface. > > >> >>> The concern with this approach is that the packet would no > > >> longer be > > >> >>> being forwarded exactly as data because it would be being > > >> modified in > > >> >> flight. > > >> >>> Furthermore, in the case of P2MP, it is not enough to flag > > the > > >> packet > > >> >>> as a local Out-MIP and further identifier-based lookup is > > >> needed. > > >> >>> > > >> >>> Some of these issues were raised and discussed as the I-D > > >> progressed, > > >> >>> and some of the alternative solutions were tracked with > > >> their pros > > >> >> and > > >> >>> cons in Appendix A of the I-D (look at revision -03). > > >> >>> > > >> >>> Thanks, > > >> >>> Adrian > > >> >>>> -----Original Message----- > > >> >>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > > On > > >> Behalf > > >> >>>> Of Adrian Farrel > > >> >>>> Sent: Monday, November 19, 2012 8:45 AM > > >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > > >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > > >> ; > > >> >>> draft-ietf-mpls-tp-mip- > > >> >>>> mep-map@tools.ietf.org > > >> >>>> Subject: Re: [mpls] working group last call on > > >> >>>> draft-ietf-mpls-tp-mip-mep-map > > >> >>>> > > >> >>>> Yeah, it's a boring draft. Did you expect me to co-author > > >> anything > > >> >> else? > > >> >>>> > > >> >>>> The point was that when I started the I-D lots of people > > were > > >> saying > > >> >>>> "it's complex" and "it can't be done" and "it won't be > > >> backward > > >> >> compatible". > > >> >>>> > > >> >>>> So the I-D says "here it is" > > >> >>>> > > >> >>>> A (sorry not to offer you excitement) > > >> >>>> > > >> >>>>> -----Original Message----- > > >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] > > >> >>>>> Sent: 19 November 2012 12:38 > > >> >>>>> To: Loa Andersson; mpls@ietf.org > > >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > > >> ; MPLS-TP ad > > >> >>>>> hoc > > >> >>> team; > > >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > > >> >>>>> Subject: Re: [mpls] working group last call on > > >> >>> draft-ietf-mpls-tp-mip-mep-map > > >> >>>>> > > >> >>>>> After getting to section 6 and its features > > >> (requirements!), I find > > >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it > is > > >> >>>>> Informational and not Standards Track. > > >> >>>>> > > >> >>>>> Meanwhile, I suggest some editorial issues. > > >> >>>>> > > >> >>>>> Title > > >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > > >> [Handling > > >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a > more > > >> >>>>> informative statement unless and until you get to the > > >> definition of > > >> >>>>> Internal in s3; and s6, which is the crux of the document > > >> says The > > >> >>>>> preferred solution to per-interface MIP message handling > is > > >> >>>>> presented in this section] > > >> >>>>> > > >> >>>>> s1 > > >> >>>>> two (or more) MIPs per node on both sides of the > > >> forwarding engine. > > >> >>>>> [two on both sides sounds like four in total to me; > > >> suggest 'one on > > >> >>>>> each side of the forwarding engine'] > > >> >>>>> > > >> >>>>> s4 > > >> >>>>> o CV between a MEP and a MIP > > >> >>>>> [expand CV on first use] > > >> >>>>> > > >> >>>>> s5 > > >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] > > >> for MPLS-TP > > >> >>>>> LSPs and MPLS-TP PWs, respectively. > > >> >>>>> ['respectively' suggests to me that there should be two > > >> precedents, > > >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 > > for > > >> LSPs, > > >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this > > sentence > > >> as > > >> >>>>> redundant] > > >> >>>>> > > >> >>>>> s6 > > >> >>>>> The appendix of this document contains a > > >> >>>>> few solutions that the authors have discarded which have > > >> been > > >> >> left in > > >> >>>>> the document for informational purposes. > > >> >>>>> [not any more they haven't!] > > >> >>>>> > > >> >>>>> The node itself is addresses > > >> >>>>> [The node itself is addressed] > > >> >>>>> > > >> >>>>> The identification information indside [The > identification > > >> >>>>> information inside ] > > >> >>>>> > > >> >>>>> MIP identifiers are not know > > >> >>>>> [MIP identifiers are not known] > > >> >>>>> > > >> >>>>> reserved MIP address > > >> >>>>> [reserved MIP addressses or a reserved MIP address] > > >> >>>>> > > >> >>>>> Tom Petch > > >> >>>>> > > >> >>>>> > > >> >>>>> ----- Original Message ----- > > >> >>>>> From: "Loa Andersson" > > >> >>>>> To: > > >> >>>>> Cc: ; > >> chairs@tools.ietf.org>; > > >> >>>>> "MPLS-TP ad hoc team" ; > > >> >>>>> > > >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM > > >> >>>>> > > >> >>>>>> Working Group, > > >> >>>>>> > > >> >>>>>> This is to start a 2 week working group last call on > > >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. > > >> >>>>>> > > >> >>>>>> Please send your comments to the mpls working group > > mailing > > >> list > > >> >>>>>> (mpls@ietf.org). > > >> >>>>>> > > >> >>>>>> Please send both technical comments, and if you are > happy > > >> with the > > >> >>>>>> document as is also indications of support. > > >> >>>>>> > > >> >>>>>> This working group last call will end on November 28. > > >> >>>>>> > > >> >>>>>> /Loa > > >> >>>>>> for the wg co-chairs > > >> >>>> > > >> >>>> > > >> >>>> _______________________________________________ > > >> >>>> mpls mailing list > > >> >>>> mpls@ietf.org > > >> >>>> https://www.ietf.org/mailman/listinfo/mpls > > >> >>> > > >> >>> > > >> >>> _______________________________________________ > > >> >>> mpls mailing list > > >> >>> mpls@ietf.org > > >> >>> https://www.ietf.org/mailman/listinfo/mpls > > >> >> _______________________________________________ > > >> >> mpls mailing list > > >> >> mpls@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/mpls > > >> > > > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > >> Road, London W3 6BL | Registered in England 2832014 > > >> > _______________________________________________ > > >> > mpls mailing list > > >> > mpls@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/mpls > > >> > > > >> > > > >> > > >> _______________________________________________ > > >> mpls mailing list > > >> mpls@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mpls > > > > > > >=20 >=20 From Rolf.Winter@neclab.eu Tue Dec 4 00:34:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950121F854E for ; Tue, 4 Dec 2012 00:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6N1-qEKF6kF for ; Tue, 4 Dec 2012 00:34:08 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7121F85B2 for ; Tue, 4 Dec 2012 00:34:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 44FA210282A; Tue, 4 Dec 2012 09:34:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81L+-x8wuVzU; Tue, 4 Dec 2012 09:34:07 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2002E102828; Tue, 4 Dec 2012 09:33:52 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 09:33:52 +0100 From: Rolf Winter To: Shahram Davari , "hideki.endo.es@hitachi.com" Thread-Topic: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNxlMXKWb9xeipk0ykh7jRLlQh+ZfxTQkAgAHCTQCAAOTmgIAAXp2AgABi/fCAAA0igIAHi3cAgAMdCoCAABe0gIAHqEqAgAAMUACAAF+SUIAAToJZ///wNICAAJC4IA== Date: Tue, 4 Dec 2012 08:33:41 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:34:10 -0000 Shahram, what if it is configured and you only want to talk to one out of all the ou= t-MIPs. I guess we can all craft examples where we can make our point. A si= ngle bit simply does not guarantee you that the local CPU does not have to = look at the OAM frame to finally discard it. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Shahram Davari [mailto:davari@broadcom.com] > Sent: Dienstag, 4. Dezember 2012 01:53 > To: hideki.endo.es@hitachi.com > Cc: Rolf Winter; mpls@ietf.org > Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls- > tp-mip-mep-map >=20 > Hi Hideki, >=20 > I think you need to look at my p-code. F a MIP is not configured in the > Egress port, then that egress port won't sent the OAM packet to its > processor and drops it. So there is no issue with my proposed method. >=20 > Thx > Shahram >=20 > -----Original Message----- > From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > Sent: Monday, December 03, 2012 4:48 PM > To: Shahram Davari > Cc: Rolf.Winter@neclab.eu; mpls@ietf.org > Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp- > mip-mep-map >=20 > Hi Shahram, >=20 > First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a > MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests > Here, CV means On-demand CV. You may misunderstand as Proactive CV. >=20 > Second, you wrote; > "The issue is that each CPU/processor has limited resources. > By sending all OAM MIP packets to both processor you are losing 1/2 > of the capacity of each processor. " > It depends on implementations, > and this issue could NOT be resolved by even your solution that uses > ACH header to indicate in/out-MIP. > Let's consider P2MP case as you pointed out. > All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. > This means that the OAM processor at port D loses its capacity. > If we consider the larger number of ports in the LSR which has 100 > ports, for example, All OAM MIP packets for out-MIPs port(B, C) are > sent to all out-MIPs. > This means that the OAM processors at the other 98 ports lose those > capacities. > Even if your solution using ACH header is applied, it can reduce OAM > packets only for in-MIP, which means only 1/101 effectiveness in the > case of P2MP for 100 ports. >=20 > Thanks, > Hideki Endo >=20 >=20 > >Rolf, > > > >For clarity it is better to use an example. Assume that an LSR has 4 > ports (A, B, C, D). Now assume that it receives packets on a unicast > LSP-X from port A and forwards them to port B. there can only be 3 > configurations: > > > >1) MIP on port A (In-MIP), or > >2) MIP on port B (out-MIP), or > >3) MEIP on Port A and B > > > >A single OAM packet can be terminated and processed only by one of > these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport > B). In your example, you are saying send a copy of the P to the > CPU/Processor on Port A, and send a copy also to CPU/Processor on Port > B. Port A CPU will drop the packet since the MIP-ID is not A. The > issue is that each CPU/processor has limited resources. By sending all > OAM MIP packets to both processor you are losing 1/2 of the capacity of > each processor. The practical solution is to have a simple indicator > in the packet header that this OAM packet is meant for Out-MIP. Then > port A just switches the OAM packet to Port B, and Port B terminates > and sends it to its CPU/processor. > > > >Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the > chip from Port A and is sent to ports B, C, D. Also assume that there > is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a > Multicast OAM packet is meant for out-MIPs (B, C). In such case the > OAM packet should not be sent to port A CPU/Processor. It is therefore > multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. > Port D drops the OAM packets and does not send it to its CPU, since > there is no MIP configured for that MPLS label. > > > >So the Pseudo-code is like this: > > > >Ingress Port: > > > >If packet is OAM and TTL=3D1 > > If MIP is enabled > > If packet indicates In-MIP > > Send to local CPU > > Else > > Forward to egress port > > End > > Else > > Forward normally > > End > >Else > > > >Egress Port: > > > >If packet is OAM and TTL=3D1 > > If MIP is enabled > > If packet indicates In-MIP > > Drop packet > > Else If packet indicates Out-MIP > > Send to local CPU > > End > > Else > > Drop packet > > End > >End > > > > > >Using this example could you please describe your reasoning for not > requiring HW to identify In-MEP vs out-MIPs? > > > >Thanks > >Shahram > > > >-----Original Message----- > >From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >Sent: Monday, December 03, 2012 12:10 PM > >To: Shahram Davari > >Cc: Pablo Frank; mpls@ietf.org > >Subject: RE: [mpls] working group last call on > >draft-ietf-mpls-tp-mip-mep-map > > > >But the MIP that is addressed needs to be able to handle this _plus_ > take an appropriate action and in the P2MP case this will always be the > case since there are 2 or more out MIPs. > > > >NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:davari@broadcom.com] > >> Sent: Montag, 3. Dezember 2012 16:27 > >> To: Rolf Winter > >> Cc: Pablo Frank; mpls@ietf.org > >> Subject: Re: [mpls] working group last call on > >> draft-ietf-mpls-tp-mip- mep-map > >> > >> Hi Rolf, > >> > >> Your HW guys are correct as long as the amount of data sent to the > >> in- MIP processor is not much. But from your previous email to Loa I > >> see that you want to also terminate CV at MIPs. CVs are fast and > high > >> bandwidth and blindly dumping them on a CPU or OAM processor that > >> may not be expecting them is like DoS attack. > >> > >> > >> > >> Regards, > >> Shahram > >> > >> > >> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > >> wrote: > >> > >> > Hi, > >> > > >> > sorry for the belated response. I checked with some of our HW > people. > >> Here's the gist of their response: > >> > > >> > Of course they wouldn't like parsing TLVs but we established that > >> fact already. Their answer to the problem is slightly different > though. > >> A TTL-expired OAM frame can simply be copied and forwarded to the > >> out- MIPs where, if the frame is not intended for them, it can > safely > >> be dropped. In the P2MP case e.g. this needs to be done anyway, i.e. > >> the implementation must behave in this exact way in either case. So > >> there is at least one way to implement this at line rate without > >> going back and changing a bunch of RFCs. > >> > > >> > Best, > >> > > >> > Rolf > >> > > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> > London W3 6BL | Registered in England 2832014 > >> > > >> > > >> >> -----Original Message----- > >> >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >> >> Behalf Of Shahram Davari > >> >> Sent: Mittwoch, 28. November 2012 18:46 > >> >> To: Pablo Frank > >> >> Cc: mpls@ietf.org > >> >> Subject: Re: [mpls] working group last call on > >> >> draft-ietf-mpls-tp-mip- mep-map > >> >> > >> >> Pablo, > >> >> > >> >> > >> >> > >> >> That was exactly my point. Let's use a flag to indicate in-MIP or > >> >> out- MIP and then the offline processor can do MEPID lookup to > >> >> determine whether this is a legitimate OAM packet or not. > >> >> > >> >> > >> >> > >> >> Thx > >> >> Shahram > >> >> > >> >> > >> >> > >> >> From: Pablo Frank [mailto:pabloisnot@gmail.com] > >> >> Sent: Wednesday, November 28, 2012 8:22 AM > >> >> To: Shahram Davari > >> >> Cc: mpls@ietf.org > >> >> Subject: Re: [mpls] working group last call on > >> >> draft-ietf-mpls-tp-mip- mep-map > >> >> > >> >> > >> >> > >> >> I think Shahram raises a very legitimate concern about how > >> >> expensive this could be to implement in hardware. > >> >> > >> >> > >> >> > >> >> As I understand it, the logic proposed by this draft is as > follows: > >> >> > >> >> > >> >> > >> >> At the ingress blade: > >> >> > >> >> > >> >> > >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> >> > >> >> Parse MIP-ID TLV > >> >> > >> >> Lookup MIP-ID > >> >> > >> >> IF MIP-is-egress, THEN > >> >> > >> >> forward normally (but note we must intercept it again on > >> egress) > >> >> > >> >> ELSE > >> >> > >> >> punt to OAM processor > >> >> > >> >> > >> >> > >> >> At the egress blade: > >> >> > >> >> > >> >> > >> >> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >> >> > >> >> Parse MIP-ID TLV > >> >> > >> >> Lookup MIP-ID > >> >> > >> >> IF MIP-is-egress, THEN > >> >> > >> >> punt to OAM processor > >> >> > >> >> ELSE > >> >> > >> >> drop > >> >> > >> >> > >> >> > >> >> Note all this has to be done in the fast-path now at full line > >> >> rate (and hardware guys hate TLVs). Before, the only thing the > >> >> fast-path had to do was look for TTL-expiry. > >> >> > >> >> > >> >> > >> >> The only reason that ACH reserved bit was rejected (in Appendix > >> >> A.4 of > >> >> -03 version of doc) was because it also required a MIP-ID lookup. > >> >> But I don't see anything wrong with combining both mechanisms. > >> >> Ideally, hardware could rely on the reserved bit to do the > initial > >> >> filtering at full line-rate and then a presumably much more > >> >> cost-efficient OAM hardware block could perform the MIP-ID lookup. > >> >> Instead of the complex logic above, the fast path gets a simple > >> >> modification to TTL handling and the OAM block does the heavy > >> lifting of dealing with ACH TLVs, etc. > >> >> > >> >> > >> >> > >> >> This seems like a case where practicality should trump elegance. > >> >> > >> >> > >> >> > >> >> regards, > >> >> > >> >> Pablo > >> >> > >> >> > >> >> > >> >> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > >> >> > >> >> wrote: > >> >> > >> >> > >> >> > >> >> > Rolf, > >> >> > > >> >> > I am sure you know that TLVs are not Hardware friendly. And > I > >> >> think you agree with me that this draft requires deep parsing of > >> >> all packets at line rate to get to the MIPID TLV. > >> >> > > >> >> > I still think the MIPID TLV is required to decide whether an > >> OAM > >> >> packet ended up at the right MIP. But may be a simpler solution > >> >> could be augmented to decide between In-MIP and Out-MIP. For > >> >> example how about using one of the reserved bits in the ACH > >> >> header. This > >> can > >> >> easily be done in hardware with minimum complexity. > >> >> > > >> >> > Regards, > >> >> > Shahram > >> >> > > >> >> > > >> >> > > >> >> > -----Original Message----- > >> >> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > On > >> >> Behalf Of Rolf Winter > >> >> > Sent: Wednesday, November 21, 2012 12:13 PM > >> >> > To: S. Davari; adrian@olddog.co.uk > >> >> > Cc: mpls@ietf.org > >> >> > Subject: Re: [mpls] working group last call on > >> >> draft-ietf-mpls- tp-mip-mep-map > >> >> > > >> >> > Hi, > >> >> > > >> >> >> Hi Adrian, > >> >> >> > >> >> >> You are right and I should have sent these types of > comments > >> >> before > >> >> >> last call. I completely understand the procedure. > >> >> >> > >> >> >> One thing I didn't understand in your response is that you > >> said > >> >> in-MIP > >> >> >> requires to do the MEPID lookup at line rate anyway. Why is > >> >> that? > >> >> >> > >> >> >> My understanding is that before this draft, the process > >> >> would have > >> >> >> been for the ingress to look at TTL and if it is expired > >> >> then send the > >> >> >> packet to OAM processor. > >> >> > > >> >> > Yes (and no). While I assume likely MIP functionality will > be > >> >> implemented on the ingress, the related RFCs are vague about the > >> >> actual placement of the MIP function. See e.g. the OAM Framework > >> (RFC > >> >> 6371) "per-node MIPs (i.e., a single MIP per node in an > >> >> unspecified location within the node)". > >> >> > > >> >> > Also, I think "before this draft" is not quite accurate in > >> >> that is suggests there is no per-interface MIP addressing > possible > >> >> as of > >> now. > >> >> Take RFC 6426. In practice this is where part of the problem lies. > >> We > >> >> cannot really go back and change all this. There are other > >> constraints. > >> >> E.g. we have a requirement to address a single out-MIP out of a > >> >> set of out-MIPs on a P2MP branch point. So this was part of the > >> >> constraints we worked with. > >> >> > > >> >> >> > >> >> >> The MEPID that you suggest in this draft is very useful for > >> >> filtering > >> >> >> out leaked OAM frames from upstream. But lets leave lookup > >> >> of the MEPID > >> >> >> to the OAM processing module (at slower rate) and add an > >> >> indicator to > >> >> >> the OAM packet to indicate whether it should be taken out > of > >> >> the data > >> >> >> path in the Ingress or egress. > >> >> >> > >> >> >> So can I suggest adding the following text to the draft: > >> >> >> > >> >> >> " In addition to the MEPID, which is used to ultimately > >> >> accept or > >> >> >> filter out received OAM packets, OAM packets should have a > >> >> simple > >> >> >> indicator that identifies whether the OAM packet belongs to > >> >> in-MIP or > >> >> >> Out-MIP". > >> >> > > >> >> > We also have the question on where to retrofit those bits. I > >> >> assume a TLV wouldn't work for the exact reasons you do not like > >> >> to have to do a second lookup, since it would require some > >> >> parsing. All these constraints and the ones outlined in the > >> >> document led to where we are. In a sense this is a non-spec since > >> >> it rather rules out a number of things that seem like a good idea > >> >> at first but then have a catch of some sort. > >> >> > > >> >> > Best, > >> >> > > >> >> > Rolf > >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> Regards, > >> >> >> Shahram > >> >> >> > >> >> >> > >> >> >> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > >> >> > >> >> >> wrote: > >> >> >> > >> >> >>> > >> >> >>> > >> >> >>> Hi Shahram, > >> >> >>> > >> >> >>> I am worried about the precedent of a comment like this > >> during > >> >> WG > >> >> >> last call. > >> >> >>> While comments that improve the document or point out > >> >> fundamental > >> >> >>> flaws are welcome whenever they arrive, points with the > >> >> flavour "I > >> >> >>> wouldn't have done it like this" that arrive this late in > >> >> the process > >> >> >> don't feel very constructive. > >> >> >>> But I will leave the chair to worry about process and try > >> >> to address > >> >> >>> the technical points... > >> >> >>> > >> >> >>>> Identifying whether to terminate an OAM packet and > process > >> it > >> >> in In- > >> >> >> MIP vs. > >> >> >>> Out- > >> >> >>>> MIP requires line rate lookup, otherwise the OAM packet > >> >> will not > >> >> >> take > >> >> >>>> the same path as data packets. Therefore any MIP > >> >> identifier that is > >> >> >>>> proposed in this > >> >> >>> draft > >> >> >>>> requires one extra lookup and therefore adds > significantly > >> to > >> >> cost. > >> >> >>> > >> >> >>> If I am not wrong, this is a feature of an out-MIP. If you > >> >> decide to > >> >> >>> implement out-MIPs, and if you want the OAM to follow > >> >> exactly the > >> >> >> same > >> >> >>> path as the data, then it is a requirement that the out > >> >> interface > >> >> >>> inspects the packets (at line > >> >> >>> rate) to determine whether they are OAM and targeted at > the > >> >> interface. > >> >> >>> > >> >> >>> We cannot change that aspect. All we can do is aim to make > >> the > >> >> lookup > >> >> >>> as easy as possible. > >> >> >>> > >> >> >>>> Perhaps a > >> >> >>>> similar method to Ethernet MDL/MEL (Maintenance Domain > >> >> Level) may be > >> >> >>>> used that requires only 3 bits and achieves the same > result. > >> >> >>> > >> >> >>> Perhaps it could. > >> >> >>> But before going there, why is the lookup in the current > >> >> version of > >> >> >>> the I-D arduous? > >> >> >>> > >> >> >>> Presumably you do not propose making any change to the way > >> >> In-MIPs > >> >> >> are > >> >> >>> currently identified, so the lookups being done at line > >> >> rate today on > >> >> >>> the incoming interfaces will not be changed. If you are > >> >> proposing > >> >> >> such > >> >> >>> a change, then the discussion is outside the scope of this > >> >> I- D and > >> >> >>> becomes a much wider question for the working group. > >> >> >>> > >> >> >>> This leaves me with the trade-off of enabling a *simpler* > >> >> lookup on > >> >> >>> the outgoing interfaces versus doing identical lookups on > >> both > >> >> >>> interfaces. My assumption was that if the incoming > >> >> interface can do > >> >> >>> the lookup at line rate, it is not hard to perform the > same > >> >> lookup on > >> >> >>> the outgoing interface. Furthermore, there is a reduction > in > >> >> >> complexity by having fewer things to look up. > >> >> >>> > >> >> >>> Another possibility is that the full lookup could be done > >> >> on the > >> >> >>> incoming interface and the packet marked for easy > >> interception > >> >> on the > >> >> >> outgoing interface. > >> >> >>> The concern with this approach is that the packet would no > >> >> longer be > >> >> >>> being forwarded exactly as data because it would be being > >> >> modified in > >> >> >> flight. > >> >> >>> Furthermore, in the case of P2MP, it is not enough to flag > >> the > >> >> packet > >> >> >>> as a local Out-MIP and further identifier-based lookup is > >> >> needed. > >> >> >>> > >> >> >>> Some of these issues were raised and discussed as the I-D > >> >> progressed, > >> >> >>> and some of the alternative solutions were tracked with > >> >> their pros > >> >> >> and > >> >> >>> cons in Appendix A of the I-D (look at revision -03). > >> >> >>> > >> >> >>> Thanks, > >> >> >>> Adrian > >> >> >>>> -----Original Message----- > >> >> >>>> From: mpls-bounces@ietf.org [mailto:mpls- > bounces@ietf.org] > >> On > >> >> Behalf > >> >> >>>> Of Adrian Farrel > >> >> >>>> Sent: Monday, November 19, 2012 8:45 AM > >> >> >>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > >> >> >>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> >> ; > >> >> >>> draft-ietf-mpls-tp-mip- > >> >> >>>> mep-map@tools.ietf.org > >> >> >>>> Subject: Re: [mpls] working group last call on > >> >> >>>> draft-ietf-mpls-tp-mip-mep-map > >> >> >>>> > >> >> >>>> Yeah, it's a boring draft. Did you expect me to co-author > >> >> anything > >> >> >> else? > >> >> >>>> > >> >> >>>> The point was that when I started the I-D lots of people > >> were > >> >> saying > >> >> >>>> "it's complex" and "it can't be done" and "it won't be > >> >> backward > >> >> >> compatible". > >> >> >>>> > >> >> >>>> So the I-D says "here it is" > >> >> >>>> > >> >> >>>> A (sorry not to offer you excitement) > >> >> >>>> > >> >> >>>>> -----Original Message----- > >> >> >>>>> From: t.petch [mailto:ietfc@btconnect.com] > >> >> >>>>> Sent: 19 November 2012 12:38 > >> >> >>>>> To: Loa Andersson; mpls@ietf.org > >> >> >>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >> >> ; MPLS-TP ad > >> >> >>>>> hoc > >> >> >>> team; > >> >> >>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > >> >> >>>>> Subject: Re: [mpls] working group last call on > >> >> >>> draft-ietf-mpls-tp-mip-mep-map > >> >> >>>>> > >> >> >>>>> After getting to section 6 and its features > >> >> (requirements!), I find > >> >> >>>>> myself underwhelmed; is that it? Well, I suppose so, it > is > >> >> >>>>> Informational and not Standards Track. > >> >> >>>>> > >> >> >>>>> Meanwhile, I suggest some editorial issues. > >> >> >>>>> > >> >> >>>>> Title > >> >> >>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > >> >> [Handling > >> >> >>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a > more > >> >> >>>>> informative statement unless and until you get to the > >> >> definition of > >> >> >>>>> Internal in s3; and s6, which is the crux of the > document > >> >> says The > >> >> >>>>> preferred solution to per-interface MIP message handling > is > >> >> >>>>> presented in this section] > >> >> >>>>> > >> >> >>>>> s1 > >> >> >>>>> two (or more) MIPs per node on both sides of the > >> >> forwarding engine. > >> >> >>>>> [two on both sides sounds like four in total to me; > >> >> suggest 'one on > >> >> >>>>> each side of the forwarding engine'] > >> >> >>>>> > >> >> >>>>> s4 > >> >> >>>>> o CV between a MEP and a MIP > >> >> >>>>> [expand CV on first use] > >> >> >>>>> > >> >> >>>>> s5 > >> >> >>>>> In-band OAM messages are sent using the G-ACh [RFC5586] > >> >> for MPLS-TP > >> >> >>>>> LSPs and MPLS-TP PWs, respectively. > >> >> >>>>> ['respectively' suggests to me that there should be two > >> >> precedents, > >> >> >>>>> not just RFC5586; the second paragraph specifies RFC5586 > >> for > >> >> LSPs, > >> >> >>>>> RFC6423/RFC4385 for PWs, in which case, strike this > >> sentence > >> >> as > >> >> >>>>> redundant] > >> >> >>>>> > >> >> >>>>> s6 > >> >> >>>>> The appendix of this document contains a > >> >> >>>>> few solutions that the authors have discarded which > have > >> >> been > >> >> >> left in > >> >> >>>>> the document for informational purposes. > >> >> >>>>> [not any more they haven't!] > >> >> >>>>> > >> >> >>>>> The node itself is addresses > >> >> >>>>> [The node itself is addressed] > >> >> >>>>> > >> >> >>>>> The identification information indside [The > identification > >> >> >>>>> information inside ] > >> >> >>>>> > >> >> >>>>> MIP identifiers are not know > >> >> >>>>> [MIP identifiers are not known] > >> >> >>>>> > >> >> >>>>> reserved MIP address > >> >> >>>>> [reserved MIP addressses or a reserved MIP address] > >> >> >>>>> > >> >> >>>>> Tom Petch > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> ----- Original Message ----- > >> >> >>>>> From: "Loa Andersson" > >> >> >>>>> To: > >> >> >>>>> Cc: ; >> >> chairs@tools.ietf.org>; > >> >> >>>>> "MPLS-TP ad hoc team" ; > >> >> >>>>> > >> >> >>>>> Sent: Wednesday, November 14, 2012 3:16 PM > >> >> >>>>> > >> >> >>>>>> Working Group, > >> >> >>>>>> > >> >> >>>>>> This is to start a 2 week working group last call on > >> >> >>>>>> draft-ietf-mpls-tp-mip-mep-map. > >> >> >>>>>> > >> >> >>>>>> Please send your comments to the mpls working group > >> mailing > >> >> list > >> >> >>>>>> (mpls@ietf.org). > >> >> >>>>>> > >> >> >>>>>> Please send both technical comments, and if you are > >> >> happy with the > >> >> >>>>>> document as is also indications of support. > >> >> >>>>>> > >> >> >>>>>> This working group last call will end on November 28. > >> >> >>>>>> > >> >> >>>>>> /Loa > >> >> >>>>>> for the wg co-chairs > >> >> >>>> > >> >> >>>> > >> >> >>>> _______________________________________________ > >> >> >>>> mpls mailing list > >> >> >>>> mpls@ietf.org > >> >> >>>> https://www.ietf.org/mailman/listinfo/mpls > >> >> >>> > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> mpls mailing list > >> >> >>> mpls@ietf.org > >> >> >>> https://www.ietf.org/mailman/listinfo/mpls > >> >> >> _______________________________________________ > >> >> >> mpls mailing list > >> >> >> mpls@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/mpls > >> >> > > >> >> > NEC Europe Limited | Registered Office: NEC House, 1 > Victoria > >> >> Road, London W3 6BL | Registered in England 2832014 > >> >> > _______________________________________________ > >> >> > mpls mailing list > >> >> > mpls@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/mpls > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > > >> > > > > > > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > >=20 From Rolf.Winter@neclab.eu Tue Dec 4 00:46:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD98221F8605 for ; Tue, 4 Dec 2012 00:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.385 X-Spam-Level: X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4kk+QILxCe1 for ; Tue, 4 Dec 2012 00:46:36 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E059A21F845B for ; Tue, 4 Dec 2012 00:46:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1E2C310282A; Tue, 4 Dec 2012 09:46:35 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKwkiWYhyS9z; Tue, 4 Dec 2012 09:46:35 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 03859102828; Tue, 4 Dec 2012 09:46:15 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 09:46:15 +0100 From: Rolf Winter To: Puneet Agarwal , "hideki.endo.es@hitachi.com" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eK+O4JEBXeB5UOt6q9GpTzxDZgIUb6Q Date: Tue, 4 Dec 2012 08:46:05 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com> In-Reply-To: <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:46:37 -0000 Hi, quite some time ago we asked whether we could mandate TLV ordering (at leas= t mandating one out of N TLVs to be the first in the OAM PDU) in order to a= llow efficient implementation in HW. This actually would be a good thing in= this case. The responses we got weren't quite positive (which is actually = quite a positive description of the responses we got) but I don't see that = the GACh RFC is actually disallowing it. Still we would need to go back and= make changes to a few RFCs. That was also something people weren't really = happy about. Again, these were some of the constraints we worked with which= led to what is on the table right now. We weren't blind to HW consideratio= ns, vice versa as you can see when you look at the appendix that was remove= d in the latest version of the document. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Dienstag, 4. Dezember 2012 06:44 > To: hideki.endo.es@hitachi.com > Cc: Shahram Davari; Rolf Winter; mpls@ietf.org > Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip- > mep-map >=20 > Hi hideki, >=20 > Is the determination that the mip identifier is present in the same > location always in the pdu or is it variable (based on oam msg type)? >=20 > Thx >=20 > Puneet >=20 >=20 >=20 > On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" > wrote: >=20 > > draft-ietf-mpls-tp-mip-mep-map From hideki.endo.es@hitachi.com Tue Dec 4 00:56:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F02B21F8414 for ; Tue, 4 Dec 2012 00:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv96XzXCWK-u for ; Tue, 4 Dec 2012 00:56:30 -0800 (PST) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB33221F84CF for ; Tue, 4 Dec 2012 00:56:28 -0800 (PST) Received: from mlsv8.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id AC0F437C8E; Tue, 4 Dec 2012 17:56:26 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv8.hitachi.co.jp (8.13.1/8.13.1) id qB48uQHb031362; Tue, 4 Dec 2012 17:56:26 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB48uEW2032068; Tue, 4 Dec 2012 17:56:26 +0900 Received: from vshuts04.hitachi.co.jp ([vshuts04.hitachi.co.jp [10.201.6.86]]) by mfilter06.hitachi.co.jp with RELAY id qB48uPI0032156 ; Tue, 4 Dec 2012 17:56:26 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 8C8D4140077; Tue, 4 Dec 2012 17:56:24 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB48uOm16048328; Tue, 4 Dec 2012 17:56:24 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Tue, 4 Dec 2012 17:56:07 +0900 References: <5098CF68.2000105@pi.nu> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> Priority: normal Importance: normal X400-Content-Identifier: X50BDBA9100000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121204175545KQE] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working group last callondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 08:56:32 -0000 Sharhram, I didn't mean new requirement similar to Figure 7. I do think that OAM packets must go through the normal forwarding engine without bypass. As Rolf said in other e-mail, -------------------------- | -----| | | MIP1| | ->-| |->---- | | | Out | | | | i/f | | | -----| |----- | -----| | MIP0| ---- | | MIP2| | | | |- | | ----->-| In |->-| FW |--->-| Out |->---- | i/f | | |- | i/f | |----- ---- | -----| | | -----| | | | MIP3| | | | | | ->-| Out |->---- | | i/f | | -----| -------------------------- The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually. Here, each out-MIP has different MIP ID. If you don't need this machanism, how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? Thanks, Hideki Endo >Hideki, > >In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding engine and do unicast forwarding of a multicast OAM packet to a single outgoing port. This kind of behavior is explicitly rejected in the draft. > >Regards, >Shahram > > >On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: > >> Hi Hideki, >> >> I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP. >> >> But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc. >> >> >> Regards, >> Shahram >> >> >> On Dec 3, 2012, at 5:24 PM, wrote: >> >>> Hi Shahram, >>> >>> Back and forth. >>> Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not. >>> >>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>> Don't you consider the case when MIPs is configured in the Egress port B,C and D? >>> In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D. >>> In that case, your solution has low effectiveness as I pointed out. >>> Do I miss something? >>> >>> Thanks, >>> Hideki Endo >>> >>> >>>> Hi, >>>> >>>> Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW. >>>> >>>> Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW. >>>> >>>> Thanks, >>>> Shahram >>>> >>>> -----Original Message----- >>>> From: Shahram Davari >>>> Sent: Monday, December 03, 2012 4:53 PM >>>> To: 'hideki.endo.es@hitachi.com' >>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>> >>>> Hi Hideki, >>>> >>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>> >>>> Thx >>>> Shahram >>>> >>>> -----Original Message----- >>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>> Sent: Monday, December 03, 2012 4:48 PM >>>> To: Shahram Davari >>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>> >>>> Hi Shahram, >>>> >>>> First, as Rolf sent, we need in/out-MIP for >>>> 1. CV between a MEP and a MIP >>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >>>> 3. data-plane loopback configuration at a MIP >>>> 4. diagnostic tests >>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>> >>>> Second, you wrote; >>>> "The issue is that each CPU/processor has limited resources. >>>> By sending all OAM MIP packets to both processor you are >>>> losing 1/2 of the capacity of each processor. " >>>> It depends on implementations, >>>> and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. >>>> Let's consider P2MP case as you pointed out. >>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>> This means that the OAM processor at port D loses its capacity. >>>> If we consider the larger number of ports in the LSR which has 100 ports, for example, >>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>> This means that the OAM processors at the other 98 ports lose those capacities. >>>> Even if your solution using ACH header is applied, >>>> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >>>> in the case of P2MP for 100 ports. >>>> >>>> Thanks, >>>> Hideki Endo >>>> >>>> >>>>> Rolf, >>>>> >>>>> For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: >>>>> >>>>> 1) MIP on port A (In-MIP), or >>>>> 2) MIP on port B (out-MIP), or >>>>> 3) MEIP on Port A and B >>>>> >>>>> A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. >>>>> >>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. >>>>> >>>>> So the Pseudo-code is like this: >>>>> >>>>> Ingress Port: >>>>> >>>>> If packet is OAM and TTL=1 >>>>> If MIP is enabled >>>>> If packet indicates In-MIP >>>>> Send to local CPU >>>>> Else >>>>> Forward to egress port >>>>> End >>>>> Else >>>>> Forward normally >>>>> End >>>>> Else >>>>> >>>>> Egress Port: >>>>> >>>>> If packet is OAM and TTL=1 >>>>> If MIP is enabled >>>>> If packet indicates In-MIP >>>>> Drop packet >>>>> Else If packet indicates Out-MIP >>>>> Send to local CPU >>>>> End >>>>> Else >>>>> Drop packet >>>>> End >>>>> End >>>>> >>>>> >>>>> Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? >>>>> >>>>> Thanks >>>>> Shahram >>>>> >>>>> -----Original Message----- >>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>> To: Shahram Davari >>>>> Cc: Pablo Frank; mpls@ietf.org >>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>> >>>>> But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. >>>>> >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>> To: Rolf Winter >>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>>>>> mep-map >>>>>> >>>>>> Hi Rolf, >>>>>> >>>>>> Your HW guys are correct as long as the amount of data sent to the in- >>>>>> MIP processor is not much. But from your previous email to Loa I see >>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>>>>> not be expecting them is like DoS attack. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> Shahram >>>>>> >>>>>> >>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> sorry for the belated response. I checked with some of our HW people. >>>>>> Here's the gist of their response: >>>>>>> >>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>> fact already. Their answer to the problem is slightly different though. >>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>>>> implementation must behave in this exact way in either case. So there >>>>>> is at least one way to implement this at line rate without going back >>>>>> and changing a bunch of RFCs. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Rolf >>>>>>> >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>>>>> Of Shahram Davari >>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>> To: Pablo Frank >>>>>>>> Cc: mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>> >>>>>>>> Pablo, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thx >>>>>>>> Shahram >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>> To: Shahram Davari >>>>>>>> Cc: mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think Shahram raises a very legitimate concern about how expensive >>>>>>>> this could be to implement in hardware. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> At the ingress blade: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>> >>>>>>>> Parse MIP-ID TLV >>>>>>>> >>>>>>>> Lookup MIP-ID >>>>>>>> >>>>>>>> IF MIP-is-egress, THEN >>>>>>>> >>>>>>>> forward normally (but note we must intercept it again on >>>>>> egress) >>>>>>>> >>>>>>>> ELSE >>>>>>>> >>>>>>>> punt to OAM processor >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> At the egress blade: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>> >>>>>>>> Parse MIP-ID TLV >>>>>>>> >>>>>>>> Lookup MIP-ID >>>>>>>> >>>>>>>> IF MIP-is-egress, THEN >>>>>>>> >>>>>>>> punt to OAM processor >>>>>>>> >>>>>>>> ELSE >>>>>>>> >>>>>>>> drop >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-path >>>>>>>> had to do was look for TTL-expiry. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>>>> of >>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Pablo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Rolf, >>>>>>>>> >>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>> think you agree with me that this draft requires deep parsing of all >>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>> >>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>> OAM >>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For example >>>>>>>> how about using one of the reserved bits in the ACH header. This >>>>>> can >>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Shahram >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>> Behalf Of Rolf Winter >>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>> Cc: mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>>> tp-mip-mep-map >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> Hi Adrian, >>>>>>>>>> >>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>> before >>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>> >>>>>>>>>> One thing I didn't understand in your response is that you >>>>>> said >>>>>>>> in-MIP >>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>> that? >>>>>>>>>> >>>>>>>>>> My understanding is that before this draft, the process would >>>>>>>> have >>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>> send the >>>>>>>>>> packet to OAM processor. >>>>>>>>> >>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>> (RFC >>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>>>> location within the node)". >>>>>>>>> >>>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>>> is suggests there is no per-interface MIP addressing possible as of >>>>>> now. >>>>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>>>> We >>>>>>>> cannot really go back and change all this. There are other >>>>>> constraints. >>>>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>> constraints we worked with. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>> filtering >>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>> the MEPID >>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>> indicator to >>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>> the data >>>>>>>>>> path in the Ingress or egress. >>>>>>>>>> >>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>> >>>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>>> or >>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>> simple >>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>> in-MIP or >>>>>>>>>> Out-MIP". >>>>>>>>> >>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>>>> have to do a second lookup, since it would require some parsing. All >>>>>>>> these constraints and the ones outlined in the document led to where >>>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>>> number of things that seem like a good idea at first but then have a >>>>>>>> catch of some sort. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Rolf >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Shahram >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Shahram, >>>>>>>>>>> >>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>> during >>>>>>>> WG >>>>>>>>>> last call. >>>>>>>>>>> While comments that improve the document or point out >>>>>>>> fundamental >>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>> flavour "I >>>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>>> process >>>>>>>>>> don't feel very constructive. >>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>> address >>>>>>>>>>> the technical points... >>>>>>>>>>> >>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>> it >>>>>>>> in In- >>>>>>>>>> MIP vs. >>>>>>>>>>> Out- >>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>>> not >>>>>>>>>> take >>>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>>> that is >>>>>>>>>>>> proposed in this >>>>>>>>>>> draft >>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>> to >>>>>>>> cost. >>>>>>>>>>> >>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>> decide to >>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>>> the >>>>>>>>>> same >>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>> interface >>>>>>>>>>> inspects the packets (at line >>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>> interface. >>>>>>>>>>> >>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>> the >>>>>>>> lookup >>>>>>>>>>> as easy as possible. >>>>>>>>>>> >>>>>>>>>>>> Perhaps a >>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>> Level) may be >>>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>> >>>>>>>>>>> Perhaps it could. >>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>> version of >>>>>>>>>>> the I-D arduous? >>>>>>>>>>> >>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>> In-MIPs >>>>>>>>>> are >>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>> today on >>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>> proposing >>>>>>>>>> such >>>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>>> D and >>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>> >>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>> lookup on >>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>> both >>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>> can do >>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>> lookup on >>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>> >>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>> the >>>>>>>>>>> incoming interface and the packet marked for easy >>>>>> interception >>>>>>>> on the >>>>>>>>>> outgoing interface. >>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>> longer be >>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>> modified in >>>>>>>>>> flight. >>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>> the >>>>>>>> packet >>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>> needed. >>>>>>>>>>> >>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>> progressed, >>>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>>> pros >>>>>>>>>> and >>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Adrian >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>> On >>>>>>>> Behalf >>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>> ; >>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>> >>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>> anything >>>>>>>>>> else? >>>>>>>>>>>> >>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>> were >>>>>>>> saying >>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>> backward >>>>>>>>>> compatible". >>>>>>>>>>>> >>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>> >>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>> hoc >>>>>>>>>>> team; >>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>> >>>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>>> I find >>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>> >>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>> >>>>>>>>>>>>> Title >>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>> [Handling >>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>> definition of >>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>> says The >>>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>> >>>>>>>>>>>>> s1 >>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>>> engine. >>>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>>> 'one on >>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>> >>>>>>>>>>>>> s4 >>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>> >>>>>>>>>>>>> s5 >>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>>> MPLS-TP >>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>> precedents, >>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>> for >>>>>>>> LSPs, >>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>> sentence >>>>>>>> as >>>>>>>>>>>>> redundant] >>>>>>>>>>>>> >>>>>>>>>>>>> s6 >>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>> been >>>>>>>>>> left in >>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>> >>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>> >>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>> information inside ] >>>>>>>>>>>>> >>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>> >>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>> >>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>> To: >>>>>>>>>>>>> Cc: ; >>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>> >>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>> >>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>> mailing >>>>>>>> list >>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>> with the >>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>> >>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> > > From davari@broadcom.com Tue Dec 4 01:22:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B2821F8659 for ; Tue, 4 Dec 2012 01:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.269 X-Spam-Level: X-Spam-Status: No, score=-5.269 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX2E6srVE2uY for ; Tue, 4 Dec 2012 01:22:29 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3421F85E6 for ; Tue, 4 Dec 2012 01:22:29 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 01:17:53 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 01:22:18 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 01:21:57 -0800 From: "Shahram Davari" To: "Rolf Winter" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0gDOGLzGkGQffUCu8eKg5ppt/Q== Date: Tue, 4 Dec 2012 09:21:57 +0000 Message-ID: <1C7E7722-1249-44A1-AF38-FD6CA490718D@broadcom.com> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA3604A39W4985624-01-01 Content-Type: multipart/alternative; boundary=_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_ Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:22:33 -0000 --_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Rolf, The job of OAM is to diagnose issues in the data plane. This means OAM has = to take the same path as Data. Therefore on a P2MP LSP, OAM must be multica= sted, similar to data. You can't just send to one MEP or MIP. Here is what RFC6371 says: P2MP Considerations All the traffic sent over a P2MP transport path, including OAM packets gene= rated by a MEP, is sent (multicast) from the root to all the leaves. As a c= onsequence: o To send an OAM packet to all leaves, the source MEP can send a single OA= M packet that will be delivered by the forwarding plane to all the leaves a= nd processed by all the leaves. Hence, a single OAM packet can simultaneous= ly instrument all the MEs in a P2MP MEG. o To send an OAM packet to a single leaf, the source MEP sends a single OA= M packet that will be delivered by the forwarding plane to all the leaves b= ut contains sufficient information to identify a target leaf, and therefore= is processed only by the target leaf and can be silently discarded by the = other leaves. So although you can send a targeted OAM message to only one MEP or MIP, but= the same message is going to be received by all MEPs or MIPs (with same TT= L distance). The others just drop it. So in the MIP example provided the ingress port of a router can't decide to= which selective egress port it has to send the OAM packet to. The only de= cision it can make is that an OAM message is or is not for itself (the in-M= EP). Each egress port also decide individually whether the OAM is for itsel= f or not, and if not just drops the packet. So for sure the in-MEP doesn't need to look at MEPID to decide whether to t= erminate and send the OAM packet to CPU or forward normally. A single bit i= s enough for making such decision. Regarding out-MIPs, there are 2 options: 1) send OAM packet received with TTL expiry to CPU and let CPU look at MEPI= D and if not correct drop it 2) let the HW to look at MEPID and if correct, send the packet to CPU, else= drop it. I agree the 2nd option is more efficient, but is not practical, since locat= ing arbitrarily located TLVs in various different OAM packet types such as = BFD, LSP-Ping, etc is not practical. Thx Shahram Regards, Shahram On Dec 4, 2012, at 12:34 AM, "Rolf Winter" > wrote: Shahram, what if it is configured and you only want to talk to one out of all the ou= t-MIPs. I guess we can all craft examples where we can make our point. A si= ngle bit simply does not guarantee you that the local CPU does not have to = look at the OAM frame to finally discard it. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Dienstag, 4. Dezember 2012 01:53 To: hideki.endo.es@hitachi.com Cc: Rolf Winter; mpls@ietf.org Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls- tp-mip-mep-map Hi Hideki, I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. Thx Shahram -----Original Message----- From: hideki.endo.es@hitachi.com [mailto= :hideki.endo.es@hitachi.com] Sent: Monday, December 03, 2012 4:48 PM To: Shahram Davari Cc: Rolf.Winter@neclab.eu; mpls@ietf.org Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp- mip-mep-map Hi Shahram, First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests Here, CV means On-demand CV. You may misunderstand as Proactive CV. Second, you wrote; "The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. " It depends on implementations, and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. Let's consider P2MP case as you pointed out. All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processor at port D loses its capacity. If we consider the larger number of ports in the LSR which has 100 ports, for example, All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. This means that the OAM processors at the other 98 ports lose those capacities. Even if your solution using ACH header is applied, it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness in the case of P2MP for 100 ports. Thanks, Hideki Endo Rolf, For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: 1) MIP on port A (In-MIP), or 2) MIP on port B (out-MIP), or 3) MEIP on Port A and B A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. So the Pseudo-code is like this: Ingress Port: If packet is OAM and TTL=3D1 If MIP is enabled If packet indicates In-MIP Send to local CPU Else Forward to egress port End Else Forward normally End Else Egress Port: If packet is OAM and TTL=3D1 If MIP is enabled If packet indicates In-MIP Drop packet Else If packet indicates Out-MIP Send to local CPU End Else Drop packet End End Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? Thanks Shahram -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] Sent: Monday, December 03, 2012 12:10 PM To: Shahram Davari Cc: Pablo Frank; mpls@ietf.org Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -----Original Message----- From: Shahram Davari [mailto:davari@broadcom.com] Sent: Montag, 3. Dezember 2012 16:27 To: Rolf Winter Cc: Pablo Frank; mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- mep-map Hi Rolf, Your HW guys are correct as long as the amount of data sent to the in- MIP processor is not much. But from your previous email to Loa I see that you want to also terminate CV at MIPs. CVs are fast and high bandwidth and blindly dumping them on a CPU or OAM processor that may not be expecting them is like DoS attack. Regards, Shahram On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > wrote: Hi, sorry for the belated response. I checked with some of our HW people. Here's the gist of their response: Of course they wouldn't like parsing TLVs but we established that fact already. Their answer to the problem is slightly different though. A TTL-expired OAM frame can simply be copied and forwarded to the out- MIPs where, if the frame is not intended for them, it can safely be dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the implementation must behave in this exact way in either case. So there is at least one way to implement this at line rate without going back and changing a bunch of RFCs. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Shahram Davari Sent: Mittwoch, 28. November 2012 18:46 To: Pablo Frank Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- mep-map Pablo, That was exactly my point. Let's use a flag to indicate in-MIP or out- MIP and then the offline processor can do MEPID lookup to determine whether this is a legitimate OAM packet or not. Thx Shahram From: Pablo Frank [mailto:pabloisnot@gmail.com] Sent: Wednesday, November 28, 2012 8:22 AM To: Shahram Davari Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- mep-map I think Shahram raises a very legitimate concern about how expensive this could be to implement in hardware. As I understand it, the logic proposed by this draft is as follows: At the ingress blade: IF TTL-expired && GAL-is-present && GACh-type-is-X THEN Parse MIP-ID TLV Lookup MIP-ID IF MIP-is-egress, THEN forward normally (but note we must intercept it again on egress) ELSE punt to OAM processor At the egress blade: IF TTL-expired && GAL-is-present && GACh-type-is-X THEN Parse MIP-ID TLV Lookup MIP-ID IF MIP-is-egress, THEN punt to OAM processor ELSE drop Note all this has to be done in the fast-path now at full line rate (and hardware guys hate TLVs). Before, the only thing the fast-path had to do was look for TTL-expiry. The only reason that ACH reserved bit was rejected (in Appendix A.4 of -03 version of doc) was because it also required a MIP-ID lookup. But I don't see anything wrong with combining both mechanisms. Ideally, hardware could rely on the reserved bit to do the initial filtering at full line-rate and then a presumably much more cost-efficient OAM hardware block could perform the MIP-ID lookup. Instead of the complex logic above, the fast path gets a simple modification to TTL handling and the OAM block does the heavy lifting of dealing with ACH TLVs, etc. This seems like a case where practicality should trump elegance. regards, Pablo On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > wrote: Rolf, I am sure you know that TLVs are not Hardware friendly. And I think you agree with me that this draft requires deep parsing of all packets at line rate to get to the MIPID TLV. I still think the MIPID TLV is required to decide whether an OAM packet ended up at the right MIP. But may be a simpler solution could be augmented to decide between In-MIP and Out-MIP. For example how about using one of the reserved bits in the ACH header. This can easily be done in hardware with minimum complexity. Regards, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Rolf Winter Sent: Wednesday, November 21, 2012 12:13 PM To: S. Davari; adrian@olddog.co.uk Cc: mpls@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls- tp-mip-mep-map Hi, Hi Adrian, You are right and I should have sent these types of comments before last call. I completely understand the procedure. One thing I didn't understand in your response is that you said in-MIP requires to do the MEPID lookup at line rate anyway. Why is that? My understanding is that before this draft, the process would have been for the ingress to look at TTL and if it is expired then send the packet to OAM processor. Yes (and no). While I assume likely MIP functionality will be implemented on the ingress, the related RFCs are vague about the actual placement of the MIP function. See e.g. the OAM Framework (RFC 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified location within the node)". Also, I think "before this draft" is not quite accurate in that is suggests there is no per-interface MIP addressing possible as of now. Take RFC 6426. In practice this is where part of the problem lies. We cannot really go back and change all this. There are other constraints. E.g. we have a requirement to address a single out-MIP out of a set of out-MIPs on a P2MP branch point. So this was part of the constraints we worked with. The MEPID that you suggest in this draft is very useful for filtering out leaked OAM frames from upstream. But lets leave lookup of the MEPID to the OAM processing module (at slower rate) and add an indicator to the OAM packet to indicate whether it should be taken out of the data path in the Ingress or egress. So can I suggest adding the following text to the draft: " In addition to the MEPID, which is used to ultimately accept or filter out received OAM packets, OAM packets should have a simple indicator that identifies whether the OAM packet belongs to in-MIP or Out-MIP". We also have the question on where to retrofit those bits. I assume a TLV wouldn't work for the exact reasons you do not like to have to do a second lookup, since it would require some parsing. All these constraints and the ones outlined in the document led to where we are. In a sense this is a non-spec since it rather rules out a number of things that seem like a good idea at first but then have a catch of some sort. Best, Rolf Regards, Shahram On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > wrote: Hi Shahram, I am worried about the precedent of a comment like this during WG last call. While comments that improve the document or point out fundamental flaws are welcome whenever they arrive, points with the flavour "I wouldn't have done it like this" that arrive this late in the process don't feel very constructive. But I will leave the chair to worry about process and try to address the technical points... Identifying whether to terminate an OAM packet and process it in In- MIP vs. Out- MIP requires line rate lookup, otherwise the OAM packet will not take the same path as data packets. Therefore any MIP identifier that is proposed in this draft requires one extra lookup and therefore adds significantly to cost. If I am not wrong, this is a feature of an out-MIP. If you decide to implement out-MIPs, and if you want the OAM to follow exactly the same path as the data, then it is a requirement that the out interface inspects the packets (at line rate) to determine whether they are OAM and targeted at the interface. We cannot change that aspect. All we can do is aim to make the lookup as easy as possible. Perhaps a similar method to Ethernet MDL/MEL (Maintenance Domain Level) may be used that requires only 3 bits and achieves the same result. Perhaps it could. But before going there, why is the lookup in the current version of the I-D arduous? Presumably you do not propose making any change to the way In-MIPs are currently identified, so the lookups being done at line rate today on the incoming interfaces will not be changed. If you are proposing such a change, then the discussion is outside the scope of this I- D and becomes a much wider question for the working group. This leaves me with the trade-off of enabling a *simpler* lookup on the outgoing interfaces versus doing identical lookups on both interfaces. My assumption was that if the incoming interface can do the lookup at line rate, it is not hard to perform the same lookup on the outgoing interface. Furthermore, there is a reduction in complexity by having fewer things to look up. Another possibility is that the full lookup could be done on the incoming interface and the packet marked for easy interception on the outgoing interface. The concern with this approach is that the packet would no longer be being forwarded exactly as data because it would be being modified in flight. Furthermore, in the case of P2MP, it is not enough to flag the packet as a local Out-MIP and further identifier-based lookup is needed. Some of these issues were raised and discussed as the I-D progressed, and some of the alternative solutions were tracked with their pros and cons in Appendix A of the I-D (look at revision -03). Thanks, Adrian -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls- bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, November 19, 2012 8:45 AM To: 't.petch'; 'Loa Andersson'; mpls@ietf.org Cc: mpls-ads@tools.ietf.org; mpls-chairs@to= ols.ietf.org ; draft-ietf-mpls-tp-mip- mep-map@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Yeah, it's a boring draft. Did you expect me to co-author anything else? The point was that when I started the I-D lots of people were saying "it's complex" and "it can't be done" and "it won't be backward compatible". So the I-D says "here it is" A (sorry not to offer you excitement) -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: 19 November 2012 12:38 To: Loa Andersson; mpls@ietf.org Cc: mpls-ads@tools.ietf.org; mpls-chairs@to= ols.ietf.org ; MPLS-TP ad hoc team; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map After getting to section 6 and its features (requirements!), I find myself underwhelmed; is that it? Well, I suppose so, it is Informational and not Standards Track. Meanwhile, I suggest some editorial issues. Title Handling MPLS-TP OAM Packets Targeted at Internal MIPs [Handling MPLS-TP OAM Packets Targeted at Interface MIPs seems a more informative statement unless and until you get to the definition of Internal in s3; and s6, which is the crux of the document says The preferred solution to per-interface MIP message handling is presented in this section] s1 two (or more) MIPs per node on both sides of the forwarding engine. [two on both sides sounds like four in total to me; suggest 'one on each side of the forwarding engine'] s4 o CV between a MEP and a MIP [expand CV on first use] s5 In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP LSPs and MPLS-TP PWs, respectively. ['respectively' suggests to me that there should be two precedents, not just RFC5586; the second paragraph specifies RFC5586 for LSPs, RFC6423/RFC4385 for PWs, in which case, strike this sentence as redundant] s6 The appendix of this document contains a few solutions that the authors have discarded which have been left in the document for informational purposes. [not any more they haven't!] The node itself is addresses [The node itself is addressed] The identification information indside [The identification information inside ] MIP identifiers are not know [MIP identifiers are not known] reserved MIP address [reserved MIP addressses or a reserved MIP address] Tom Petch ----- Original Message ----- From: "Loa Andersson" > To: > Cc: >; >; "MPLS-TP ad hoc team" >; > Sent: Wednesday, November 14, 2012 3:16 PM Working Group, This is to start a 2 week working group last call on draft-ietf-mpls-tp-mip-mep-map. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. This working group last call will end on November 28. /Loa for the wg co-chairs _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Rolf,

The job of OAM is to diagno= se issues in the data plane. This means OAM has to take the same path as Da= ta. Therefore on a P2MP LSP, OAM must be multicasted, similar to data. You = can't just send to one MEP or MIP.


Here is what RFC6371 says:<= /div>

 

P2MP Considerations

All the t= raffic sent over a P2MP transport path, including OAM packets generated by = a MEP, is sent (multicast) from the root to all the leaves. As a consequenc= e: 

 o To send an OAM packet to all leaves= , the source MEP can send a single OAM packet that will be delivered by the= forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrumen= t all the MEs in a P2MP MEG. 

 o To send an OAM packet to a single l= eaf, the source MEP sends a single OAM packet that will be delivered by the= forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is process= ed only by the target leaf and can be silently discarded by the other leave= s. 

So although you can send a targeted OAM mes= sage to only one MEP or MIP, but the same message is going to be received b= y all MEPs or MIPs (with same TTL distance). The others just drop it. 

So in the MIP example provided the ingress = port of a router can't decide to which selective egress port it has to send= the OAM packet to.  The only decision it can make is that an OAM message is or is not for itself (the in-MEP). E= ach egress port also decide individually whether the OAM is for itself or n= ot, and if not just drops the packet.

So for sure the in-MEP doesn't need to look= at MEPID to decide whether to terminate and send the OAM packet to CPU or = forward normally. A single bit is enough for making such decision. Regarding out-MIPs, there are 2 options:<= /div>

1) send OAM packet received with TTL expiry= to CPU and let CPU look at MEPID and if not correct drop it

2) let the HW to look at MEPID and if corre= ct, send the packet to CPU, else drop it.

I agree the 2nd option is more efficient, b= ut is not practical, since locating arbitrarily located TLVs in various dif= ferent OAM packet types such as BFD, LSP-Ping, etc is not practical.

Thx
Shahram






Regards,
Shahram


On Dec 4, 2012, at 12:34 AM, "Rolf Winter" <Rolf.Winter@neclab.eu> wrote:

Shahram,

what if it is configured and you only want to talk to one out of all = the out-MIPs. I guess we can all craft examples where we can make our point= . A single bit simply does not guarantee you that the local CPU does not ha= ve to look at the OAM frame to finally discard it.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, L= ondon W3 6BL | Registered in England 2832014


-----Original Message-----
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Dienstag, 4. Dezember 2012 01:53
To: hideki.endo.es@hitachi.com
Cc: Rolf Winter; mpls@ietf.org
Subject: RE: Re:Re: [mpls] working group la= st call on draft-ietf-mpls-
tp-mip-mep-map

Hi Hideki,

I think you need to look at my p-code. F a = MIP is not configured in the
Egress port, then that egress port won't se= nt the OAM packet to its
processor and drops it. So there is no issu= e with my proposed method.

Thx
Shahram

-----Original Message-----
From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]
Sent: Monday, December 03, 2012 4:48 PM
To: Shahram Davari
Cc: Rolf.Winter@neclab.eu; mpls@ietf.org
Subject: Re:Re: [mpls] working group last c= all on draft-ietf-mpls-tp-
mip-mep-map

Hi Shahram,

First, as Rolf sent, we need in/out-MIP for= 1. CV between a MEP and a
MIP 2. traceroute over an MPLS-TP LSP and/o= r an MPLS-TP PW containing
MIPs 3. data-plane loopback configuration a= t a MIP 4. diagnostic tests
Here, CV means On-demand CV. You may misund= erstand as Proactive CV.

Second, you wrote;
"The issue is that each CPU/processor = has limited resources.
By sending all OAM MIP packets to both proc= essor you are  losing 1/2
of the capacity of each processor. "
It depends on implementations,
and this issue could NOT be resolved by eve= n your solution that uses
ACH header to indicate in/out-MIP.
Let's consider P2MP case as you pointed out= .
All OAM MIP packets for out-MIPs port(B, C)= are sent to all out-MIPs.
This means that the OAM processor at port D= loses its capacity.
If we consider the larger number of ports i= n the LSR which has 100
ports, for example, All OAM MIP packets for= out-MIPs port(B, C) are
sent to all out-MIPs.
This means that the OAM processors at the o= ther 98 ports lose those
capacities.
Even if your solution using ACH header is a= pplied, it can reduce OAM
packets only for in-MIP, which means only 1= /101 effectiveness in the
case of P2MP for 100 ports.

Thanks,
Hideki Endo


Rolf,

For clarity it is better to use an example.= Assume that an LSR has 4
ports (A, B, C, D). Now assume that it rece= ives packets  on a unicast
LSP-X from port A and forwards them to port= B.  there can only be 3
configurations:

1) MIP on port A (In-MIP), or
2) MIP on port B (out-MIP), or
3) MEIP on Port A and B

A single OAM packet can be terminated and p= rocessed only by one of
these MIPs. Now assume OAM packet (P) is me= ant for out-MIP (MIPID =3Dport
B). In your example, you are saying send a = copy of the P to the
CPU/Processor on Port A, and send a copy al= so to CPU/Processor on Port
B. Port A CPU will drop the packet since th= e MIP-ID is not A.  The
issue is that each CPU/processor has limite= d resources.  By sending all
OAM MIP packets to both processor you are l= osing 1/2 of the capacity of
each processor.  The practical solutio= n is to have a simple indicator
in the packet header that this OAM packet i= s meant for Out-MIP. Then
port A just switches the OAM packet to Port= B, and Port B terminates
and sends it to its CPU/processor.

Lest get to P2MP example. Assume LSP-Y is a= P2MP LSP that enters the
chip from Port A and is sent to ports B, C,= D.  Also assume that there
is In-MIP on port A and out-MIPs of ports B= , C (not D).  Now assume a
Multicast OAM packet is  meant for out= -MIPs (B, C). In such case the
OAM packet should not be sent to port A CPU= /Processor. It is therefore
multicast to ports B, C, D. Ports B, C send= the OAM packet to their CPU.
Port D drops the OAM packets and does not s= end it to its CPU, since
there is no MIP configured for that MPLS la= bel.

So the Pseudo-code is like this:

Ingress Port:

If packet is OAM and TTL=3D1
   If MIP is enabled
       If packet indica= tes In-MIP
           Se= nd to local CPU
       Else
           Fo= rward to egress port
       End
   Else
       Forward normally=
   End
Else

Egress Port:

If packet is OAM and TTL=3D1
   If MIP is enabled
       If packet indica= tes In-MIP
           Dr= op  packet
       Else If packet i= ndicates Out-MIP
           Se= nd to local CPU
       End
   Else
       Drop packet
   End
End


Using this example could you please describ= e your reasoning for not
requiring HW to identify In-MEP vs out-MIPs= ?

Thanks
Shahram

-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Monday, December 03, 2012 12:10 PM
To: Shahram Davari
Cc: Pablo Frank; mpls@ietf.org
Subject: RE: [mpls] working group last call= on
draft-ietf-mpls-tp-mip-mep-map

But the MIP that is addressed needs to be a= ble to handle this _plus_
take an appropriate action and in the P2MP = case this will always be the
case since there are 2 or more out MIPs.

NEC Europe Limited | Registered Office: NEC= House, 1 Victoria Road,
London W3 6BL | Registered in England 28320= 14


-----Original Message-----
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Montag, 3. Dezember 2012 16:27=
To: Rolf Winter
Cc: Pablo Frank; mpls@ietf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls-tp-mip- mep-map

Hi Rolf,

Your HW guys are correct as long as the amo= unt of data sent to the
in- MIP processor is not much. But from you= r previous email to Loa I
see that you want to also terminate CV at M= IPs. CVs are fast and
high
bandwidth and blindly dumping them on a CPU= or OAM processor  that
may not be expecting them is like DoS attac= k.



Regards,
Shahram


On Dec 3, 2012, at 5:53 AM, "Rolf Wint= er" <Rolf.Winter@neclab.eu= >
wrote:

Hi,

sorry for the belated response. I checked w= ith some of our HW
people.
Here's the gist of their response:

Of course they wouldn't like parsing TLVs b= ut we established that
fact already. Their answer to the problem i= s slightly different
though.
A TTL-expired OAM frame can simply be copie= d and forwarded to the
out- MIPs where, if the frame is not intend= ed for them, it can
safely
be dropped. In the P2MP case e.g. this need= s to be done anyway, i.e.
the implementation must behave in this exac= t way in either case. So
there is at least one way to implement this= at line rate without
going back and changing a bunch of RFCs.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC= House, 1 Victoria Road,
London W3 6BL | Registered in England 28320= 14


-----Original Message-----
From: mpls-bounces@ietf.org [mai= lto:mpls-bounces@ietf.org] On
Behalf Of Shahram Davari
Sent: Mittwoch, 28. November 2012 18:46
To: Pablo Frank
Cc: mpls@i= etf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls-tp-mip- mep-map

Pablo,



That was exactly my point. Let's use a flag= to indicate in-MIP or
out- MIP and then the offline processor can= do MEPID lookup to
determine whether this is a legitimate OAM = packet or not.



Thx
Shahram



From: Pablo Frank [mailto:pabloisnot@gmail.com]
Sent: Wednesday, November 28, 2012 8:22 AM<= /span>
To: Shahram Davari
Cc: mpls@i= etf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls-tp-mip- mep-map



I think Shahram raises a very legitimate co= ncern about how
expensive this could be to implement in har= dware.



As I understand it, the logic proposed by t= his draft is as
follows:



At the ingress blade:



IF TTL-expired && GAL-is-present &a= mp;& GACh-type-is-X THEN

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    forward normally (b= ut note we must intercept it again on
egress)

 ELSE

    punt to OAM process= or



At the egress blade:



IF TTL-expired && GAL-is-present &a= mp;& GACh-type-is-X THEN

 Parse MIP-ID TLV

 Lookup MIP-ID

 IF MIP-is-egress, THEN

    punt to OAM process= or

 ELSE

    drop



Note all this has to be done in the fast-pa= th now at full line
rate (and hardware guys hate TLVs).  B= efore, the only thing the
fast-path had to do was look for TTL-expiry= .



The only reason that ACH reserved bit was r= ejected (in Appendix
A.4 of
-03 version of doc) was because it also req= uired a MIP-ID lookup.
But I don't see anything wrong with combini= ng both mechanisms.
Ideally, hardware could rely on the reserve= d bit to do the
initial
filtering at full line-rate and then a pres= umably much more
cost-efficient OAM hardware block could per= form the MIP-ID lookup.
Instead of the complex logic above, the fas= t path gets a simple
modification to TTL handling and the OAM bl= ock does the heavy
lifting of dealing with ACH TLVs, etc.



This seems like a case where practicality s= hould trump elegance.



regards,

Pablo



On Mon, Nov 26, 2012 at 11:48 AM, Shahram D= avari
<= davari@broadcom.com>
wrote:



Rolf,

I am sure you know that TLVs are not Hardwa= re friendly. And
I
think you agree with me that this draft req= uires deep parsing of
all packets at line rate to get to the MIPI= D TLV.

I still think the MIPID TLV is required to = decide whether an
OAM
packet ended up  at the right MIP. But= may be a simpler solution
could be augmented to decide between In-MIP= and Out-MIP. For
example how about using one of the reserved= bits in the ACH
header.  This
can
easily be done in hardware with minimum com= plexity.

Regards,
Shahram



-----Original Message-----
From: mpls-bounces@ietf.org [mai= lto:mpls-bounces@ietf.org]
On
Behalf Of Rolf Winter
Sent: Wednesday, November 21, 2012 12:13 PM=
To: S. Davari; adrian@olddog.co.uk
Cc: mpls@i= etf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls- tp-mip-mep-map

Hi,

Hi Adrian,

You are right and I should have sent these = types of
comments
before
last call. I completely understand the proc= edure.

One thing I didn't understand in your respo= nse is that you
said
in-MIP
requires to do the MEPID lookup at line rat= e anyway. Why is
that?

My understanding is that before this draft,=  the process
would have
been for the ingress to look at TTL and if = it is expired
then send the
packet to OAM processor.

Yes (and no). While I assume likely MIP fun= ctionality will
be
implemented on the ingress, the related RFC= s are vague about the
actual placement of the MIP function. See e= .g. the OAM Framework
(RFC
6371) "per-node MIPs (i.e., a single M= IP per node in an
unspecified location within the node)"= .

Also, I think "before this draft"= is not quite accurate in
that is suggests there is no per-interface = MIP addressing
possible
as of
now.
Take RFC 6426. In practice this is where pa= rt of the problem lies.
We
cannot really go back and change all this. = There are other
constraints.
E.g. we have a requirement to address a sin= gle out-MIP out of a
set of out-MIPs on a P2MP branch point. &nb= sp;So this was part of the
constraints we worked with.


The MEPID that you suggest in this draft is= very useful for
filtering
out leaked OAM frames from upstream. But le= ts leave lookup
of the MEPID
to the OAM processing module (at slower rat= e) and add an
indicator to
the OAM packet to indicate whether it shoul= d be taken out
of
the data
path in the Ingress or egress.

So can I suggest adding the following text = to the draft:

" In addition to the MEPID, which is u= sed to ultimately
accept or
filter out received OAM packets, OAM packet= s  should have a
simple
indicator that identifies whether the OAM p= acket belongs to
in-MIP or
Out-MIP".

We also have the question on where to retro= fit those bits. I
assume a TLV wouldn't work for the exact re= asons you do not like
to have to do a second lookup, since it wou= ld require some
parsing. All these constraints and the ones= outlined in the
document led to where we are. In a sense th= is is a non-spec since
it rather rules out a number of things that= seem like a good idea
at first but then have a catch of some sort= .

Best,

Rolf




Regards,
Shahram


On Nov 21, 2012, at 1:16 AM, "Adrian F= arrel"
<= adrian@olddog.co.uk>
wrote:

<co-author mode>

Hi Shahram,

I am worried about the precedent of a comme= nt like this
during
WG
last call.
While comments that improve the document or= point out
fundamental
flaws are welcome whenever they arrive, poi= nts with the
flavour "I
wouldn't have done it like this" that = arrive this late in
the process
don't feel very constructive.
But I will leave the chair to worry about p= rocess and try
to address
the technical points...

Identifying whether to terminate an OAM pac= ket and
process
it
in In-
MIP vs.
Out-
MIP requires line rate lookup, otherwise th= e OAM packet
will not
take
the same path as data packets.  Theref= ore any MIP
identifier that is
proposed in this
draft
requires one extra lookup and therefore add= s
significantly
to
cost.

If I am not wrong, this is a feature of an = out-MIP. If you
decide to
implement out-MIPs, and if you want the OAM= to follow
exactly the
same
path as the data, then it is a requirement = that the out
interface
inspects the packets (at line
rate) to determine whether they are OAM and= targeted at
the
interface.

We cannot change that aspect. All we can do= is aim to make
the
lookup
as easy as possible.

Perhaps a
similar method to Ethernet MDL/MEL (Mainten= ance Domain
Level) may be
used that requires only 3 bits and achieves= the same
result.

Perhaps it could.
But before going there, why is the lookup i= n the current
version of
the I-D arduous?

Presumably you do not propose making any ch= ange to the way
In-MIPs
are
currently identified, so the lookups being = done at line
rate today on
the incoming interfaces will not be changed= . If you are
proposing
such
a change, then the discussion is outside th= e scope of this
I- D and
becomes a much wider question for the worki= ng group.

This leaves me with the trade-off of enabli= ng a *simpler*
lookup on
the outgoing interfaces versus doing identi= cal lookups on
both
interfaces. My assumption was that if the i= ncoming
interface can do
the lookup at line rate, it is not hard to = perform the
same
lookup on
the outgoing interface. Furthermore, there = is a reduction
in
complexity by having fewer things to look u= p.

Another possibility is that the full lookup= could be done
on the
incoming interface and the packet marked fo= r easy
interception
on the
outgoing interface.
The concern with this approach is that the = packet would no
longer be
being forwarded exactly as data because it = would be being
modified in
flight.
Furthermore, in the case of P2MP, it is not= enough to flag
the
packet
as a local Out-MIP and further identifier-b= ased lookup is
needed.

Some of these issues were raised and discus= sed as the I-D
progressed,
and some of the alternative solutions were = tracked with
their pros
and
cons in Appendix A of the I-D (look at revi= sion -03).

Thanks,
Adrian
-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-
bounces= @ietf.org]
On
Behalf
Of Adrian Farrel
Sent: Monday, November 19, 2012 8:45 AM
To: 't.petch'; 'Loa Andersson'; mpls@ietf.org
Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org
<mailto:mpls-chairs@tools.ietf.org> ;
draft-ietf-mpls-tp-mip-
m= ep-map@tools.ietf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls-tp-mip-mep-map

Yeah, it's a boring draft. Did you expect m= e to co-author
anything
else?

The point was that when I started the I-D l= ots of people
were
saying
"it's complex" and "it can't= be done" and "it won't be
backward
compatible".

So the I-D says "here it is"

A (sorry not to offer you excitement)

-----Original Message-----
From: t.petch [mailto:ietfc@btconnect.com]
Sent: 19 November 2012 12:38
To: Loa Andersson; mpls@ietf.org
Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org
<mailto:mpls-chairs@tools.ietf.org> ; MPLS-TP ad
hoc
team;
draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org
Subject: Re: [mpls] working group last call= on
draft-ietf-mpls-tp-mip-mep-map

After getting to section 6 and its features=
(requirements!), I find
myself underwhelmed; is that it?  Well= , I suppose so, it
is
Informational and not Standards Track.

Meanwhile, I suggest some editorial issues.=

Title
Handling MPLS-TP OAM Packets Targeted at In= ternal MIPs
[Handling
MPLS-TP OAM Packets Targeted at Interface M= IPs seems a
more
informative statement unless and until you = get to the
definition of
Internal in s3; and s6, which is the crux o= f the
document
says The
preferred solution to per-interface MIP mes= sage handling
is
presented in this section]

s1
two (or more) MIPs per node on both sides o= f the
forwarding engine.
[two on both sides sounds like four in tota= l to me;
suggest 'one on
each side of the forwarding engine']=

s4
o  CV between a MEP and a MIP
[expand CV on first use]

s5
In-band OAM messages are sent using the G-A= Ch [RFC5586]
for MPLS-TP
LSPs and MPLS-TP PWs, respectively.<= br>
['respectively' suggests to me that there s= hould be two
precedents,
not just RFC5586; the second paragraph spec= ifies RFC5586
for
LSPs,
RFC6423/RFC4385 for PWs, in which case, str= ike this
sentence
as
redundant]

s6
The appendix of this document contains a
few solutions that the authors have discard= ed which
have
been
left in
the document for informational purposes.
[not any more they haven't!]

The node itself is addresses
[The node itself is addressed]

The identification information indside [The=
identification
information inside ]

MIP identifiers are not know
[MIP identifiers are not known]

reserved MIP address
[reserved MIP addressses or a reserved MIP = address]

Tom Petch


----- Original Message -----
From: "Loa Andersson" <loa@pi.nu>
To: <mp= ls@ietf.org>
Cc: <mpls-ads@tools.ietf.org>; <mpls-
ch= airs@tools.ietf.org>;
"MPLS-TP ad hoc team" <ahmpls-tp@lists.itu.int>;=
<draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org= >
Sent: Wednesday, November 14, 2012 3:16 PM<= /span>

Working Group,

This is to start a 2 week working group las= t call on
draft-ietf-mpls-tp-mip-mep-map.

Please send your comments to the mpls worki= ng group
mailing
list
(mpls@ietf= .org).

Please send both technical comments, and if= you are
happy with the
document as is also indications of support.=

This working group last call will end on No= vember 28.

/Loa
for the wg co-chairs


___________________________________________= ____
mpls mailing list
mpls@ietf.= org
https://www.ietf.org/mailman/listinfo/mpls


___________________________________________= ____
mpls mailing list
mpls@ietf.= org
https://www.ietf.org/mailman/listinfo/mpls
___________________________________________= ____
mpls mailing list
mpls@ietf.= org
https://www.ietf.org/mailman/listinfo/mpls

NEC Europe Limited | Registered Office: NEC= House, 1
Victoria
Road, London W3 6BL | Registered in England= 2832014
___________________________________________= ____
mpls mailing list
mpls@ietf.= org
https://www.ietf.org/mailman/listinfo/mpls



  _______________________________= ________________
  mpls mailing list
  mpls@ietf.org
  https://www.ietf.org/mailman/listinfo/mpls





___________________________________________= ____
mpls mailing list
mpls@ietf.= org
https://www.ietf.org/mailman/listinfo/mpls




--_000_1C7E7722124944A1AF38FD6CA490718Dbroadcomcom_-- From davarish@yahoo.com Tue Dec 4 01:28:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F43821F863F for ; Tue, 4 Dec 2012 01:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kse6ci+J0a6l for ; Tue, 4 Dec 2012 01:28:57 -0800 (PST) Received: from nm27-vm0.bullet.mail.bf1.yahoo.com (nm27-vm0.bullet.mail.bf1.yahoo.com [98.139.213.139]) by ietfa.amsl.com (Postfix) with ESMTP id 71D2C21F8630 for ; Tue, 4 Dec 2012 01:28:57 -0800 (PST) Received: from [98.139.212.147] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2012 09:28:56 -0000 Received: from [98.139.172.97] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2012 09:28:56 -0000 Received: from [127.0.0.1] by smtp120-mob.biz.mail.bf1.yahoo.com with NNFMP; 04 Dec 2012 09:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354613336; bh=AI5WS+lIUHJMQLYCZ93J8iMQHV11XE4FPIRcndoK7v4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=XyBAJ0KGrKkOEouZxCCyq9SfQgjSkCVx1Hqn5stN/7fRXE7Mg8Sqv8lZb5IyeY3jonnmaIH2cliDC3uWG6iQ0Z7Olfoa2F4OXUCLgQo8c3Jnrljqzt50WTyDBFlrC3Bzs7g4o8QwXltUw7ix8MSxyfhkG3PezwHecGWGs9/FPKM= X-Yahoo-Newman-Id: 871216.75173.bm@smtp120-mob.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HV5xY08VM1mIIs8pXQgqG8kj0cpf0MMaLacMWOUU1gejHYo zzz3VGl26dFqTEsugZlKzO.T93XlaHCFyQ9nNc7lSe_RHIBmL.gjavd.EajQ PjVPX.e8beZ2980HehifoxqVYCqmkzAVaOMyMSodYhJwY0PPzp1hj0RNAQAy jAnogab49M3fPHkrKRBY8i4AYm0GcNAUAaiBZ7G0DMOVWEb9QB2wPcp.KPvY LCh06kr6AJV1O_Dr8Plv1L0dF8.May__0V6cHLx.pZadrfsdWFdeT_nxuTIc yvJopSZkrH5t8tVg.lEsryZcXC6NVFhnQin0YF.Nk..rGBMoI9_RBJzkSRXv kuwkfc_Pcur5a6zwE0B4rephE0idkJawHU1w0YerL6m7cdjMMiczVOIP9k14 6gidbDIpDIAxxaHMoFRlHOaZzeutKP8Co82x4BdUo8Gx2H7muwmD6zql_NjD d3mhOCFCsO8w- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [192.168.0.104] (davarish@98.248.36.11 with xymcookie) by smtp120-mob.biz.mail.bf1.yahoo.com with SMTP; 04 Dec 2012 01:28:56 -0800 PST References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.br oadcom.com> <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> Mime-Version: 1.0 (1.0) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <98F14E8F-9AAC-4372-B322-C23D2AD0DDCE@yahoo.com> X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Tue, 4 Dec 2012 01:28:52 -0800 To: Rolf Winter Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:28:59 -0000 Hi Rolf, For in-MIP a single bit is enough. However for out-MIP the CPU has to drop t= he unwanted OAM. Not efficient but the system still works. Remember this hap= pens only in a corner case of p2mp MPLS with multiple out-MIP on the same ro= uter, and when only root wants to talk to one of the leaves.=20 That's why I am suggesting to have a single bit in addition to the MEPID. Regards, Shahram On Dec 4, 2012, at 12:33 AM, Rolf Winter wrote: > Shahram, >=20 > what if it is configured and you only want to talk to one out of all the o= ut-MIPs. I guess we can all craft examples where we can make our point. A si= ngle bit simply does not guarantee you that the local CPU does not have to l= ook at the OAM frame to finally discard it. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: Shahram Davari [mailto:davari@broadcom.com] >> Sent: Dienstag, 4. Dezember 2012 01:53 >> To: hideki.endo.es@hitachi.com >> Cc: Rolf Winter; mpls@ietf.org >> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls- >> tp-mip-mep-map >>=20 >> Hi Hideki, >>=20 >> I think you need to look at my p-code. F a MIP is not configured in the >> Egress port, then that egress port won't sent the OAM packet to its >> processor and drops it. So there is no issue with my proposed method. >>=20 >> Thx >> Shahram >>=20 >> -----Original Message----- >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >> Sent: Monday, December 03, 2012 4:48 PM >> To: Shahram Davari >> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp- >> mip-mep-map >>=20 >> Hi Shahram, >>=20 >> First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and a >> MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing >> MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests >> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>=20 >> Second, you wrote; >> "The issue is that each CPU/processor has limited resources. >> By sending all OAM MIP packets to both processor you are losing 1/2 >> of the capacity of each processor. " >> It depends on implementations, >> and this issue could NOT be resolved by even your solution that uses >> ACH header to indicate in/out-MIP. >> Let's consider P2MP case as you pointed out. >> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >> This means that the OAM processor at port D loses its capacity. >> If we consider the larger number of ports in the LSR which has 100 >> ports, for example, All OAM MIP packets for out-MIPs port(B, C) are >> sent to all out-MIPs. >> This means that the OAM processors at the other 98 ports lose those >> capacities. >> Even if your solution using ACH header is applied, it can reduce OAM >> packets only for in-MIP, which means only 1/101 effectiveness in the >> case of P2MP for 100 ports. >>=20 >> Thanks, >> Hideki Endo >>=20 >>=20 >>> Rolf, >>>=20 >>> For clarity it is better to use an example. Assume that an LSR has 4 >> ports (A, B, C, D). Now assume that it receives packets on a unicast >> LSP-X from port A and forwards them to port B. there can only be 3 >> configurations: >>>=20 >>> 1) MIP on port A (In-MIP), or >>> 2) MIP on port B (out-MIP), or >>> 3) MEIP on Port A and B >>>=20 >>> A single OAM packet can be terminated and processed only by one of >> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport= >> B). In your example, you are saying send a copy of the P to the >> CPU/Processor on Port A, and send a copy also to CPU/Processor on Port >> B. Port A CPU will drop the packet since the MIP-ID is not A. The >> issue is that each CPU/processor has limited resources. By sending all >> OAM MIP packets to both processor you are losing 1/2 of the capacity of >> each processor. The practical solution is to have a simple indicator >> in the packet header that this OAM packet is meant for Out-MIP. Then >> port A just switches the OAM packet to Port B, and Port B terminates >> and sends it to its CPU/processor. >>>=20 >>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the >> chip from Port A and is sent to ports B, C, D. Also assume that there >> is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a >> Multicast OAM packet is meant for out-MIPs (B, C). In such case the >> OAM packet should not be sent to port A CPU/Processor. It is therefore >> multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. >> Port D drops the OAM packets and does not send it to its CPU, since >> there is no MIP configured for that MPLS label. >>>=20 >>> So the Pseudo-code is like this: >>>=20 >>> Ingress Port: >>>=20 >>> If packet is OAM and TTL=3D1 >>> If MIP is enabled >>> If packet indicates In-MIP >>> Send to local CPU >>> Else >>> Forward to egress port >>> End >>> Else >>> Forward normally >>> End >>> Else >>>=20 >>> Egress Port: >>>=20 >>> If packet is OAM and TTL=3D1 >>> If MIP is enabled >>> If packet indicates In-MIP >>> Drop packet >>> Else If packet indicates Out-MIP >>> Send to local CPU >>> End >>> Else >>> Drop packet >>> End >>> End >>>=20 >>>=20 >>> Using this example could you please describe your reasoning for not >> requiring HW to identify In-MEP vs out-MIPs? >>>=20 >>> Thanks >>> Shahram >>>=20 >>> -----Original Message----- >>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>> Sent: Monday, December 03, 2012 12:10 PM >>> To: Shahram Davari >>> Cc: Pablo Frank; mpls@ietf.org >>> Subject: RE: [mpls] working group last call on >>> draft-ietf-mpls-tp-mip-mep-map >>>=20 >>> But the MIP that is addressed needs to be able to handle this _plus_ >> take an appropriate action and in the P2MP case this will always be the >> case since there are 2 or more out MIPs. >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>> Sent: Montag, 3. Dezember 2012 16:27 >>>> To: Rolf Winter >>>> Cc: Pablo Frank; mpls@ietf.org >>>> Subject: Re: [mpls] working group last call on >>>> draft-ietf-mpls-tp-mip- mep-map >>>>=20 >>>> Hi Rolf, >>>>=20 >>>> Your HW guys are correct as long as the amount of data sent to the >>>> in- MIP processor is not much. But from your previous email to Loa I >>>> see that you want to also terminate CV at MIPs. CVs are fast and >> high >>>> bandwidth and blindly dumping them on a CPU or OAM processor that >>>> may not be expecting them is like DoS attack. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>> wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> sorry for the belated response. I checked with some of our HW >> people. >>>> Here's the gist of their response: >>>>>=20 >>>>> Of course they wouldn't like parsing TLVs but we established that >>>> fact already. Their answer to the problem is slightly different >> though. >>>> A TTL-expired OAM frame can simply be copied and forwarded to the >>>> out- MIPs where, if the frame is not intended for them, it can >> safely >>>> be dropped. In the P2MP case e.g. this needs to be done anyway, i.e. >>>> the implementation must behave in this exact way in either case. So >>>> there is at least one way to implement this at line rate without >>>> going back and changing a bunch of RFCs. >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Rolf >>>>>=20 >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>> Behalf Of Shahram Davari >>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>> To: Pablo Frank >>>>>> Cc: mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>=20 >>>>>> Pablo, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thx >>>>>> Shahram >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>> To: Shahram Davari >>>>>> Cc: mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I think Shahram raises a very legitimate concern about how >>>>>> expensive this could be to implement in hardware. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> As I understand it, the logic proposed by this draft is as >> follows: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At the ingress blade: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>=20 >>>>>> Parse MIP-ID TLV >>>>>>=20 >>>>>> Lookup MIP-ID >>>>>>=20 >>>>>> IF MIP-is-egress, THEN >>>>>>=20 >>>>>> forward normally (but note we must intercept it again on >>>> egress) >>>>>>=20 >>>>>> ELSE >>>>>>=20 >>>>>> punt to OAM processor >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> At the egress blade: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>=20 >>>>>> Parse MIP-ID TLV >>>>>>=20 >>>>>> Lookup MIP-ID >>>>>>=20 >>>>>> IF MIP-is-egress, THEN >>>>>>=20 >>>>>> punt to OAM processor >>>>>>=20 >>>>>> ELSE >>>>>>=20 >>>>>> drop >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Note all this has to be done in the fast-path now at full line >>>>>> rate (and hardware guys hate TLVs). Before, the only thing the >>>>>> fast-path had to do was look for TTL-expiry. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The only reason that ACH reserved bit was rejected (in Appendix >>>>>> A.4 of >>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>> Ideally, hardware could rely on the reserved bit to do the >> initial >>>>>> filtering at full line-rate and then a presumably much more >>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>> modification to TTL handling and the OAM block does the heavy >>>> lifting of dealing with ACH TLVs, etc. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This seems like a case where practicality should trump elegance. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> regards, >>>>>>=20 >>>>>> Pablo >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Rolf, >>>>>>>=20 >>>>>>> I am sure you know that TLVs are not Hardware friendly. And >> I >>>>>> think you agree with me that this draft requires deep parsing of >>>>>> all packets at line rate to get to the MIPID TLV. >>>>>>>=20 >>>>>>> I still think the MIPID TLV is required to decide whether an >>>> OAM >>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>> could be augmented to decide between In-MIP and Out-MIP. For >>>>>> example how about using one of the reserved bits in the ACH >>>>>> header. This >>>> can >>>>>> easily be done in hardware with minimum complexity. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Shahram >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >> On >>>>>> Behalf Of Rolf Winter >>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>> Cc: mpls@ietf.org >>>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls- tp-mip-mep-map >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>>> Hi Adrian, >>>>>>>>=20 >>>>>>>> You are right and I should have sent these types of >> comments >>>>>> before >>>>>>>> last call. I completely understand the procedure. >>>>>>>>=20 >>>>>>>> One thing I didn't understand in your response is that you >>>> said >>>>>> in-MIP >>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>> that? >>>>>>>>=20 >>>>>>>> My understanding is that before this draft, the process >>>>>> would have >>>>>>>> been for the ingress to look at TTL and if it is expired >>>>>> then send the >>>>>>>> packet to OAM processor. >>>>>>>=20 >>>>>>> Yes (and no). While I assume likely MIP functionality will >> be >>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>> (RFC >>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an >>>>>> unspecified location within the node)". >>>>>>>=20 >>>>>>> Also, I think "before this draft" is not quite accurate in >>>>>> that is suggests there is no per-interface MIP addressing >> possible >>>>>> as of >>>> now. >>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>> We >>>>>> cannot really go back and change all this. There are other >>>> constraints. >>>>>> E.g. we have a requirement to address a single out-MIP out of a >>>>>> set of out-MIPs on a P2MP branch point. So this was part of the >>>>>> constraints we worked with. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>> filtering >>>>>>>> out leaked OAM frames from upstream. But lets leave lookup >>>>>> of the MEPID >>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>> indicator to >>>>>>>> the OAM packet to indicate whether it should be taken out >> of >>>>>> the data >>>>>>>> path in the Ingress or egress. >>>>>>>>=20 >>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>=20 >>>>>>>> " In addition to the MEPID, which is used to ultimately >>>>>> accept or >>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>> simple >>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>> in-MIP or >>>>>>>> Out-MIP". >>>>>>>=20 >>>>>>> We also have the question on where to retrofit those bits. I >>>>>> assume a TLV wouldn't work for the exact reasons you do not like >>>>>> to have to do a second lookup, since it would require some >>>>>> parsing. All these constraints and the ones outlined in the >>>>>> document led to where we are. In a sense this is a non-spec since >>>>>> it rather rules out a number of things that seem like a good idea >>>>>> at first but then have a catch of some sort. >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Rolf >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Shahram >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> >>>>>>>>>=20 >>>>>>>>> Hi Shahram, >>>>>>>>>=20 >>>>>>>>> I am worried about the precedent of a comment like this >>>> during >>>>>> WG >>>>>>>> last call. >>>>>>>>> While comments that improve the document or point out >>>>>> fundamental >>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>> flavour "I >>>>>>>>> wouldn't have done it like this" that arrive this late in >>>>>> the process >>>>>>>> don't feel very constructive. >>>>>>>>> But I will leave the chair to worry about process and try >>>>>> to address >>>>>>>>> the technical points... >>>>>>>>>=20 >>>>>>>>>> Identifying whether to terminate an OAM packet and >> process >>>> it >>>>>> in In- >>>>>>>> MIP vs. >>>>>>>>> Out- >>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet >>>>>> will not >>>>>>>> take >>>>>>>>>> the same path as data packets. Therefore any MIP >>>>>> identifier that is >>>>>>>>>> proposed in this >>>>>>>>> draft >>>>>>>>>> requires one extra lookup and therefore adds >> significantly >>>> to >>>>>> cost. >>>>>>>>>=20 >>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>> decide to >>>>>>>>> implement out-MIPs, and if you want the OAM to follow >>>>>> exactly the >>>>>>>> same >>>>>>>>> path as the data, then it is a requirement that the out >>>>>> interface >>>>>>>>> inspects the packets (at line >>>>>>>>> rate) to determine whether they are OAM and targeted at >> the >>>>>> interface. >>>>>>>>>=20 >>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>> the >>>>>> lookup >>>>>>>>> as easy as possible. >>>>>>>>>=20 >>>>>>>>>> Perhaps a >>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>> Level) may be >>>>>>>>>> used that requires only 3 bits and achieves the same >> result. >>>>>>>>>=20 >>>>>>>>> Perhaps it could. >>>>>>>>> But before going there, why is the lookup in the current >>>>>> version of >>>>>>>>> the I-D arduous? >>>>>>>>>=20 >>>>>>>>> Presumably you do not propose making any change to the way >>>>>> In-MIPs >>>>>>>> are >>>>>>>>> currently identified, so the lookups being done at line >>>>>> rate today on >>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>> proposing >>>>>>>> such >>>>>>>>> a change, then the discussion is outside the scope of this >>>>>> I- D and >>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>=20 >>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>> lookup on >>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>> both >>>>>>>>> interfaces. My assumption was that if the incoming >>>>>> interface can do >>>>>>>>> the lookup at line rate, it is not hard to perform the >> same >>>>>> lookup on >>>>>>>>> the outgoing interface. Furthermore, there is a reduction >> in >>>>>>>> complexity by having fewer things to look up. >>>>>>>>>=20 >>>>>>>>> Another possibility is that the full lookup could be done >>>>>> on the >>>>>>>>> incoming interface and the packet marked for easy >>>> interception >>>>>> on the >>>>>>>> outgoing interface. >>>>>>>>> The concern with this approach is that the packet would no >>>>>> longer be >>>>>>>>> being forwarded exactly as data because it would be being >>>>>> modified in >>>>>>>> flight. >>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>> the >>>>>> packet >>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>> needed. >>>>>>>>>=20 >>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>> progressed, >>>>>>>>> and some of the alternative solutions were tracked with >>>>>> their pros >>>>>>>> and >>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Adrian >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls- >> bounces@ietf.org] >>>> On >>>>>> Behalf >>>>>>>>>> Of Adrian Farrel >>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>> ; >>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>=20 >>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>> anything >>>>>>>> else? >>>>>>>>>>=20 >>>>>>>>>> The point was that when I started the I-D lots of people >>>> were >>>>>> saying >>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>> backward >>>>>>>> compatible". >>>>>>>>>>=20 >>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>=20 >>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>> ; MPLS-TP ad >>>>>>>>>>> hoc >>>>>>>>> team; >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>=20 >>>>>>>>>>> After getting to section 6 and its features >>>>>> (requirements!), I find >>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it >> is >>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>=20 >>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>=20 >>>>>>>>>>> Title >>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>> [Handling >>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a >> more >>>>>>>>>>> informative statement unless and until you get to the >>>>>> definition of >>>>>>>>>>> Internal in s3; and s6, which is the crux of the >> document >>>>>> says The >>>>>>>>>>> preferred solution to per-interface MIP message handling >> is >>>>>>>>>>> presented in this section] >>>>>>>>>>>=20 >>>>>>>>>>> s1 >>>>>>>>>>> two (or more) MIPs per node on both sides of the >>>>>> forwarding engine. >>>>>>>>>>> [two on both sides sounds like four in total to me; >>>>>> suggest 'one on >>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>=20 >>>>>>>>>>> s4 >>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>=20 >>>>>>>>>>> s5 >>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] >>>>>> for MPLS-TP >>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>> precedents, >>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>> for >>>>>> LSPs, >>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>> sentence >>>>>> as >>>>>>>>>>> redundant] >>>>>>>>>>>=20 >>>>>>>>>>> s6 >>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>> few solutions that the authors have discarded which >> have >>>>>> been >>>>>>>> left in >>>>>>>>>>> the document for informational purposes. >>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>=20 >>>>>>>>>>> The node itself is addresses >>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>=20 >>>>>>>>>>> The identification information indside [The >> identification >>>>>>>>>>> information inside ] >>>>>>>>>>>=20 >>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>=20 >>>>>>>>>>> reserved MIP address >>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>=20 >>>>>>>>>>> Tom Petch >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>> To: >>>>>>>>>>> Cc: ; >>>>> chairs@tools.ietf.org>; >>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>> >>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>=20 >>>>>>>>>>>> Working Group, >>>>>>>>>>>>=20 >>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>=20 >>>>>>>>>>>> Please send your comments to the mpls working group >>>> mailing >>>>>> list >>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>=20 >>>>>>>>>>>> Please send both technical comments, and if you are >>>>>> happy with the >>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>=20 >>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>=20 >>>>>>>>>>>> /Loa >>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>=20 >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 >> Victoria >>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Tue Dec 4 01:33:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1F21F8602 for ; Tue, 4 Dec 2012 01:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggnAvXKK4XPs for ; Tue, 4 Dec 2012 01:33:29 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 903F521F84FD for ; Tue, 4 Dec 2012 01:33:29 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 01:28:54 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 01:31:27 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 01:31:06 -0800 From: "Shahram Davari" To: "Rolf Winter" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eJMrDrf0hTkh0+f0Jf1wk5ixZgI2e+A//+Gd40= Date: Tue, 4 Dec 2012 09:31:05 +0000 Message-ID: <86E44E2B-5306-49D7-BA75-BAE914E8B031@broadcom.com> References: <5098CF68.2000105@pi.nu> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA31DC739W4993986-13-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:33:30 -0000 How about the G-ACH TLV that immediately follows ACH.=20 Regards, Shahram On Dec 4, 2012, at 12:46 AM, "Rolf Winter" wrote: > Hi, >=20 > quite some time ago we asked whether we could mandate TLV ordering (at le= ast mandating one out of N TLVs to be the first in the OAM PDU) in order to= allow efficient implementation in HW. This actually would be a good thing = in this case. The responses we got weren't quite positive (which is actuall= y quite a positive description of the responses we got) but I don't see tha= t the GACh RFC is actually disallowing it. Still we would need to go back a= nd make changes to a few RFCs. That was also something people weren't reall= y happy about. Again, these were some of the constraints we worked with whi= ch led to what is on the table right now. We weren't blind to HW considerat= ions, vice versa as you can see when you look at the appendix that was remo= ved in the latest version of the document. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Londo= n W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: Puneet Agarwal [mailto:pagarwal@broadcom.com] >> Sent: Dienstag, 4. Dezember 2012 06:44 >> To: hideki.endo.es@hitachi.com >> Cc: Shahram Davari; Rolf Winter; mpls@ietf.org >> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip- >> mep-map >>=20 >> Hi hideki, >>=20 >> Is the determination that the mip identifier is present in the same >> location always in the pdu or is it variable (based on oam msg type)? >>=20 >> Thx >>=20 >> Puneet >>=20 >>=20 >>=20 >> On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" >> wrote: >>=20 >>> draft-ietf-mpls-tp-mip-mep-map >=20 >=20 From davari@broadcom.com Tue Dec 4 01:33:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0DB21F86EE for ; Tue, 4 Dec 2012 01:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.318 X-Spam-Level: X-Spam-Status: No, score=-5.318 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQkTi4xSw1jK for ; Tue, 4 Dec 2012 01:33:57 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id E45F621F86DE for ; Tue, 4 Dec 2012 01:33:57 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 01:28:54 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 01:32:47 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 01:32:26 -0800 From: "Shahram Davari" To: "hideki.endo.es@hitachi.com" Thread-Topic: [mpls] working group last callondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0gJEhFwWW7HCs0W23otaynE9Lg== Date: Tue, 4 Dec 2012 09:32:25 +0000 Message-ID: References: <5098CF68.2000105@pi.nu> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA31DC739W4993986-17-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last callondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 09:34:00 -0000 I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU. Regards, Shahram On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" wrote: > Sharhram, >=20 > I didn't mean new requirement similar to Figure 7. > I do think that OAM packets must go through the normal forwarding engine > without bypass. >=20 > As Rolf said in other e-mail, > -------------------------- > | -----| > | | MIP1| > | ->-| |->---- > | | | Out | > | | | i/f | > | | -----| > |----- | -----| > | MIP0| ---- | | MIP2| > | | | |- | | > ----->-| In |->-| FW |--->-| Out |->---- > | i/f | | |- | i/f | > |----- ---- | -----| > | | -----| > | | | MIP3| > | | | | > | ->-| Out |->---- > | | i/f | > | -----| > -------------------------- > The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in = the P2MP tree individually. > Here, each out-MIP has different MIP ID. > If you don't need this machanism, > how does a out-MIP verify whether the OAM packet is sent to the out-MIP o= r not?=20 >=20 > Thanks, > Hideki Endo >=20 >=20 >> Hideki, >>=20 >> In summary your requirement is similar to Figure 7 , where you are going= to bypass the normal forwarding engine and do unicast forwarding of a mul= ticast OAM packet to a single outgoing port. This kind of behavior is ex= plicitly rejected in the draft. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: >>=20 >>> Hi Hideki, >>>=20 >>> I think we have a fundamental problem statement difference. Based on yo= ur examples I think you are looking in to how to send an OAM packet only to= a single out-MIP out of Nxout-MIPs in a P2MP LSP. >>>=20 >>> But I don't think this is architecturally sound or even required. Imagi= ne there is no in-MIP at all. We want a multicast OAM packet behaves like a= data packet and be replicated to all egress ports. Now if a MIP is configu= red in say 2 of the egress ports and not the other 98 ones, then the 98 egr= ess ports will drop the OAM packet in HW and won't send them to their CPU. = For the other 2 ports with Out-MIP, both will send the packets to their CPU= and both CPUs have to process and respond such as with link trace reply or= Loopback reply, etc. >>>=20 >>>=20 >>> Regards, >>> Shahram >>>=20 >>>=20 >>> On Dec 3, 2012, at 5:24 PM, wrote: >>>=20 >>>> Hi Shahram, >>>>=20 >>>> Back and forth. >>>> Here, let's focus on whether using MIP ID requires unnecessarily parsi= ng in HW or not. >>>>=20 >>>>> I think you need to look at my p-code. F a MIP is not configured in t= he Egress port, then that egress port won't sent the OAM packet to its proc= essor and drops it. So there is no issue with my proposed method. >>>> Don't you consider the case when MIPs is configured in the Egress port= B,C and D? >>>> In the case of P2MP, we need to identify the only one out-MIP of these= out-MIPs in port B,C and D. >>>> In that case, your solution has low effectiveness as I pointed out. >>>> Do I miss something? >>>>=20 >>>> Thanks, >>>> Hideki Endo >>>>=20 >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Using MIP ID as the only method to filter OAM packets to CPU/Processo= r is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 = LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP = ID as the only identifier requires unnecessarily parsing of all these diffe= rent packet types at line rate in HW. >>>>>=20 >>>>> Why not just use a simple bit in the ACH header? We need a n indicato= r in a fixed location or the solution is not going to be practical in HW. >>>>>=20 >>>>> Thanks, >>>>> Shahram >>>>>=20 >>>>> -----Original Message----- >>>>> From: Shahram Davari=20 >>>>> Sent: Monday, December 03, 2012 4:53 PM >>>>> To: 'hideki.endo.es@hitachi.com' >>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls= -tp-mip-mep-map >>>>>=20 >>>>> Hi Hideki, >>>>>=20 >>>>> I think you need to look at my p-code. F a MIP is not configured in t= he Egress port, then that egress port won't sent the OAM packet to its proc= essor and drops it. So there is no issue with my proposed method. >>>>>=20 >>>>> Thx >>>>> Shahram >>>>>=20 >>>>> -----Original Message----- >>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com]= =20 >>>>> Sent: Monday, December 03, 2012 4:48 PM >>>>> To: Shahram Davari >>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-= mip-mep-map >>>>>=20 >>>>> Hi Shahram, >>>>>=20 >>>>> First, as Rolf sent, we need in/out-MIP for >>>>> 1. CV between a MEP and a MIP >>>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIP= s >>>>> 3. data-plane loopback configuration at a MIP >>>>> 4. diagnostic tests >>>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>>>=20 >>>>> Second, you wrote; >>>>> "The issue is that each CPU/processor has limited resources.=20 >>>>> By sending all OAM MIP packets to both processor you are=20 >>>>> losing 1/2 of the capacity of each processor. " >>>>> It depends on implementations, >>>>> and this issue could NOT be resolved by even your solution that uses = ACH header to indicate in/out-MIP. >>>>> Let's consider P2MP case as you pointed out. >>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>> This means that the OAM processor at port D loses its capacity. >>>>> If we consider the larger number of ports in the LSR which has 100 po= rts, for example, >>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>> This means that the OAM processors at the other 98 ports lose those c= apacities. >>>>> Even if your solution using ACH header is applied, >>>>> it can reduce OAM packets only for in-MIP, which means only 1/101 eff= ectiveness >>>>> in the case of P2MP for 100 ports. >>>>>=20 >>>>> Thanks, >>>>> Hideki Endo >>>>>=20 >>>>>=20 >>>>>> Rolf, >>>>>>=20 >>>>>> For clarity it is better to use an example. Assume that an LSR has 4= ports (A, B, C, D). Now assume that it receives packets on a unicast LSP= -X from port A and forwards them to port B. there can only be 3 configura= tions: >>>>>>=20 >>>>>> 1) MIP on port A (In-MIP), or >>>>>> 2) MIP on port B (out-MIP), or >>>>>> 3) MEIP on Port A and B >>>>>>=20 >>>>>> A single OAM packet can be terminated and processed only by one of t= hese MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport B)= . In your example, you are saying send a copy of the P to the CPU/Processor= on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU wil= l drop the packet since the MIP-ID is not A. The issue is that each CPU/pr= ocessor has limited resources. By sending all OAM MIP packets to both proc= essor you are losing 1/2 of the capacity of each processor. The practical = solution is to have a simple indicator in the packet header that this OAM p= acket is meant for Out-MIP. Then port A just switches the OAM packet to Por= t B, and Port B terminates and sends it to its CPU/processor. >>>>>>=20 >>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the= chip from Port A and is sent to ports B, C, D. Also assume that there is = In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multica= st OAM packet is meant for out-MIPs (B, C). In such case the OAM packet sh= ould not be sent to port A CPU/Processor. It is therefore multicast to port= s B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OA= M packets and does not send it to its CPU, since there is no MIP configured= for that MPLS label. >>>>>>=20 >>>>>> So the Pseudo-code is like this: >>>>>>=20 >>>>>> Ingress Port: >>>>>>=20 >>>>>> If packet is OAM and TTL=3D1 >>>>>> If MIP is enabled >>>>>> If packet indicates In-MIP >>>>>> Send to local CPU >>>>>> Else >>>>>> Forward to egress port >>>>>> End >>>>>> Else >>>>>> Forward normally >>>>>> End >>>>>> Else >>>>>>=20 >>>>>> Egress Port: >>>>>>=20 >>>>>> If packet is OAM and TTL=3D1 >>>>>> If MIP is enabled >>>>>> If packet indicates In-MIP >>>>>> Drop packet >>>>>> Else If packet indicates Out-MIP >>>>>> Send to local CPU >>>>>> End >>>>>> Else >>>>>> Drop packet >>>>>> End >>>>>> End >>>>>>=20 >>>>>>=20 >>>>>> Using this example could you please describe your reasoning for not = requiring HW to identify In-MEP vs out-MIPs? >>>>>>=20 >>>>>> Thanks >>>>>> Shahram >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >>>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>>> To: Shahram Davari >>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mi= p-mep-map >>>>>>=20 >>>>>> But the MIP that is addressed needs to be able to handle this _plus_= take an appropriate action and in the P2MP case this will always be the ca= se since there are 2 or more out MIPs. >>>>>>=20 >>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>>> To: Rolf Winter >>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-m= ip- >>>>>>> mep-map >>>>>>>=20 >>>>>>> Hi Rolf, >>>>>>>=20 >>>>>>> Your HW guys are correct as long as the amount of data sent to the = in- >>>>>>> MIP processor is not much. But from your previous email to Loa I se= e >>>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that = may >>>>>>> not be expecting them is like DoS attack. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Shahram >>>>>>>=20 >>>>>>>=20 >>>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> sorry for the belated response. I checked with some of our HW peop= le. >>>>>>> Here's the gist of their response: >>>>>>>>=20 >>>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>>> fact already. Their answer to the problem is slightly different tho= ugh. >>>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the o= ut- >>>>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. t= he >>>>>>> implementation must behave in this exact way in either case. So the= re >>>>>>> is at least one way to implement this at line rate without going ba= ck >>>>>>> and changing a bunch of RFCs. >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Rolf >>>>>>>>=20 >>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= , >>>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Beh= alf >>>>>>>>> Of Shahram Davari >>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>>> To: Pablo Frank >>>>>>>>> Cc: mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>=20 >>>>>>>>> Pablo, >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thx >>>>>>>>> Shahram >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>>> To: Shahram Davari >>>>>>>>> Cc: mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I think Shahram raises a very legitimate concern about how expens= ive >>>>>>>>> this could be to implement in hardware. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> As I understand it, the logic proposed by this draft is as follow= s: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> At the ingress blade: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>=20 >>>>>>>>> Parse MIP-ID TLV >>>>>>>>>=20 >>>>>>>>> Lookup MIP-ID >>>>>>>>>=20 >>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>=20 >>>>>>>>> forward normally (but note we must intercept it again on >>>>>>> egress) >>>>>>>>>=20 >>>>>>>>> ELSE >>>>>>>>>=20 >>>>>>>>> punt to OAM processor >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> At the egress blade: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>=20 >>>>>>>>> Parse MIP-ID TLV >>>>>>>>>=20 >>>>>>>>> Lookup MIP-ID >>>>>>>>>=20 >>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>=20 >>>>>>>>> punt to OAM processor >>>>>>>>>=20 >>>>>>>>> ELSE >>>>>>>>>=20 >>>>>>>>> drop >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Note all this has to be done in the fast-path now at full line ra= te >>>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-p= ath >>>>>>>>> had to do was look for TTL-expiry. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A= .4 >>>>>>>>> of >>>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>>> Ideally, hardware could rely on the reserved bit to do the initia= l >>>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup= . >>>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> regards, >>>>>>>>>=20 >>>>>>>>> Pablo >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Rolf, >>>>>>>>>>=20 >>>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>>> think you agree with me that this draft requires deep parsing of = all >>>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>>>=20 >>>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>>> OAM >>>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For exam= ple >>>>>>>>> how about using one of the reserved bits in the ACH header. This >>>>>>> can >>>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Shahram >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>>> Behalf Of Rolf Winter >>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>>>> tp-mip-mep-map >>>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>>> Hi Adrian, >>>>>>>>>>>=20 >>>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>>> before >>>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>>=20 >>>>>>>>>>> One thing I didn't understand in your response is that you >>>>>>> said >>>>>>>>> in-MIP >>>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>>> that? >>>>>>>>>>>=20 >>>>>>>>>>> My understanding is that before this draft, the process would >>>>>>>>> have >>>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>>> send the >>>>>>>>>>> packet to OAM processor. >>>>>>>>>>=20 >>>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>>> (RFC >>>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecifi= ed >>>>>>>>> location within the node)". >>>>>>>>>>=20 >>>>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>>>> is suggests there is no per-interface MIP addressing possible as = of >>>>>>> now. >>>>>>>>> Take RFC 6426. In practice this is where part of the problem lies= . >>>>>>> We >>>>>>>>> cannot really go back and change all this. There are other >>>>>>> constraints. >>>>>>>>> E.g. we have a requirement to address a single out-MIP out of a s= et >>>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>>> constraints we worked with. >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>>> filtering >>>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>>> the MEPID >>>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>>> indicator to >>>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>>> the data >>>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>>=20 >>>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>>=20 >>>>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>>>> or >>>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>>> simple >>>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>>> in-MIP or >>>>>>>>>>> Out-MIP". >>>>>>>>>>=20 >>>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like = to >>>>>>>>> have to do a second lookup, since it would require some parsing. = All >>>>>>>>> these constraints and the ones outlined in the document led to wh= ere >>>>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>>>> number of things that seem like a good idea at first but then hav= e a >>>>>>>>> catch of some sort. >>>>>>>>>>=20 >>>>>>>>>> Best, >>>>>>>>>>=20 >>>>>>>>>> Rolf >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Shahram >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Shahram, >>>>>>>>>>>>=20 >>>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>>> during >>>>>>>>> WG >>>>>>>>>>> last call. >>>>>>>>>>>> While comments that improve the document or point out >>>>>>>>> fundamental >>>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>>> flavour "I >>>>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>>>> process >>>>>>>>>>> don't feel very constructive. >>>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>>> address >>>>>>>>>>>> the technical points... >>>>>>>>>>>>=20 >>>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>>> it >>>>>>>>> in In- >>>>>>>>>>> MIP vs. >>>>>>>>>>>> Out- >>>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>>>> not >>>>>>>>>>> take >>>>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>>>> that is >>>>>>>>>>>>> proposed in this >>>>>>>>>>>> draft >>>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>>> to >>>>>>>>> cost. >>>>>>>>>>>>=20 >>>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>>> decide to >>>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>>>> the >>>>>>>>>>> same >>>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>>> interface >>>>>>>>>>>> inspects the packets (at line >>>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>>> interface. >>>>>>>>>>>>=20 >>>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>>> the >>>>>>>>> lookup >>>>>>>>>>>> as easy as possible. >>>>>>>>>>>>=20 >>>>>>>>>>>>> Perhaps a >>>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>>> Level) may be >>>>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>>>=20 >>>>>>>>>>>> Perhaps it could. >>>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>>> version of >>>>>>>>>>>> the I-D arduous? >>>>>>>>>>>>=20 >>>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>>> In-MIPs >>>>>>>>>>> are >>>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>>> today on >>>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>>> proposing >>>>>>>>>>> such >>>>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>>>> D and >>>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>>=20 >>>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>>> lookup on >>>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>>> both >>>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>>> can do >>>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>>> lookup on >>>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>>=20 >>>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>>> the >>>>>>>>>>>> incoming interface and the packet marked for easy >>>>>>> interception >>>>>>>>> on the >>>>>>>>>>> outgoing interface. >>>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>>> longer be >>>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>>> modified in >>>>>>>>>>> flight. >>>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>>> the >>>>>>>>> packet >>>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>>> needed. >>>>>>>>>>>>=20 >>>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>>> progressed, >>>>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>>>> pros >>>>>>>>>>> and >>>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Adrian >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>>> On >>>>>>>>> Behalf >>>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>> ; >>>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>>> anything >>>>>>>>>>> else? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>>> were >>>>>>>>> saying >>>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>>> backward >>>>>>>>>>> compatible". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>>> hoc >>>>>>>>>>>> team; >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>>>> I find >>>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Title >>>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>>> [Handling >>>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>>> definition of >>>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>>> says The >>>>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> s1 >>>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>>>> engine. >>>>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>>>> 'one on >>>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> s4 >>>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> s5 >>>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>>>> MPLS-TP >>>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>>> precedents, >>>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>>> for >>>>>>>>> LSPs, >>>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>>> sentence >>>>>>>>> as >>>>>>>>>>>>>> redundant] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> s6 >>>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>>> been >>>>>>>>>>> left in >>>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>>> To: >>>>>>>>>>>>>> Cc: ; >>>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>>> mailing >>>>>>>>> list >>>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>>> with the >>>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>=20 >>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >=20 From loa@pi.nu Tue Dec 4 02:13:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391EB21F8909 for ; Tue, 4 Dec 2012 02:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNluFWdS9lsg for ; Tue, 4 Dec 2012 02:13:51 -0800 (PST) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0464F21F893B for ; Tue, 4 Dec 2012 02:13:50 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 712A282388; Tue, 4 Dec 2012 11:13:46 +0100 (CET) Message-ID: <50BDCCD3.4030803@pi.nu> Date: Tue, 04 Dec 2012 11:13:39 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> In-Reply-To: <50A3B5C0.4060203@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" Subject: [mpls] Extended - Re: working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 10:13:52 -0000 Working Group, since we have a discussion relating to to comments in this working group last call, the chairs will leave the wg last open until the end of this week. /Loa for the wg co-chairs On 2012-11-14 16:16, Loa Andersson wrote: > > Working Group, > > This is to start a 2 week working group last call on > draft-ietf-mpls-tp-mip-mep-map. > > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). > > Please send both technical comments, and if you are happy with the > document as is also indications of support. > > This working group last call will end on November 28. > > /Loa > for the wg co-chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From stbryant@cisco.com Tue Dec 4 02:27:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36BF21F86FC for ; Tue, 4 Dec 2012 02:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRCx-1cpJxdC for ; Tue, 4 Dec 2012 02:27:45 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A550F21F86F4 for ; Tue, 4 Dec 2012 02:27:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2304; q=dns/txt; s=iport; t=1354616864; x=1355826464; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=HNCDuYt7PUasP2xO9Wl0uWDIK/Si6blcANG2+6B0Mqg=; b=hHfhiUQ9dYDgVbpXSkPn83/RqcJetMVuGTbvl2s2cZCYxbRvsY8/fR+Y XcXKbs8z9fTXSnBpEg2NDdcP4Keh4WcQ+sZ+o9Jp8Ssu9OuD5WNBwbJCr oTIB4jzeh/Cl02Hmu+giYvHGtHyJWg7Dmd2hyiM01NXKOSwqwo9wBdWmX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACzPvVCQ/khN/2dsb2JhbABEvjMWc4IeAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgMDK5mkFeMQBUEgQGDJwOSUIMykEeCcoFj X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="10128404" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 04 Dec 2012 10:27:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB4ARhUN023107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2012 10:27:43 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qB4ARfjW011926; Tue, 4 Dec 2012 10:27:42 GMT Message-ID: <50BDD01D.7060005@cisco.com> Date: Tue, 04 Dec 2012 10:27:41 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mpls@ietf.org References: <5098CF68.2000105@pi.nu> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> <86E44E2B-5306-49D7-BA75-BAE914E8B031@broadcom.com> In-Reply-To: <86E44E2B-5306-49D7-BA75-BAE914E8B031@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 10:27:45 -0000 No one liked those (for h/w reasons), so we never used them for any first generation OAM applications. If you look at the registry you will see that none have been defined. Stewart On 04/12/2012 09:31, Shahram Davari wrote: > How about the G-ACH TLV that immediately follows ACH. > > Regards, > Shahram > > > On Dec 4, 2012, at 12:46 AM, "Rolf Winter" wrote: > >> Hi, >> >> quite some time ago we asked whether we could mandate TLV ordering (at least mandating one out of N TLVs to be the first in the OAM PDU) in order to allow efficient implementation in HW. This actually would be a good thing in this case. The responses we got weren't quite positive (which is actually quite a positive description of the responses we got) but I don't see that the GACh RFC is actually disallowing it. Still we would need to go back and make changes to a few RFCs. That was also something people weren't really happy about. Again, these were some of the constraints we worked with which led to what is on the table right now. We weren't blind to HW considerations, vice versa as you can see when you look at the appendix that was removed in the latest version of the document. >> >> Best, >> >> Rolf >> >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >> >> >>> -----Original Message----- >>> From: Puneet Agarwal [mailto:pagarwal@broadcom.com] >>> Sent: Dienstag, 4. Dezember 2012 06:44 >>> To: hideki.endo.es@hitachi.com >>> Cc: Shahram Davari; Rolf Winter; mpls@ietf.org >>> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip- >>> mep-map >>> >>> Hi hideki, >>> >>> Is the determination that the mip identifier is present in the same >>> location always in the pdu or is it variable (based on oam msg type)? >>> >>> Thx >>> >>> Puneet >>> >>> >>> >>> On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" >>> wrote: >>> >>>> draft-ietf-mpls-tp-mip-mep-map >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Tue Dec 4 03:02:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D154721F86AC for ; Tue, 4 Dec 2012 03:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9BQYZDo3KmT for ; Tue, 4 Dec 2012 03:02:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A039A21F86AA for ; Tue, 4 Dec 2012 03:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4494; q=dns/txt; s=iport; t=1354618946; x=1355828546; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=Om5vHu9drImB8p4ehE/bdlfKDCKZ8+tX7bduEi2iqkQ=; b=irWvSz9UR4ALTl1XWG0oNjUb0Qmp0egUYL1JusrKWuWscA7ib6bdItt/ kEGesg0bDP5Okq2wdNCW1TcSoW5FSbUpzGdhK5eIAZ6wPPW6mYNbZfGoF o4OwYdXcnoaSMfTxElKrKaJYoPC3f/vENNapfrIqbEph+GD+tVgzr1wxV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GAEXXvVCQ/khL/2dsb2JhbABEjAuuTYNbFnOCHgEBAQMBeAEFCwsEFAkWDwkDAgECAUUGDQEHAQGIBgawQJBbjECEQQOWApBHgnI X-IronPort-AV: E=McAfee;i="5400,1158,6915"; a="147752735" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2012 11:02:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB4B2OLd000948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2012 11:02:24 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qB4B2Ka9013895; Tue, 4 Dec 2012 11:02:22 GMT Message-ID: <50BDD83C.8010209@cisco.com> Date: Tue, 04 Dec 2012 11:02:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lizhong Jin References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030900060500040905080206" Cc: mpls@ietf.org Subject: Re: [mpls] wg last call on ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:02:27 -0000 This is a multi-part message in MIME format. --------------030900060500040905080206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 23/10/2012 03:32, Lizhong Jin wrote: > > > > 2. For the "Ethernet Interface Parameters" application, is it > > allowed to apply GAP Request, Flush or Suppress message specified in > > [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC > address. > > Yes if it makes sense in your application. I can see that you might > > for example suppress the MAC address refresh and rely on your peer > > to over-ride the request if the address changed. > > > > I am not sure why this needs clarification since the Ethernet draft > > inherits the rules of the GAP protocol. > [Lizhong] in section 4, all the description is for application > "0x0001", while the request/suppress message in > [I-D.ietf-mpls-gach-adv] is for application "0x0000". > e.g, "This document defines a new GAP application, "Ethernet Interface > Parameters", to support the advertisement of Ethernet-specific > parameters associated with the sending interface." > It seems the procedure in section 4 only inherits the GAP message, but > not GAP application "0x0000". It would be good have some description > to say, the GAP application "0x0000" could be also applied to this draft. Lizhong How about if we add to the GAP draft (immediately before section 4.1) "Any application using the GAP inherits the ability to use facilities provide by Application 0x0000." Stewart --------------030900060500040905080206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 23/10/2012 03:32, Lizhong Jin wrote:
> 2. For the "Ethernet Interface Parameters" application, is it
> allowed to apply GAP Request, Flush or Suppress message specified in
> [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address.
> Yes if it makes sense in your application. I can see that you might
> for example suppress the MAC address refresh and rely on your peer
> to over-ride the request if the address changed.
>
> I am not sure why this needs clarification since the Ethernet draft
> inherits the rules of the GAP protocol.
[Lizhong] in section 4, all the description is for application "0x0001", while the request/suppress message in [I-D.ietf-mpls-gach-adv] is for application "0x0000".
e.g, "This document defines a new GAP application, "Ethernet Interface Parameters", to support the advertisement of Ethernet-specific parameters associated with the sending interface."
It seems the procedure in section 4 only inherits the GAP message, but not GAP application "0x0000". It would be good have some description to say, the GAP application "0x0000" could be also applied to this draft.
Lizhong

How about if we add to the GAP draft (immediately before section 4.1)

"Any application using the GAP inherits the ability to use facilities provide by Application 0x0000."

Stewart

 --------------030900060500040905080206-- From Rolf.Winter@neclab.eu Tue Dec 4 03:09:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3E21F85D5 for ; Tue, 4 Dec 2012 03:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSRWjbpMT52y for ; Tue, 4 Dec 2012 03:09:18 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9721F866F for ; Tue, 4 Dec 2012 03:09:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 32374102836; Tue, 4 Dec 2012 12:09:17 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWOt8hwSF8Ae; Tue, 4 Dec 2012 12:09:17 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 14115102785; Tue, 4 Dec 2012 12:09:07 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 12:08:58 +0100 From: Rolf Winter To: "stbryant@cisco.com" , "mpls@ietf.org" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eK+O4JEBXeB5UOt6q9GpTzxDZgIUb6Q///944CAAA/QgIAAGqEw Date: Tue, 4 Dec 2012 11:08:58 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55543BB8@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> <86E44E2B-5306-49D7-BA75-BAE914E8B031@broadcom.com> <50BDD01D.7060005@cisco.com> In-Reply-To: <50BDD01D.7060005@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:09:19 -0000 Right, but the reason was that the TLV can be anywhere, i.e. give more than= a single TLV in an OAM frame, there is no guarantee that the TLV will be t= he first, second, third... Even if you guarantee that the TLV will be the s= ay second TLV, there is no guarantee that the first will be of constant len= gth or always the same and so forth. This requires parsing of TLVs which ca= nnot practically be done in HW at line rate. I understand Shahram to ask fo= r an ID TLV to be required to always be the first TLV independent of the nu= mber of TLVs in an OAM frame. Reasons against this that I heard include: "w= e have never done that and will never do it", "this defeats the purpose of = TLVs which are designed with this flexibility", "this is a HW problem not a= protocol issue", "what if another TLV comes up that wants to be first too"= and others. Best, Rolf=20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Stewart Bryant > Sent: Dienstag, 4. Dezember 2012 11:28 > To: mpls@ietf.org > Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip- > mep-map >=20 > No one liked those (for h/w reasons), so we never used them for any > first generation OAM applications. If you look at the registry you will > see that none have been defined. >=20 > Stewart >=20 > On 04/12/2012 09:31, Shahram Davari wrote: > > How about the G-ACH TLV that immediately follows ACH. > > > > Regards, > > Shahram > > > > > > On Dec 4, 2012, at 12:46 AM, "Rolf Winter" > wrote: > > > >> Hi, > >> > >> quite some time ago we asked whether we could mandate TLV ordering > (at least mandating one out of N TLVs to be the first in the OAM PDU) > in order to allow efficient implementation in HW. This actually would > be a good thing in this case. The responses we got weren't quite > positive (which is actually quite a positive description of the > responses we got) but I don't see that the GACh RFC is actually > disallowing it. Still we would need to go back and make changes to a > few RFCs. That was also something people weren't really happy about. > Again, these were some of the constraints we worked with which led to > what is on the table right now. We weren't blind to HW considerations, > vice versa as you can see when you look at the appendix that was > removed in the latest version of the document. > >> > >> Best, > >> > >> Rolf > >> > >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >> London W3 6BL | Registered in England 2832014 > >> > >> > >>> -----Original Message----- > >>> From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > >>> Sent: Dienstag, 4. Dezember 2012 06:44 > >>> To: hideki.endo.es@hitachi.com > >>> Cc: Shahram Davari; Rolf Winter; mpls@ietf.org > >>> Subject: Re: [mpls] working group last call > >>> ondraft-ietf-mpls-tp-mip- mep-map > >>> > >>> Hi hideki, > >>> > >>> Is the determination that the mip identifier is present in the same > >>> location always in the pdu or is it variable (based on oam msg > type)? > >>> > >>> Thx > >>> > >>> Puneet > >>> > >>> > >>> > >>> On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" > >>> wrote: > >>> > >>>> draft-ietf-mpls-tp-mip-mep-map > >> > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Tue Dec 4 03:40:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23CD21F898B for ; Tue, 4 Dec 2012 03:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdSaDRK99e4X for ; Tue, 4 Dec 2012 03:40:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D983521F896F for ; Tue, 4 Dec 2012 03:40:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3F49F102838; Tue, 4 Dec 2012 12:40:39 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRFFXnzjJ0mz; Tue, 4 Dec 2012 12:40:39 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 1BF57102837; Tue, 4 Dec 2012 12:40:19 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 12:40:11 +0100 From: Rolf Winter To: "S. Davari" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0gIx/lNCVk4YY0ajo2c8PWxp5JgIg9qg Date: Tue, 4 Dec 2012 11:40:09 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55543BED@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.br oadcom.com> <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> <98F14E8F-9AAC-4372-B322-C23D2AD0DDCE@yahoo.com> In-Reply-To: <98F14E8F-9AAC-4372-B322-C23D2AD0DDCE@yahoo.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:40:45 -0000 Hi Sharam, that is not quite accurate. It will happen at all nodes at the same TTL dis= tance because also there the TTL will expire even if no out-MIP is addresse= d there. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: S. Davari [mailto:davarish@yahoo.com] > Sent: Dienstag, 4. Dezember 2012 10:29 > To: Rolf Winter > Cc: Shahram Davari; hideki.endo.es@hitachi.com; mpls@ietf.org > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- > mep-map >=20 > Hi Rolf, >=20 > For in-MIP a single bit is enough. However for out-MIP the CPU has to > drop the unwanted OAM. Not efficient but the system still works. > Remember this happens only in a corner case of p2mp MPLS with multiple > out-MIP on the same router, and when only root wants to talk to one of > the leaves. >=20 > That's why I am suggesting to have a single bit in addition to the > MEPID. >=20 > Regards, > Shahram >=20 >=20 > On Dec 4, 2012, at 12:33 AM, Rolf Winter wrote: >=20 > > Shahram, > > > > what if it is configured and you only want to talk to one out of all > the out-MIPs. I guess we can all craft examples where we can make our > point. A single bit simply does not guarantee you that the local CPU > does not have to look at the OAM frame to finally discard it. > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:davari@broadcom.com] > >> Sent: Dienstag, 4. Dezember 2012 01:53 > >> To: hideki.endo.es@hitachi.com > >> Cc: Rolf Winter; mpls@ietf.org > >> Subject: RE: Re:Re: [mpls] working group last call on > >> draft-ietf-mpls- tp-mip-mep-map > >> > >> Hi Hideki, > >> > >> I think you need to look at my p-code. F a MIP is not configured in > >> the Egress port, then that egress port won't sent the OAM packet to > >> its processor and drops it. So there is no issue with my proposed > method. > >> > >> Thx > >> Shahram > >> > >> -----Original Message----- > >> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] > >> Sent: Monday, December 03, 2012 4:48 PM > >> To: Shahram Davari > >> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org > >> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls- > tp- > >> mip-mep-map > >> > >> Hi Shahram, > >> > >> First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and > a > >> MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW > containing > >> MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic > >> tests Here, CV means On-demand CV. You may misunderstand as > Proactive CV. > >> > >> Second, you wrote; > >> "The issue is that each CPU/processor has limited resources. > >> By sending all OAM MIP packets to both processor you are losing 1/2 > >> of the capacity of each processor. " > >> It depends on implementations, > >> and this issue could NOT be resolved by even your solution that uses > >> ACH header to indicate in/out-MIP. > >> Let's consider P2MP case as you pointed out. > >> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. > >> This means that the OAM processor at port D loses its capacity. > >> If we consider the larger number of ports in the LSR which has 100 > >> ports, for example, All OAM MIP packets for out-MIPs port(B, C) are > >> sent to all out-MIPs. > >> This means that the OAM processors at the other 98 ports lose those > >> capacities. > >> Even if your solution using ACH header is applied, it can reduce OAM > >> packets only for in-MIP, which means only 1/101 effectiveness in the > >> case of P2MP for 100 ports. > >> > >> Thanks, > >> Hideki Endo > >> > >> > >>> Rolf, > >>> > >>> For clarity it is better to use an example. Assume that an LSR has > 4 > >> ports (A, B, C, D). Now assume that it receives packets on a > unicast > >> LSP-X from port A and forwards them to port B. there can only be 3 > >> configurations: > >>> > >>> 1) MIP on port A (In-MIP), or > >>> 2) MIP on port B (out-MIP), or > >>> 3) MEIP on Port A and B > >>> > >>> A single OAM packet can be terminated and processed only by one of > >> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID > >> =3Dport B). In your example, you are saying send a copy of the P to > the > >> CPU/Processor on Port A, and send a copy also to CPU/Processor on > >> Port B. Port A CPU will drop the packet since the MIP-ID is not A. > >> The issue is that each CPU/processor has limited resources. By > >> sending all OAM MIP packets to both processor you are losing 1/2 of > >> the capacity of each processor. The practical solution is to have a > >> simple indicator in the packet header that this OAM packet is meant > >> for Out-MIP. Then port A just switches the OAM packet to Port B, and > >> Port B terminates and sends it to its CPU/processor. > >>> > >>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters > the > >> chip from Port A and is sent to ports B, C, D. Also assume that > >> there is In-MIP on port A and out-MIPs of ports B, C (not D). Now > >> assume a Multicast OAM packet is meant for out-MIPs (B, C). In such > >> case the OAM packet should not be sent to port A CPU/Processor. It > is > >> therefore multicast to ports B, C, D. Ports B, C send the OAM packet > to their CPU. > >> Port D drops the OAM packets and does not send it to its CPU, since > >> there is no MIP configured for that MPLS label. > >>> > >>> So the Pseudo-code is like this: > >>> > >>> Ingress Port: > >>> > >>> If packet is OAM and TTL=3D1 > >>> If MIP is enabled > >>> If packet indicates In-MIP > >>> Send to local CPU > >>> Else > >>> Forward to egress port > >>> End > >>> Else > >>> Forward normally > >>> End > >>> Else > >>> > >>> Egress Port: > >>> > >>> If packet is OAM and TTL=3D1 > >>> If MIP is enabled > >>> If packet indicates In-MIP > >>> Drop packet > >>> Else If packet indicates Out-MIP > >>> Send to local CPU > >>> End > >>> Else > >>> Drop packet > >>> End > >>> End > >>> > >>> > >>> Using this example could you please describe your reasoning for not > >> requiring HW to identify In-MEP vs out-MIPs? > >>> > >>> Thanks > >>> Shahram > >>> > >>> -----Original Message----- > >>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] > >>> Sent: Monday, December 03, 2012 12:10 PM > >>> To: Shahram Davari > >>> Cc: Pablo Frank; mpls@ietf.org > >>> Subject: RE: [mpls] working group last call on > >>> draft-ietf-mpls-tp-mip-mep-map > >>> > >>> But the MIP that is addressed needs to be able to handle this > _plus_ > >> take an appropriate action and in the P2MP case this will always be > >> the case since there are 2 or more out MIPs. > >>> > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > >>> London W3 6BL | Registered in England 2832014 > >>> > >>> > >>>> -----Original Message----- > >>>> From: Shahram Davari [mailto:davari@broadcom.com] > >>>> Sent: Montag, 3. Dezember 2012 16:27 > >>>> To: Rolf Winter > >>>> Cc: Pablo Frank; mpls@ietf.org > >>>> Subject: Re: [mpls] working group last call on > >>>> draft-ietf-mpls-tp-mip- mep-map > >>>> > >>>> Hi Rolf, > >>>> > >>>> Your HW guys are correct as long as the amount of data sent to the > >>>> in- MIP processor is not much. But from your previous email to Loa > >>>> I see that you want to also terminate CV at MIPs. CVs are fast and > >> high > >>>> bandwidth and blindly dumping them on a CPU or OAM processor that > >>>> may not be expecting them is like DoS attack. > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> > >>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> sorry for the belated response. I checked with some of our HW > >> people. > >>>> Here's the gist of their response: > >>>>> > >>>>> Of course they wouldn't like parsing TLVs but we established that > >>>> fact already. Their answer to the problem is slightly different > >> though. > >>>> A TTL-expired OAM frame can simply be copied and forwarded to the > >>>> out- MIPs where, if the frame is not intended for them, it can > >> safely > >>>> be dropped. In the P2MP case e.g. this needs to be done anyway, > i.e. > >>>> the implementation must behave in this exact way in either case. > So > >>>> there is at least one way to implement this at line rate without > >>>> going back and changing a bunch of RFCs. > >>>>> > >>>>> Best, > >>>>> > >>>>> Rolf > >>>>> > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria > >>>>> Road, London W3 6BL | Registered in England 2832014 > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > >>>>>> Behalf Of Shahram Davari > >>>>>> Sent: Mittwoch, 28. November 2012 18:46 > >>>>>> To: Pablo Frank > >>>>>> Cc: mpls@ietf.org > >>>>>> Subject: Re: [mpls] working group last call on > >>>>>> draft-ietf-mpls-tp-mip- mep-map > >>>>>> > >>>>>> Pablo, > >>>>>> > >>>>>> > >>>>>> > >>>>>> That was exactly my point. Let's use a flag to indicate in-MIP > or > >>>>>> out- MIP and then the offline processor can do MEPID lookup to > >>>>>> determine whether this is a legitimate OAM packet or not. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thx > >>>>>> Shahram > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] > >>>>>> Sent: Wednesday, November 28, 2012 8:22 AM > >>>>>> To: Shahram Davari > >>>>>> Cc: mpls@ietf.org > >>>>>> Subject: Re: [mpls] working group last call on > >>>>>> draft-ietf-mpls-tp-mip- mep-map > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think Shahram raises a very legitimate concern about how > >>>>>> expensive this could be to implement in hardware. > >>>>>> > >>>>>> > >>>>>> > >>>>>> As I understand it, the logic proposed by this draft is as > >> follows: > >>>>>> > >>>>>> > >>>>>> > >>>>>> At the ingress blade: > >>>>>> > >>>>>> > >>>>>> > >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >>>>>> > >>>>>> Parse MIP-ID TLV > >>>>>> > >>>>>> Lookup MIP-ID > >>>>>> > >>>>>> IF MIP-is-egress, THEN > >>>>>> > >>>>>> forward normally (but note we must intercept it again on > >>>> egress) > >>>>>> > >>>>>> ELSE > >>>>>> > >>>>>> punt to OAM processor > >>>>>> > >>>>>> > >>>>>> > >>>>>> At the egress blade: > >>>>>> > >>>>>> > >>>>>> > >>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN > >>>>>> > >>>>>> Parse MIP-ID TLV > >>>>>> > >>>>>> Lookup MIP-ID > >>>>>> > >>>>>> IF MIP-is-egress, THEN > >>>>>> > >>>>>> punt to OAM processor > >>>>>> > >>>>>> ELSE > >>>>>> > >>>>>> drop > >>>>>> > >>>>>> > >>>>>> > >>>>>> Note all this has to be done in the fast-path now at full line > >>>>>> rate (and hardware guys hate TLVs). Before, the only thing the > >>>>>> fast-path had to do was look for TTL-expiry. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The only reason that ACH reserved bit was rejected (in Appendix > >>>>>> A.4 of > >>>>>> -03 version of doc) was because it also required a MIP-ID lookup. > >>>>>> But I don't see anything wrong with combining both mechanisms. > >>>>>> Ideally, hardware could rely on the reserved bit to do the > >> initial > >>>>>> filtering at full line-rate and then a presumably much more > >>>>>> cost-efficient OAM hardware block could perform the MIP-ID > lookup. > >>>>>> Instead of the complex logic above, the fast path gets a simple > >>>>>> modification to TTL handling and the OAM block does the heavy > >>>> lifting of dealing with ACH TLVs, etc. > >>>>>> > >>>>>> > >>>>>> > >>>>>> This seems like a case where practicality should trump elegance. > >>>>>> > >>>>>> > >>>>>> > >>>>>> regards, > >>>>>> > >>>>>> Pablo > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Rolf, > >>>>>>> > >>>>>>> I am sure you know that TLVs are not Hardware friendly. And > >> I > >>>>>> think you agree with me that this draft requires deep parsing of > >>>>>> all packets at line rate to get to the MIPID TLV. > >>>>>>> > >>>>>>> I still think the MIPID TLV is required to decide whether an > >>>> OAM > >>>>>> packet ended up at the right MIP. But may be a simpler solution > >>>>>> could be augmented to decide between In-MIP and Out-MIP. For > >>>>>> example how about using one of the reserved bits in the ACH > >>>>>> header. This > >>>> can > >>>>>> easily be done in hardware with minimum complexity. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Shahram > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] > >> On > >>>>>> Behalf Of Rolf Winter > >>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM > >>>>>>> To: S. Davari; adrian@olddog.co.uk > >>>>>>> Cc: mpls@ietf.org > >>>>>>> Subject: Re: [mpls] working group last call on > >>>>>> draft-ietf-mpls- tp-mip-mep-map > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>>> Hi Adrian, > >>>>>>>> > >>>>>>>> You are right and I should have sent these types of > >> comments > >>>>>> before > >>>>>>>> last call. I completely understand the procedure. > >>>>>>>> > >>>>>>>> One thing I didn't understand in your response is that you > >>>> said > >>>>>> in-MIP > >>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is > >>>>>> that? > >>>>>>>> > >>>>>>>> My understanding is that before this draft, the process > >>>>>> would have > >>>>>>>> been for the ingress to look at TTL and if it is expired > >>>>>> then send the > >>>>>>>> packet to OAM processor. > >>>>>>> > >>>>>>> Yes (and no). While I assume likely MIP functionality will > >> be > >>>>>> implemented on the ingress, the related RFCs are vague about the > >>>>>> actual placement of the MIP function. See e.g. the OAM Framework > >>>> (RFC > >>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an > >>>>>> unspecified location within the node)". > >>>>>>> > >>>>>>> Also, I think "before this draft" is not quite accurate in > >>>>>> that is suggests there is no per-interface MIP addressing > >> possible > >>>>>> as of > >>>> now. > >>>>>> Take RFC 6426. In practice this is where part of the problem > lies. > >>>> We > >>>>>> cannot really go back and change all this. There are other > >>>> constraints. > >>>>>> E.g. we have a requirement to address a single out-MIP out of a > >>>>>> set of out-MIPs on a P2MP branch point. So this was part of the > >>>>>> constraints we worked with. > >>>>>>> > >>>>>>>> > >>>>>>>> The MEPID that you suggest in this draft is very useful for > >>>>>> filtering > >>>>>>>> out leaked OAM frames from upstream. But lets leave lookup > >>>>>> of the MEPID > >>>>>>>> to the OAM processing module (at slower rate) and add an > >>>>>> indicator to > >>>>>>>> the OAM packet to indicate whether it should be taken out > >> of > >>>>>> the data > >>>>>>>> path in the Ingress or egress. > >>>>>>>> > >>>>>>>> So can I suggest adding the following text to the draft: > >>>>>>>> > >>>>>>>> " In addition to the MEPID, which is used to ultimately > >>>>>> accept or > >>>>>>>> filter out received OAM packets, OAM packets should have a > >>>>>> simple > >>>>>>>> indicator that identifies whether the OAM packet belongs to > >>>>>> in-MIP or > >>>>>>>> Out-MIP". > >>>>>>> > >>>>>>> We also have the question on where to retrofit those bits. I > >>>>>> assume a TLV wouldn't work for the exact reasons you do not like > >>>>>> to have to do a second lookup, since it would require some > >>>>>> parsing. All these constraints and the ones outlined in the > >>>>>> document led to where we are. In a sense this is a non-spec > since > >>>>>> it rather rules out a number of things that seem like a good > idea > >>>>>> at first but then have a catch of some sort. > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Rolf > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Shahram > >>>>>>>> > >>>>>>>> > >>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" > >>>>>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi Shahram, > >>>>>>>>> > >>>>>>>>> I am worried about the precedent of a comment like this > >>>> during > >>>>>> WG > >>>>>>>> last call. > >>>>>>>>> While comments that improve the document or point out > >>>>>> fundamental > >>>>>>>>> flaws are welcome whenever they arrive, points with the > >>>>>> flavour "I > >>>>>>>>> wouldn't have done it like this" that arrive this late in > >>>>>> the process > >>>>>>>> don't feel very constructive. > >>>>>>>>> But I will leave the chair to worry about process and try > >>>>>> to address > >>>>>>>>> the technical points... > >>>>>>>>> > >>>>>>>>>> Identifying whether to terminate an OAM packet and > >> process > >>>> it > >>>>>> in In- > >>>>>>>> MIP vs. > >>>>>>>>> Out- > >>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet > >>>>>> will not > >>>>>>>> take > >>>>>>>>>> the same path as data packets. Therefore any MIP > >>>>>> identifier that is > >>>>>>>>>> proposed in this > >>>>>>>>> draft > >>>>>>>>>> requires one extra lookup and therefore adds > >> significantly > >>>> to > >>>>>> cost. > >>>>>>>>> > >>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you > >>>>>> decide to > >>>>>>>>> implement out-MIPs, and if you want the OAM to follow > >>>>>> exactly the > >>>>>>>> same > >>>>>>>>> path as the data, then it is a requirement that the out > >>>>>> interface > >>>>>>>>> inspects the packets (at line > >>>>>>>>> rate) to determine whether they are OAM and targeted at > >> the > >>>>>> interface. > >>>>>>>>> > >>>>>>>>> We cannot change that aspect. All we can do is aim to make > >>>> the > >>>>>> lookup > >>>>>>>>> as easy as possible. > >>>>>>>>> > >>>>>>>>>> Perhaps a > >>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain > >>>>>> Level) may be > >>>>>>>>>> used that requires only 3 bits and achieves the same > >> result. > >>>>>>>>> > >>>>>>>>> Perhaps it could. > >>>>>>>>> But before going there, why is the lookup in the current > >>>>>> version of > >>>>>>>>> the I-D arduous? > >>>>>>>>> > >>>>>>>>> Presumably you do not propose making any change to the way > >>>>>> In-MIPs > >>>>>>>> are > >>>>>>>>> currently identified, so the lookups being done at line > >>>>>> rate today on > >>>>>>>>> the incoming interfaces will not be changed. If you are > >>>>>> proposing > >>>>>>>> such > >>>>>>>>> a change, then the discussion is outside the scope of this > >>>>>> I- D and > >>>>>>>>> becomes a much wider question for the working group. > >>>>>>>>> > >>>>>>>>> This leaves me with the trade-off of enabling a *simpler* > >>>>>> lookup on > >>>>>>>>> the outgoing interfaces versus doing identical lookups on > >>>> both > >>>>>>>>> interfaces. My assumption was that if the incoming > >>>>>> interface can do > >>>>>>>>> the lookup at line rate, it is not hard to perform the > >> same > >>>>>> lookup on > >>>>>>>>> the outgoing interface. Furthermore, there is a reduction > >> in > >>>>>>>> complexity by having fewer things to look up. > >>>>>>>>> > >>>>>>>>> Another possibility is that the full lookup could be done > >>>>>> on the > >>>>>>>>> incoming interface and the packet marked for easy > >>>> interception > >>>>>> on the > >>>>>>>> outgoing interface. > >>>>>>>>> The concern with this approach is that the packet would no > >>>>>> longer be > >>>>>>>>> being forwarded exactly as data because it would be being > >>>>>> modified in > >>>>>>>> flight. > >>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag > >>>> the > >>>>>> packet > >>>>>>>>> as a local Out-MIP and further identifier-based lookup is > >>>>>> needed. > >>>>>>>>> > >>>>>>>>> Some of these issues were raised and discussed as the I-D > >>>>>> progressed, > >>>>>>>>> and some of the alternative solutions were tracked with > >>>>>> their pros > >>>>>>>> and > >>>>>>>>> cons in Appendix A of the I-D (look at revision -03). > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Adrian > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls- > >> bounces@ietf.org] > >>>> On > >>>>>> Behalf > >>>>>>>>>> Of Adrian Farrel > >>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM > >>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org > >>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >>>>>> ; > >>>>>>>>> draft-ietf-mpls-tp-mip- > >>>>>>>>>> mep-map@tools.ietf.org > >>>>>>>>>> Subject: Re: [mpls] working group last call on > >>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map > >>>>>>>>>> > >>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author > >>>>>> anything > >>>>>>>> else? > >>>>>>>>>> > >>>>>>>>>> The point was that when I started the I-D lots of people > >>>> were > >>>>>> saying > >>>>>>>>>> "it's complex" and "it can't be done" and "it won't be > >>>>>> backward > >>>>>>>> compatible". > >>>>>>>>>> > >>>>>>>>>> So the I-D says "here it is" > >>>>>>>>>> > >>>>>>>>>> A (sorry not to offer you excitement) > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] > >>>>>>>>>>> Sent: 19 November 2012 12:38 > >>>>>>>>>>> To: Loa Andersson; mpls@ietf.org > >>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org > >>>>>> ; MPLS-TP ad > >>>>>>>>>>> hoc > >>>>>>>>> team; > >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org > >>>>>>>>>>> Subject: Re: [mpls] working group last call on > >>>>>>>>> draft-ietf-mpls-tp-mip-mep-map > >>>>>>>>>>> > >>>>>>>>>>> After getting to section 6 and its features > >>>>>> (requirements!), I find > >>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it > >> is > >>>>>>>>>>> Informational and not Standards Track. > >>>>>>>>>>> > >>>>>>>>>>> Meanwhile, I suggest some editorial issues. > >>>>>>>>>>> > >>>>>>>>>>> Title > >>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs > >>>>>> [Handling > >>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a > >> more > >>>>>>>>>>> informative statement unless and until you get to the > >>>>>> definition of > >>>>>>>>>>> Internal in s3; and s6, which is the crux of the > >> document > >>>>>> says The > >>>>>>>>>>> preferred solution to per-interface MIP message handling > >> is > >>>>>>>>>>> presented in this section] > >>>>>>>>>>> > >>>>>>>>>>> s1 > >>>>>>>>>>> two (or more) MIPs per node on both sides of the > >>>>>> forwarding engine. > >>>>>>>>>>> [two on both sides sounds like four in total to me; > >>>>>> suggest 'one on > >>>>>>>>>>> each side of the forwarding engine'] > >>>>>>>>>>> > >>>>>>>>>>> s4 > >>>>>>>>>>> o CV between a MEP and a MIP [expand CV on first use] > >>>>>>>>>>> > >>>>>>>>>>> s5 > >>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] > >>>>>> for MPLS-TP > >>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. > >>>>>>>>>>> ['respectively' suggests to me that there should be two > >>>>>> precedents, > >>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 > >>>> for > >>>>>> LSPs, > >>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this > >>>> sentence > >>>>>> as > >>>>>>>>>>> redundant] > >>>>>>>>>>> > >>>>>>>>>>> s6 > >>>>>>>>>>> The appendix of this document contains a few solutions that > >>>>>>>>>>> the authors have discarded which > >> have > >>>>>> been > >>>>>>>> left in > >>>>>>>>>>> the document for informational purposes. > >>>>>>>>>>> [not any more they haven't!] > >>>>>>>>>>> > >>>>>>>>>>> The node itself is addresses [The node itself is addressed] > >>>>>>>>>>> > >>>>>>>>>>> The identification information indside [The > >> identification > >>>>>>>>>>> information inside ] > >>>>>>>>>>> > >>>>>>>>>>> MIP identifiers are not know [MIP identifiers are not > known] > >>>>>>>>>>> > >>>>>>>>>>> reserved MIP address > >>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] > >>>>>>>>>>> > >>>>>>>>>>> Tom Petch > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>> From: "Loa Andersson" > >>>>>>>>>>> To: > >>>>>>>>>>> Cc: ; >>>>>> chairs@tools.ietf.org>; > >>>>>>>>>>> "MPLS-TP ad hoc team" ; > >>>>>>>>>>> > >>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM > >>>>>>>>>>> > >>>>>>>>>>>> Working Group, > >>>>>>>>>>>> > >>>>>>>>>>>> This is to start a 2 week working group last call on > >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. > >>>>>>>>>>>> > >>>>>>>>>>>> Please send your comments to the mpls working group > >>>> mailing > >>>>>> list > >>>>>>>>>>>> (mpls@ietf.org). > >>>>>>>>>>>> > >>>>>>>>>>>> Please send both technical comments, and if you are > >>>>>> happy with the > >>>>>>>>>>>> document as is also indications of support. > >>>>>>>>>>>> > >>>>>>>>>>>> This working group last call will end on November 28. > >>>>>>>>>>>> > >>>>>>>>>>>> /Loa > >>>>>>>>>>>> for the wg co-chairs > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> mpls mailing list > >>>>>>>>>> mpls@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> mpls mailing list > >>>>>>>>> mpls@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>>>> _______________________________________________ > >>>>>>>> mpls mailing list > >>>>>>>> mpls@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>>> > >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 > >> Victoria > >>>>>> Road, London W3 6BL | Registered in England 2832014 > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> > >>> > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From hideki.endo.es@hitachi.com Tue Dec 4 03:49:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE3921F89DD for ; Tue, 4 Dec 2012 03:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xtTqpDjGCiR for ; Tue, 4 Dec 2012 03:49:46 -0800 (PST) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 54AFC21F8617 for ; Tue, 4 Dec 2012 03:49:46 -0800 (PST) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 4598933CC5; Tue, 4 Dec 2012 20:49:45 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id qB4Bnj2A032516; Tue, 4 Dec 2012 20:49:45 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB4Bnixv021177; Tue, 4 Dec 2012 20:49:45 +0900 Received: from vshuts04.hitachi.co.jp ([vshuts04.hitachi.co.jp [10.201.6.86]]) by mfilter04.hitachi.co.jp with RELAY id qB4BnhMw021164 ; Tue, 4 Dec 2012 20:49:44 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 6986B14004F; Tue, 4 Dec 2012 20:49:43 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB4BnhK15605982; Tue, 4 Dec 2012 20:49:43 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Tue, 4 Dec 2012 20:49:22 +0900 References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> Priority: normal Importance: normal X400-Content-Identifier: X50BDE31F00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121204204847Y4T] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:49:48 -0000 Shahram, You replied to Rolf in other mail; "For in-MIP a single bit is enough. However for out-MIP the CPU has to drop the unwanted OAM. Not efficient but the system still works. " Yes, that's right. This was my point. Again, even if your solution using ACH header is applied, it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness in the case of P2MP tree having 100 leafs. Thanks, Hideki Endo >I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU. > >Regards, >Shahram > > >On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" wrote: > >> Sharhram, >> >> I didn't mean new requirement similar to Figure 7. >> I do think that OAM packets must go through the normal forwarding engine >> without bypass. >> >> As Rolf said in other e-mail, >> -------------------------- >> | -----| >> | | MIP1| >> | ->-| |->---- >> | | | Out | >> | | | i/f | >> | | -----| >> |----- | -----| >> | MIP0| ---- | | MIP2| >> | | | |- | | >> ----->-| In |->-| FW |--->-| Out |->---- >> | i/f | | |- | i/f | >> |----- ---- | -----| >> | | -----| >> | | | MIP3| >> | | | | >> | ->-| Out |->---- >> | | i/f | >> | -----| >> -------------------------- >> The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually. >> Here, each out-MIP has different MIP ID. >> If you don't need this machanism, >> how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? >> >> Thanks, >> Hideki Endo >> >> >>> Hideki, >>> >>> In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding engine and do unicast forwarding of a multicast OAM packet to a single outgoing port. This kind of behavior is explicitly rejected in the draft. >>> >>> Regards, >>> Shahram >>> >>> >>> On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: >>> >>>> Hi Hideki, >>>> >>>> I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP. >>>> >>>> But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc. >>>> >>>> >>>> Regards, >>>> Shahram >>>> >>>> >>>> On Dec 3, 2012, at 5:24 PM, wrote: >>>> >>>>> Hi Shahram, >>>>> >>>>> Back and forth. >>>>> Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not. >>>>> >>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>> Don't you consider the case when MIPs is configured in the Egress port B,C and D? >>>>> In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D. >>>>> In that case, your solution has low effectiveness as I pointed out. >>>>> Do I miss something? >>>>> >>>>> Thanks, >>>>> Hideki Endo >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW. >>>>>> >>>>>> Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW. >>>>>> >>>>>> Thanks, >>>>>> Shahram >>>>>> >>>>>> -----Original Message----- >>>>>> From: Shahram Davari >>>>>> Sent: Monday, December 03, 2012 4:53 PM >>>>>> To: 'hideki.endo.es@hitachi.com' >>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>> >>>>>> Hi Hideki, >>>>>> >>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>>> >>>>>> Thx >>>>>> Shahram >>>>>> >>>>>> -----Original Message----- >>>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>>>> Sent: Monday, December 03, 2012 4:48 PM >>>>>> To: Shahram Davari >>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>> >>>>>> Hi Shahram, >>>>>> >>>>>> First, as Rolf sent, we need in/out-MIP for >>>>>> 1. CV between a MEP and a MIP >>>>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >>>>>> 3. data-plane loopback configuration at a MIP >>>>>> 4. diagnostic tests >>>>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>>>> >>>>>> Second, you wrote; >>>>>> "The issue is that each CPU/processor has limited resources. >>>>>> By sending all OAM MIP packets to both processor you are >>>>>> losing 1/2 of the capacity of each processor. " >>>>>> It depends on implementations, >>>>>> and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. >>>>>> Let's consider P2MP case as you pointed out. >>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>> This means that the OAM processor at port D loses its capacity. >>>>>> If we consider the larger number of ports in the LSR which has 100 ports, for example, >>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>> This means that the OAM processors at the other 98 ports lose those capacities. >>>>>> Even if your solution using ACH header is applied, >>>>>> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >>>>>> in the case of P2MP for 100 ports. >>>>>> >>>>>> Thanks, >>>>>> Hideki Endo >>>>>> >>>>>> >>>>>>> Rolf, >>>>>>> >>>>>>> For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: >>>>>>> >>>>>>> 1) MIP on port A (In-MIP), or >>>>>>> 2) MIP on port B (out-MIP), or >>>>>>> 3) MEIP on Port A and B >>>>>>> >>>>>>> A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. >>>>>>> >>>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. >>>>>>> >>>>>>> So the Pseudo-code is like this: >>>>>>> >>>>>>> Ingress Port: >>>>>>> >>>>>>> If packet is OAM and TTL=1 >>>>>>> If MIP is enabled >>>>>>> If packet indicates In-MIP >>>>>>> Send to local CPU >>>>>>> Else >>>>>>> Forward to egress port >>>>>>> End >>>>>>> Else >>>>>>> Forward normally >>>>>>> End >>>>>>> Else >>>>>>> >>>>>>> Egress Port: >>>>>>> >>>>>>> If packet is OAM and TTL=1 >>>>>>> If MIP is enabled >>>>>>> If packet indicates In-MIP >>>>>>> Drop packet >>>>>>> Else If packet indicates Out-MIP >>>>>>> Send to local CPU >>>>>>> End >>>>>>> Else >>>>>>> Drop packet >>>>>>> End >>>>>>> End >>>>>>> >>>>>>> >>>>>>> Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? >>>>>>> >>>>>>> Thanks >>>>>>> Shahram >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>>>> To: Shahram Davari >>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>> >>>>>>> But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. >>>>>>> >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>>>> To: Rolf Winter >>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>>>>>>> mep-map >>>>>>>> >>>>>>>> Hi Rolf, >>>>>>>> >>>>>>>> Your HW guys are correct as long as the amount of data sent to the in- >>>>>>>> MIP processor is not much. But from your previous email to Loa I see >>>>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>>>>>>> not be expecting them is like DoS attack. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Shahram >>>>>>>> >>>>>>>> >>>>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> sorry for the belated response. I checked with some of our HW people. >>>>>>>> Here's the gist of their response: >>>>>>>>> >>>>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>>>> fact already. Their answer to the problem is slightly different though. >>>>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>>>>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>>>>>> implementation must behave in this exact way in either case. So there >>>>>>>> is at least one way to implement this at line rate without going back >>>>>>>> and changing a bunch of RFCs. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Rolf >>>>>>>>> >>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>>>>>>> Of Shahram Davari >>>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>>>> To: Pablo Frank >>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>> >>>>>>>>>> Pablo, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thx >>>>>>>>>> Shahram >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>>>> To: Shahram Davari >>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think Shahram raises a very legitimate concern about how expensive >>>>>>>>>> this could be to implement in hardware. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At the ingress blade: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>> >>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>> >>>>>>>>>> Lookup MIP-ID >>>>>>>>>> >>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>> >>>>>>>>>> forward normally (but note we must intercept it again on >>>>>>>> egress) >>>>>>>>>> >>>>>>>>>> ELSE >>>>>>>>>> >>>>>>>>>> punt to OAM processor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At the egress blade: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>> >>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>> >>>>>>>>>> Lookup MIP-ID >>>>>>>>>> >>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>> >>>>>>>>>> punt to OAM processor >>>>>>>>>> >>>>>>>>>> ELSE >>>>>>>>>> >>>>>>>>>> drop >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-path >>>>>>>>>> had to do was look for TTL-expiry. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>>>>>> of >>>>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> >>>>>>>>>> Pablo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Rolf, >>>>>>>>>>> >>>>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>>>> think you agree with me that this draft requires deep parsing of all >>>>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>>>> >>>>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>>>> OAM >>>>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For example >>>>>>>>>> how about using one of the reserved bits in the ACH header. This >>>>>>>> can >>>>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Shahram >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>>>> Behalf Of Rolf Winter >>>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>>>>> tp-mip-mep-map >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>>> Hi Adrian, >>>>>>>>>>>> >>>>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>>>> before >>>>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>>> >>>>>>>>>>>> One thing I didn't understand in your response is that you >>>>>>>> said >>>>>>>>>> in-MIP >>>>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>>>> that? >>>>>>>>>>>> >>>>>>>>>>>> My understanding is that before this draft, the process would >>>>>>>>>> have >>>>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>>>> send the >>>>>>>>>>>> packet to OAM processor. >>>>>>>>>>> >>>>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>>>> (RFC >>>>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>>>>>> location within the node)". >>>>>>>>>>> >>>>>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>>>>> is suggests there is no per-interface MIP addressing possible as of >>>>>>>> now. >>>>>>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>>>>>> We >>>>>>>>>> cannot really go back and change all this. There are other >>>>>>>> constraints. >>>>>>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>>>> constraints we worked with. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>>>> filtering >>>>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>>>> the MEPID >>>>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>>>> indicator to >>>>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>>>> the data >>>>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>>> >>>>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>>> >>>>>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>>>>> or >>>>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>>>> simple >>>>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>>>> in-MIP or >>>>>>>>>>>> Out-MIP". >>>>>>>>>>> >>>>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>>>>>> have to do a second lookup, since it would require some parsing. All >>>>>>>>>> these constraints and the ones outlined in the document led to where >>>>>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>>>>> number of things that seem like a good idea at first but then have a >>>>>>>>>> catch of some sort. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Rolf >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Shahram >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Shahram, >>>>>>>>>>>>> >>>>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>>>> during >>>>>>>>>> WG >>>>>>>>>>>> last call. >>>>>>>>>>>>> While comments that improve the document or point out >>>>>>>>>> fundamental >>>>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>>>> flavour "I >>>>>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>>>>> process >>>>>>>>>>>> don't feel very constructive. >>>>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>>>> address >>>>>>>>>>>>> the technical points... >>>>>>>>>>>>> >>>>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>>>> it >>>>>>>>>> in In- >>>>>>>>>>>> MIP vs. >>>>>>>>>>>>> Out- >>>>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>>>>> not >>>>>>>>>>>> take >>>>>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>>>>> that is >>>>>>>>>>>>>> proposed in this >>>>>>>>>>>>> draft >>>>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>>>> to >>>>>>>>>> cost. >>>>>>>>>>>>> >>>>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>>>> decide to >>>>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>>>> interface >>>>>>>>>>>>> inspects the packets (at line >>>>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>>>> interface. >>>>>>>>>>>>> >>>>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>>>> the >>>>>>>>>> lookup >>>>>>>>>>>>> as easy as possible. >>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps a >>>>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>>>> Level) may be >>>>>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps it could. >>>>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>>>> version of >>>>>>>>>>>>> the I-D arduous? >>>>>>>>>>>>> >>>>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>>>> In-MIPs >>>>>>>>>>>> are >>>>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>>>> today on >>>>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>>>> proposing >>>>>>>>>>>> such >>>>>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>>>>> D and >>>>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>>> >>>>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>>>> lookup on >>>>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>>>> both >>>>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>>>> can do >>>>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>>>> lookup on >>>>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>>> >>>>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>>>> the >>>>>>>>>>>>> incoming interface and the packet marked for easy >>>>>>>> interception >>>>>>>>>> on the >>>>>>>>>>>> outgoing interface. >>>>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>>>> longer be >>>>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>>>> modified in >>>>>>>>>>>> flight. >>>>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>>>> the >>>>>>>>>> packet >>>>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>>>> needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>>>> progressed, >>>>>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>>>>> pros >>>>>>>>>>>> and >>>>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>>>> On >>>>>>>>>> Behalf >>>>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>> ; >>>>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>>>> anything >>>>>>>>>>>> else? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>>>> were >>>>>>>>>> saying >>>>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>>>> backward >>>>>>>>>>>> compatible". >>>>>>>>>>>>>> >>>>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>>> >>>>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>>>> hoc >>>>>>>>>>>>> team; >>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>>>>> I find >>>>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Title >>>>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>>>> [Handling >>>>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>>>> definition of >>>>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>>>> says The >>>>>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s1 >>>>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>>>>> engine. >>>>>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>>>>> 'one on >>>>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s4 >>>>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s5 >>>>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>>>>> MPLS-TP >>>>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>>>> precedents, >>>>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>>>> for >>>>>>>>>> LSPs, >>>>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>>>> sentence >>>>>>>>>> as >>>>>>>>>>>>>>> redundant] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> s6 >>>>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>>>> been >>>>>>>>>>>> left in >>>>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>>>> To: >>>>>>>>>>>>>>> Cc: ; >>>>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>>>> mailing >>>>>>>>>> list >>>>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>>>> with the >>>>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>> >>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >> > > From davari@broadcom.com Tue Dec 4 06:54:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CCD21F8BB5 for ; Tue, 4 Dec 2012 06:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yakwRE1Odptd for ; Tue, 4 Dec 2012 06:54:12 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2221F8BB0 for ; Tue, 4 Dec 2012 06:54:12 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 06:52:01 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 06:53:54 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 06:53:54 -0800 From: "Shahram Davari" To: "" Thread-Topic: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0eJMrDrf0hTkh0+f0Jf1wk5ixZgI2e+A//+Gd42AAJXsgP//xEQE Date: Tue, 4 Dec 2012 14:53:53 +0000 Message-ID: <3DE525CB-AC12-4B3C-BE0D-17CF9390D584@broadcom.com> References: <5098CF68.2000105@pi.nu> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa>, <28AF076D-2D85-4B79-8A7E-0C1AE39D01DC@broadcom.com>, <791AD3077F94194BB2BDD13565B6295D55542A76@DAPHNIS.office.hd> <86E44E2B-5306-49D7-BA75-BAE914E8B031@broadcom.com>, <50BDD01D.7060005@cisco.com> In-Reply-To: <50BDD01D.7060005@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA0D19B1QK15216744-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:54:13 -0000 That is the whole point, that TLVs are not hardware friendly. But at least = ACH TLV is at a fixed location. Regards, Shahram On Dec 4, 2012, at 2:27 AM, "Stewart Bryant" wrote: > No one liked those (for h/w reasons), so we never used them for any first= generation OAM applications. If you look at the registry you will see that= none have been defined. >=20 > Stewart >=20 > On 04/12/2012 09:31, Shahram Davari wrote: >> How about the G-ACH TLV that immediately follows ACH. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 4, 2012, at 12:46 AM, "Rolf Winter" wrote= : >>=20 >>> Hi, >>>=20 >>> quite some time ago we asked whether we could mandate TLV ordering (at = least mandating one out of N TLVs to be the first in the OAM PDU) in order = to allow efficient implementation in HW. This actually would be a good thin= g in this case. The responses we got weren't quite positive (which is actua= lly quite a positive description of the responses we got) but I don't see t= hat the GACh RFC is actually disallowing it. Still we would need to go back= and make changes to a few RFCs. That was also something people weren't rea= lly happy about. Again, these were some of the constraints we worked with w= hich led to what is on the table right now. We weren't blind to HW consider= ations, vice versa as you can see when you look at the appendix that was re= moved in the latest version of the document. >>>=20 >>> Best, >>>=20 >>> Rolf >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lon= don W3 6BL | Registered in England 2832014 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Puneet Agarwal [mailto:pagarwal@broadcom.com] >>>> Sent: Dienstag, 4. Dezember 2012 06:44 >>>> To: hideki.endo.es@hitachi.com >>>> Cc: Shahram Davari; Rolf Winter; mpls@ietf.org >>>> Subject: Re: [mpls] working group last call ondraft-ietf-mpls-tp-mip- >>>> mep-map >>>>=20 >>>> Hi hideki, >>>>=20 >>>> Is the determination that the mip identifier is present in the same >>>> location always in the pdu or is it variable (based on oam msg type)? >>>>=20 >>>> Thx >>>>=20 >>>> Puneet >>>>=20 >>>>=20 >>>>=20 >>>> On Dec 3, 2012, at 5:24 PM, "hideki.endo.es@hitachi.com" >>>> wrote: >>>>=20 >>>>> draft-ietf-mpls-tp-mip-mep-map >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From davarish@yahoo.com Tue Dec 4 06:56:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF32921F870C for ; Tue, 4 Dec 2012 06:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg60leKBpaOk for ; Tue, 4 Dec 2012 06:56:48 -0800 (PST) Received: from nm46-vm2.bullet.mail.ne1.yahoo.com (nm46-vm2.bullet.mail.ne1.yahoo.com [98.138.121.82]) by ietfa.amsl.com (Postfix) with ESMTP id A305E21F85BF for ; Tue, 4 Dec 2012 06:56:47 -0800 (PST) Received: from [98.138.226.178] by nm46.bullet.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:43 -0000 Received: from [98.138.88.107] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:43 -0000 Received: from [127.0.0.1] by smtp124-mob.biz.mail.ne1.yahoo.com with NNFMP; 04 Dec 2012 14:56:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354633002; bh=jAruvo3TsPiiQKdim7scB74rm3qQI/vuEZ2AwZcM9/U=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Content-Transfer-Encoding:Subject:References:From:Mime-Version:In-Reply-To:Message-Id:Date:Cc:To:X-Mailer; b=5PsoWKq3RhIyUmNzv30P0/7FxzFXW070MFGUHhXDZmVZeqoxkl+UEUADzEXgp+VGNSm8+pLiuPMraOiqhwbOwzkZP1lGdYmbJgg+rxvFhIqHisAyzvjyIoTj/7Dkqk9gCdOO75loVAlKGb/prLtlk92bsENoeenbICm+gjcT8Ms= X-Yahoo-Newman-Id: 978202.92292.bm@smtp124-mob.biz.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pFU1F_QVM1lKSXaWVQeOxDKiAXwM2LzxqT_kfqZi8LBV7cB 1YdJHOeoh75ydn6phRxPqhi2piegt80TF37WHDLbWyHTGR1veXv17XJdMyIW 8GkCzEA831z7.P2hAwnPJEFWt40MPvq_v8sFdYA5WqYJajErCc9wzxzzuYuw Sne4rEGinEAZAJpAoE55V9p6.zfMZ39LdqCkr6FEuyEa2IhBOuwnlRAJcRkv ZOHKfYfrOG3yXdISFKX7IlBDaRXUU.yBN._J3jcH36eRbTPCrvTBtYTTKZtk 9JBmrwF2u.0GN7Nhyxh7IdDeqowzFP2L94uJ0V5rk3TFv0xwlW0iJilm3JN5 _Q8fCbujCLA.r8Blc_rhr4Uyu5yncH7OiGA5VInjUgjukN2FCsZB7gu4Ou3f 9fmoJeB.8zcE_rS.NKBjo4IEsNUzfeUXmg.h.6Ob8JB33x7D0r8LkzBZOBZ7 VhtdtfX3No9o- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [192.168.0.104] (davarish@98.248.36.11 with xymcookie) by smtp124-mob.biz.mail.ne1.yahoo.com with SMTP; 04 Dec 2012 14:56:42 +0000 UTC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <01e601cdc652$dab31600$4001a8c0@gateway.2wire.net> <016e01cdc675$3b64d6b0$b22e8410$@olddog.co.uk> <4A6CE49E6084B141B15C0713B8993F281BD2E957@SJEXCHMB12.corp.ad.broa> <027c01cdc7c8$d5500430$7ff00c90$@olddog.co.uk> <791AD3077F94194BB2BDD13565B6295D5552490A@Hydra.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38C6B@SJEXCHMB12.corp.ad.br oadcom.com> <791AD3077F94194BB2BDD13565B6295D55542A55@DAPHNIS.office.hd> <98F14E8F-9AAC-4372-B322-C23D2AD0DDCE@yahoo.com> <791AD3077F94194BB2BDD13565B6295D55543BED@DAPHNIS.office.hd> From: "S. Davari" Mime-Version: 1.0 (1.0) In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55543BED@DAPHNIS.office.hd> Message-Id: <6B968B80-D20C-4A29-8ACD-9DA27992C169@yahoo.com> Date: Tue, 4 Dec 2012 06:56:15 -0800 To: Rolf Winter X-Mailer: iPhone Mail (10A403) Cc: "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 14:56:49 -0000 Correct. Regards, Shahram On Dec 4, 2012, at 3:40 AM, Rolf Winter wrote: > Hi Sharam, >=20 > that is not quite accurate. It will happen at all nodes at the same TTL di= stance because also there the TTL will expire even if no out-MIP is addresse= d there. >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London= W3 6BL | Registered in England 2832014=20 >=20 >=20 >> -----Original Message----- >> From: S. Davari [mailto:davarish@yahoo.com] >> Sent: Dienstag, 4. Dezember 2012 10:29 >> To: Rolf Winter >> Cc: Shahram Davari; hideki.endo.es@hitachi.com; mpls@ietf.org >> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >> mep-map >>=20 >> Hi Rolf, >>=20 >> For in-MIP a single bit is enough. However for out-MIP the CPU has to >> drop the unwanted OAM. Not efficient but the system still works. >> Remember this happens only in a corner case of p2mp MPLS with multiple >> out-MIP on the same router, and when only root wants to talk to one of >> the leaves. >>=20 >> That's why I am suggesting to have a single bit in addition to the >> MEPID. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 4, 2012, at 12:33 AM, Rolf Winter wrote: >>=20 >>> Shahram, >>>=20 >>> what if it is configured and you only want to talk to one out of all >> the out-MIPs. I guess we can all craft examples where we can make our >> point. A single bit simply does not guarantee you that the local CPU >> does not have to look at the OAM frame to finally discard it. >>>=20 >>> Best, >>>=20 >>> Rolf >>>=20 >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>> Sent: Dienstag, 4. Dezember 2012 01:53 >>>> To: hideki.endo.es@hitachi.com >>>> Cc: Rolf Winter; mpls@ietf.org >>>> Subject: RE: Re:Re: [mpls] working group last call on >>>> draft-ietf-mpls- tp-mip-mep-map >>>>=20 >>>> Hi Hideki, >>>>=20 >>>> I think you need to look at my p-code. F a MIP is not configured in >>>> the Egress port, then that egress port won't sent the OAM packet to >>>> its processor and drops it. So there is no issue with my proposed >> method. >>>>=20 >>>> Thx >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>> Sent: Monday, December 03, 2012 4:48 PM >>>> To: Shahram Davari >>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls- >> tp- >>>> mip-mep-map >>>>=20 >>>> Hi Shahram, >>>>=20 >>>> First, as Rolf sent, we need in/out-MIP for 1. CV between a MEP and >> a >>>> MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW >> containing >>>> MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic >>>> tests Here, CV means On-demand CV. You may misunderstand as >> Proactive CV. >>>>=20 >>>> Second, you wrote; >>>> "The issue is that each CPU/processor has limited resources. >>>> By sending all OAM MIP packets to both processor you are losing 1/2 >>>> of the capacity of each processor. " >>>> It depends on implementations, >>>> and this issue could NOT be resolved by even your solution that uses >>>> ACH header to indicate in/out-MIP. >>>> Let's consider P2MP case as you pointed out. >>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>> This means that the OAM processor at port D loses its capacity. >>>> If we consider the larger number of ports in the LSR which has 100 >>>> ports, for example, All OAM MIP packets for out-MIPs port(B, C) are >>>> sent to all out-MIPs. >>>> This means that the OAM processors at the other 98 ports lose those >>>> capacities. >>>> Even if your solution using ACH header is applied, it can reduce OAM >>>> packets only for in-MIP, which means only 1/101 effectiveness in the >>>> case of P2MP for 100 ports. >>>>=20 >>>> Thanks, >>>> Hideki Endo >>>>=20 >>>>=20 >>>>> Rolf, >>>>>=20 >>>>> For clarity it is better to use an example. Assume that an LSR has >> 4 >>>> ports (A, B, C, D). Now assume that it receives packets on a >> unicast >>>> LSP-X from port A and forwards them to port B. there can only be 3 >>>> configurations: >>>>>=20 >>>>> 1) MIP on port A (In-MIP), or >>>>> 2) MIP on port B (out-MIP), or >>>>> 3) MEIP on Port A and B >>>>>=20 >>>>> A single OAM packet can be terminated and processed only by one of >>>> these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID >>>> =3Dport B). In your example, you are saying send a copy of the P to >> the >>>> CPU/Processor on Port A, and send a copy also to CPU/Processor on >>>> Port B. Port A CPU will drop the packet since the MIP-ID is not A. >>>> The issue is that each CPU/processor has limited resources. By >>>> sending all OAM MIP packets to both processor you are losing 1/2 of >>>> the capacity of each processor. The practical solution is to have a >>>> simple indicator in the packet header that this OAM packet is meant >>>> for Out-MIP. Then port A just switches the OAM packet to Port B, and >>>> Port B terminates and sends it to its CPU/processor. >>>>>=20 >>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters >> the >>>> chip from Port A and is sent to ports B, C, D. Also assume that >>>> there is In-MIP on port A and out-MIPs of ports B, C (not D). Now >>>> assume a Multicast OAM packet is meant for out-MIPs (B, C). In such >>>> case the OAM packet should not be sent to port A CPU/Processor. It >> is >>>> therefore multicast to ports B, C, D. Ports B, C send the OAM packet >> to their CPU. >>>> Port D drops the OAM packets and does not send it to its CPU, since >>>> there is no MIP configured for that MPLS label. >>>>>=20 >>>>> So the Pseudo-code is like this: >>>>>=20 >>>>> Ingress Port: >>>>>=20 >>>>> If packet is OAM and TTL=3D1 >>>>> If MIP is enabled >>>>> If packet indicates In-MIP >>>>> Send to local CPU >>>>> Else >>>>> Forward to egress port >>>>> End >>>>> Else >>>>> Forward normally >>>>> End >>>>> Else >>>>>=20 >>>>> Egress Port: >>>>>=20 >>>>> If packet is OAM and TTL=3D1 >>>>> If MIP is enabled >>>>> If packet indicates In-MIP >>>>> Drop packet >>>>> Else If packet indicates Out-MIP >>>>> Send to local CPU >>>>> End >>>>> Else >>>>> Drop packet >>>>> End >>>>> End >>>>>=20 >>>>>=20 >>>>> Using this example could you please describe your reasoning for not >>>> requiring HW to identify In-MEP vs out-MIPs? >>>>>=20 >>>>> Thanks >>>>> Shahram >>>>>=20 >>>>> -----Original Message----- >>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>> To: Shahram Davari >>>>> Cc: Pablo Frank; mpls@ietf.org >>>>> Subject: RE: [mpls] working group last call on >>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>=20 >>>>> But the MIP that is addressed needs to be able to handle this >> _plus_ >>>> take an appropriate action and in the P2MP case this will always be >>>> the case since there are 2 or more out MIPs. >>>>>=20 >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>> London W3 6BL | Registered in England 2832014 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>> To: Rolf Winter >>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>> Subject: Re: [mpls] working group last call on >>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>=20 >>>>>> Hi Rolf, >>>>>>=20 >>>>>> Your HW guys are correct as long as the amount of data sent to the >>>>>> in- MIP processor is not much. But from your previous email to Loa >>>>>> I see that you want to also terminate CV at MIPs. CVs are fast and >>>> high >>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that >>>>>> may not be expecting them is like DoS attack. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Shahram >>>>>>=20 >>>>>>=20 >>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>> wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> sorry for the belated response. I checked with some of our HW >>>> people. >>>>>> Here's the gist of their response: >>>>>>>=20 >>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>> fact already. Their answer to the problem is slightly different >>>> though. >>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the >>>>>> out- MIPs where, if the frame is not intended for them, it can >>>> safely >>>>>> be dropped. In the P2MP case e.g. this needs to be done anyway, >> i.e. >>>>>> the implementation must behave in this exact way in either case. >> So >>>>>> there is at least one way to implement this at line rate without >>>>>> going back and changing a bunch of RFCs. >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Rolf >>>>>>>=20 >>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>> Behalf Of Shahram Davari >>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>> To: Pablo Frank >>>>>>>> Cc: mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>=20 >>>>>>>> Pablo, >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP >> or >>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Thx >>>>>>>> Shahram >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>> To: Shahram Davari >>>>>>>> Cc: mpls@ietf.org >>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I think Shahram raises a very legitimate concern about how >>>>>>>> expensive this could be to implement in hardware. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> As I understand it, the logic proposed by this draft is as >>>> follows: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> At the ingress blade: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>=20 >>>>>>>> Parse MIP-ID TLV >>>>>>>>=20 >>>>>>>> Lookup MIP-ID >>>>>>>>=20 >>>>>>>> IF MIP-is-egress, THEN >>>>>>>>=20 >>>>>>>> forward normally (but note we must intercept it again on >>>>>> egress) >>>>>>>>=20 >>>>>>>> ELSE >>>>>>>>=20 >>>>>>>> punt to OAM processor >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> At the egress blade: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>=20 >>>>>>>> Parse MIP-ID TLV >>>>>>>>=20 >>>>>>>> Lookup MIP-ID >>>>>>>>=20 >>>>>>>> IF MIP-is-egress, THEN >>>>>>>>=20 >>>>>>>> punt to OAM processor >>>>>>>>=20 >>>>>>>> ELSE >>>>>>>>=20 >>>>>>>> drop >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Note all this has to be done in the fast-path now at full line >>>>>>>> rate (and hardware guys hate TLVs). Before, the only thing the >>>>>>>> fast-path had to do was look for TTL-expiry. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix >>>>>>>> A.4 of >>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>> Ideally, hardware could rely on the reserved bit to do the >>>> initial >>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID >> lookup. >>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> regards, >>>>>>>>=20 >>>>>>>> Pablo >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Rolf, >>>>>>>>>=20 >>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And >>>> I >>>>>>>> think you agree with me that this draft requires deep parsing of >>>>>>>> all packets at line rate to get to the MIPID TLV. >>>>>>>>>=20 >>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>> OAM >>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For >>>>>>>> example how about using one of the reserved bits in the ACH >>>>>>>> header. This >>>>>> can >>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Shahram >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>> On >>>>>>>> Behalf Of Rolf Winter >>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>> Cc: mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>> draft-ietf-mpls- tp-mip-mep-map >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>>> Hi Adrian, >>>>>>>>>>=20 >>>>>>>>>> You are right and I should have sent these types of >>>> comments >>>>>>>> before >>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>=20 >>>>>>>>>> One thing I didn't understand in your response is that you >>>>>> said >>>>>>>> in-MIP >>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>> that? >>>>>>>>>>=20 >>>>>>>>>> My understanding is that before this draft, the process >>>>>>>> would have >>>>>>>>>> been for the ingress to look at TTL and if it is expired >>>>>>>> then send the >>>>>>>>>> packet to OAM processor. >>>>>>>>>=20 >>>>>>>>> Yes (and no). While I assume likely MIP functionality will >>>> be >>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>> (RFC >>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an >>>>>>>> unspecified location within the node)". >>>>>>>>>=20 >>>>>>>>> Also, I think "before this draft" is not quite accurate in >>>>>>>> that is suggests there is no per-interface MIP addressing >>>> possible >>>>>>>> as of >>>>>> now. >>>>>>>> Take RFC 6426. In practice this is where part of the problem >> lies. >>>>>> We >>>>>>>> cannot really go back and change all this. There are other >>>>>> constraints. >>>>>>>> E.g. we have a requirement to address a single out-MIP out of a >>>>>>>> set of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>> constraints we worked with. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>> filtering >>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup >>>>>>>> of the MEPID >>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>> indicator to >>>>>>>>>> the OAM packet to indicate whether it should be taken out >>>> of >>>>>>>> the data >>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>=20 >>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>=20 >>>>>>>>>> " In addition to the MEPID, which is used to ultimately >>>>>>>> accept or >>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>> simple >>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>> in-MIP or >>>>>>>>>> Out-MIP". >>>>>>>>>=20 >>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like >>>>>>>> to have to do a second lookup, since it would require some >>>>>>>> parsing. All these constraints and the ones outlined in the >>>>>>>> document led to where we are. In a sense this is a non-spec >> since >>>>>>>> it rather rules out a number of things that seem like a good >> idea >>>>>>>> at first but then have a catch of some sort. >>>>>>>>>=20 >>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>> Rolf >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Shahram >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> >>>>>>>>>>>=20 >>>>>>>>>>> Hi Shahram, >>>>>>>>>>>=20 >>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>> during >>>>>>>> WG >>>>>>>>>> last call. >>>>>>>>>>> While comments that improve the document or point out >>>>>>>> fundamental >>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>> flavour "I >>>>>>>>>>> wouldn't have done it like this" that arrive this late in >>>>>>>> the process >>>>>>>>>> don't feel very constructive. >>>>>>>>>>> But I will leave the chair to worry about process and try >>>>>>>> to address >>>>>>>>>>> the technical points... >>>>>>>>>>>=20 >>>>>>>>>>>> Identifying whether to terminate an OAM packet and >>>> process >>>>>> it >>>>>>>> in In- >>>>>>>>>> MIP vs. >>>>>>>>>>> Out- >>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet >>>>>>>> will not >>>>>>>>>> take >>>>>>>>>>>> the same path as data packets. Therefore any MIP >>>>>>>> identifier that is >>>>>>>>>>>> proposed in this >>>>>>>>>>> draft >>>>>>>>>>>> requires one extra lookup and therefore adds >>>> significantly >>>>>> to >>>>>>>> cost. >>>>>>>>>>>=20 >>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>> decide to >>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow >>>>>>>> exactly the >>>>>>>>>> same >>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>> interface >>>>>>>>>>> inspects the packets (at line >>>>>>>>>>> rate) to determine whether they are OAM and targeted at >>>> the >>>>>>>> interface. >>>>>>>>>>>=20 >>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>> the >>>>>>>> lookup >>>>>>>>>>> as easy as possible. >>>>>>>>>>>=20 >>>>>>>>>>>> Perhaps a >>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>> Level) may be >>>>>>>>>>>> used that requires only 3 bits and achieves the same >>>> result. >>>>>>>>>>>=20 >>>>>>>>>>> Perhaps it could. >>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>> version of >>>>>>>>>>> the I-D arduous? >>>>>>>>>>>=20 >>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>> In-MIPs >>>>>>>>>> are >>>>>>>>>>> currently identified, so the lookups being done at line >>>>>>>> rate today on >>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>> proposing >>>>>>>>>> such >>>>>>>>>>> a change, then the discussion is outside the scope of this >>>>>>>> I- D and >>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>=20 >>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>> lookup on >>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>> both >>>>>>>>>>> interfaces. My assumption was that if the incoming >>>>>>>> interface can do >>>>>>>>>>> the lookup at line rate, it is not hard to perform the >>>> same >>>>>>>> lookup on >>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction >>>> in >>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>=20 >>>>>>>>>>> Another possibility is that the full lookup could be done >>>>>>>> on the >>>>>>>>>>> incoming interface and the packet marked for easy >>>>>> interception >>>>>>>> on the >>>>>>>>>> outgoing interface. >>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>> longer be >>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>> modified in >>>>>>>>>> flight. >>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>> the >>>>>>>> packet >>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>> needed. >>>>>>>>>>>=20 >>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>> progressed, >>>>>>>>>>> and some of the alternative solutions were tracked with >>>>>>>> their pros >>>>>>>>>> and >>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Adrian >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls- >>>> bounces@ietf.org] >>>>>> On >>>>>>>> Behalf >>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>> ; >>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>=20 >>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>> anything >>>>>>>>>> else? >>>>>>>>>>>>=20 >>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>> were >>>>>>>> saying >>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>> backward >>>>>>>>>> compatible". >>>>>>>>>>>>=20 >>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>=20 >>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>> hoc >>>>>>>>>>> team; >>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>=20 >>>>>>>>>>>>> After getting to section 6 and its features >>>>>>>> (requirements!), I find >>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it >>>> is >>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title >>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>> [Handling >>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a >>>> more >>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>> definition of >>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the >>>> document >>>>>>>> says The >>>>>>>>>>>>> preferred solution to per-interface MIP message handling >>>> is >>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> s1 >>>>>>>>>>>>> two (or more) MIPs per node on both sides of the >>>>>>>> forwarding engine. >>>>>>>>>>>>> [two on both sides sounds like four in total to me; >>>>>>>> suggest 'one on >>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> s4 >>>>>>>>>>>>> o CV between a MEP and a MIP [expand CV on first use] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> s5 >>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] >>>>>>>> for MPLS-TP >>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>> precedents, >>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>> for >>>>>>>> LSPs, >>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>> sentence >>>>>>>> as >>>>>>>>>>>>> redundant] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> s6 >>>>>>>>>>>>> The appendix of this document contains a few solutions that >>>>>>>>>>>>> the authors have discarded which >>>> have >>>>>>>> been >>>>>>>>>> left in >>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The node itself is addresses [The node itself is addressed] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The identification information indside [The >>>> identification >>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> MIP identifiers are not know [MIP identifiers are not >> known] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>> To: >>>>>>>>>>>>> Cc: ; >>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>> >>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>> mailing >>>>>>>> list >>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please send both technical comments, and if you are >>>>>>>> happy with the >>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>=20 >>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 >>>> Victoria >>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Tue Dec 4 07:05:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54FA21F8BDF for ; Tue, 4 Dec 2012 07:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.356 X-Spam-Level: X-Spam-Status: No, score=-5.356 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jICGAqjVgjBD for ; Tue, 4 Dec 2012 07:05:34 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id B2A4521F8BDC for ; Tue, 4 Dec 2012 07:05:34 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 07:00:57 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 07:05:23 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 07:05:02 -0800 From: "Shahram Davari" To: "hideki.endo.es@hitachi.com" Thread-Topic: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0jC87BnsjwXIzU2iy6kxY4cyEQ== Date: Tue, 4 Dec 2012 15:05:02 +0000 Message-ID: <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CA0CFA339W5126659-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 15:05:37 -0000 Hideki, The whole point of this draft has been to ensure OAM packets addressed to o= ut-MIP reach to the egress ports and are not filtered by in-MIP. And a sing= le bit does that work. Efficiency is an internal matter to the box: " This document describes a way of forming OAM messages so that they can be= targeted at incoming MIPs and outgoing MIPs, forwarded correctly through t= he "switch fabric", and handled efficiently in node implementations where t= here is no distinction between the incoming and outgoing MIP." It makes me wonder Have you implemented this feature or just doing a resear= ch exercise? I as a chip architect have hard time implementing this feature= . This is a fact, and you can choose to ignore it. Regards, Shahram On Dec 4, 2012, at 3:49 AM, "hideki.endo.es@hitachi.com" wrote: > Shahram, >=20 > You replied to Rolf in other mail; > "For in-MIP a single bit is enough. However for out-MIP > the CPU has to drop the unwanted OAM. Not efficient but > the system still works. " > Yes, that's right. > This was my point. >=20 > Again, even if your solution using ACH header is applied, > it can reduce OAM packets only for in-MIP, which means only 1/101 effecti= veness > in the case of P2MP tree having 100 leafs. >=20 > Thanks, > Hideki Endo >=20 >=20 >> I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" wrote: >>=20 >>> Sharhram, >>>=20 >>> I didn't mean new requirement similar to Figure 7. >>> I do think that OAM packets must go through the normal forwarding engin= e >>> without bypass. >>>=20 >>> As Rolf said in other e-mail, >>> -------------------------- >>> | -----| >>> | | MIP1| >>> | ->-| |->---- >>> | | | Out | >>> | | | i/f | >>> | | -----| >>> |----- | -----| >>> | MIP0| ---- | | MIP2| >>> | | | |- | | >>> ----->-| In |->-| FW |--->-| Out |->---- >>> | i/f | | |- | i/f | >>> |----- ---- | -----| >>> | | -----| >>> | | | MIP3| >>> | | | | >>> | ->-| Out |->---- >>> | | i/f | >>> | -----| >>> -------------------------- >>> The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 i= n the P2MP tree individually. >>> Here, each out-MIP has different MIP ID. >>> If you don't need this machanism, >>> how does a out-MIP verify whether the OAM packet is sent to the out-MIP= or not?=20 >>>=20 >>> Thanks, >>> Hideki Endo >>>=20 >>>=20 >>>> Hideki, >>>>=20 >>>> In summary your requirement is similar to Figure 7 , where you are goi= ng to bypass the normal forwarding engine and do unicast forwarding of a m= ulticast OAM packet to a single outgoing port. This kind of behavior is = explicitly rejected in the draft. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: >>>>=20 >>>>> Hi Hideki, >>>>>=20 >>>>> I think we have a fundamental problem statement difference. Based on = your examples I think you are looking in to how to send an OAM packet only = to a single out-MIP out of Nxout-MIPs in a P2MP LSP. >>>>>=20 >>>>> But I don't think this is architecturally sound or even required. Ima= gine there is no in-MIP at all. We want a multicast OAM packet behaves like= a data packet and be replicated to all egress ports. Now if a MIP is confi= gured in say 2 of the egress ports and not the other 98 ones, then the 98 e= gress ports will drop the OAM packet in HW and won't send them to their CPU= . For the other 2 ports with Out-MIP, both will send the packets to their C= PU and both CPUs have to process and respond such as with link trace reply = or Loopback reply, etc. >>>>>=20 >>>>>=20 >>>>> Regards, >>>>> Shahram >>>>>=20 >>>>>=20 >>>>> On Dec 3, 2012, at 5:24 PM, wrote: >>>>>=20 >>>>>> Hi Shahram, >>>>>>=20 >>>>>> Back and forth. >>>>>> Here, let's focus on whether using MIP ID requires unnecessarily par= sing in HW or not. >>>>>>=20 >>>>>>> I think you need to look at my p-code. F a MIP is not configured in= the Egress port, then that egress port won't sent the OAM packet to its pr= ocessor and drops it. So there is no issue with my proposed method. >>>>>> Don't you consider the case when MIPs is configured in the Egress po= rt B,C and D? >>>>>> In the case of P2MP, we need to identify the only one out-MIP of the= se out-MIPs in port B,C and D. >>>>>> In that case, your solution has low effectiveness as I pointed out. >>>>>> Do I miss something? >>>>>>=20 >>>>>> Thanks, >>>>>> Hideki Endo >>>>>>=20 >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Using MIP ID as the only method to filter OAM packets to CPU/Proces= sor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC637= 4 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MI= P ID as the only identifier requires unnecessarily parsing of all these dif= ferent packet types at line rate in HW. >>>>>>>=20 >>>>>>> Why not just use a simple bit in the ACH header? We need a n indica= tor in a fixed location or the solution is not going to be practical in HW. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Shahram >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Shahram Davari=20 >>>>>>> Sent: Monday, December 03, 2012 4:53 PM >>>>>>> To: 'hideki.endo.es@hitachi.com' >>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mp= ls-tp-mip-mep-map >>>>>>>=20 >>>>>>> Hi Hideki, >>>>>>>=20 >>>>>>> I think you need to look at my p-code. F a MIP is not configured in= the Egress port, then that egress port won't sent the OAM packet to its pr= ocessor and drops it. So there is no issue with my proposed method. >>>>>>>=20 >>>>>>> Thx >>>>>>> Shahram >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com= ]=20 >>>>>>> Sent: Monday, December 03, 2012 4:48 PM >>>>>>> To: Shahram Davari >>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-t= p-mip-mep-map >>>>>>>=20 >>>>>>> Hi Shahram, >>>>>>>=20 >>>>>>> First, as Rolf sent, we need in/out-MIP for >>>>>>> 1. CV between a MEP and a MIP >>>>>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing M= IPs >>>>>>> 3. data-plane loopback configuration at a MIP >>>>>>> 4. diagnostic tests >>>>>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>>>>>=20 >>>>>>> Second, you wrote; >>>>>>> "The issue is that each CPU/processor has limited resources.=20 >>>>>>> By sending all OAM MIP packets to both processor you are=20 >>>>>>> losing 1/2 of the capacity of each processor. " >>>>>>> It depends on implementations, >>>>>>> and this issue could NOT be resolved by even your solution that use= s ACH header to indicate in/out-MIP. >>>>>>> Let's consider P2MP case as you pointed out. >>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIP= s. >>>>>>> This means that the OAM processor at port D loses its capacity. >>>>>>> If we consider the larger number of ports in the LSR which has 100 = ports, for example, >>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIP= s. >>>>>>> This means that the OAM processors at the other 98 ports lose those= capacities. >>>>>>> Even if your solution using ACH header is applied, >>>>>>> it can reduce OAM packets only for in-MIP, which means only 1/101 e= ffectiveness >>>>>>> in the case of P2MP for 100 ports. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Hideki Endo >>>>>>>=20 >>>>>>>=20 >>>>>>>> Rolf, >>>>>>>>=20 >>>>>>>> For clarity it is better to use an example. Assume that an LSR has= 4 ports (A, B, C, D). Now assume that it receives packets on a unicast L= SP-X from port A and forwards them to port B. there can only be 3 configu= rations: >>>>>>>>=20 >>>>>>>> 1) MIP on port A (In-MIP), or >>>>>>>> 2) MIP on port B (out-MIP), or >>>>>>>> 3) MEIP on Port A and B >>>>>>>>=20 >>>>>>>> A single OAM packet can be terminated and processed only by one of= these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =3Dport = B). In your example, you are saying send a copy of the P to the CPU/Process= or on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU w= ill drop the packet since the MIP-ID is not A. The issue is that each CPU/= processor has limited resources. By sending all OAM MIP packets to both pr= ocessor you are losing 1/2 of the capacity of each processor. The practica= l solution is to have a simple indicator in the packet header that this OAM= packet is meant for Out-MIP. Then port A just switches the OAM packet to P= ort B, and Port B terminates and sends it to its CPU/processor. >>>>>>>>=20 >>>>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters t= he chip from Port A and is sent to ports B, C, D. Also assume that there i= s In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multi= cast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet = should not be sent to port A CPU/Processor. It is therefore multicast to po= rts B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the = OAM packets and does not send it to its CPU, since there is no MIP configur= ed for that MPLS label. >>>>>>>>=20 >>>>>>>> So the Pseudo-code is like this: >>>>>>>>=20 >>>>>>>> Ingress Port: >>>>>>>>=20 >>>>>>>> If packet is OAM and TTL=3D1 >>>>>>>> If MIP is enabled >>>>>>>> If packet indicates In-MIP >>>>>>>> Send to local CPU >>>>>>>> Else >>>>>>>> Forward to egress port >>>>>>>> End >>>>>>>> Else >>>>>>>> Forward normally >>>>>>>> End >>>>>>>> Else >>>>>>>>=20 >>>>>>>> Egress Port: >>>>>>>>=20 >>>>>>>> If packet is OAM and TTL=3D1 >>>>>>>> If MIP is enabled >>>>>>>> If packet indicates In-MIP >>>>>>>> Drop packet >>>>>>>> Else If packet indicates Out-MIP >>>>>>>> Send to local CPU >>>>>>>> End >>>>>>>> Else >>>>>>>> Drop packet >>>>>>>> End >>>>>>>> End >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Using this example could you please describe your reasoning for no= t requiring HW to identify In-MEP vs out-MIPs? >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Shahram >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]=20 >>>>>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>>>>> To: Shahram Davari >>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-= mip-mep-map >>>>>>>>=20 >>>>>>>> But the MIP that is addressed needs to be able to handle this _plu= s_ take an appropriate action and in the P2MP case this will always be the = case since there are 2 or more out MIPs. >>>>>>>>=20 >>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road= , London W3 6BL | Registered in England 2832014=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>>>>> To: Rolf Winter >>>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp= -mip- >>>>>>>>> mep-map >>>>>>>>>=20 >>>>>>>>> Hi Rolf, >>>>>>>>>=20 >>>>>>>>> Your HW guys are correct as long as the amount of data sent to th= e in- >>>>>>>>> MIP processor is not much. But from your previous email to Loa I = see >>>>>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>>>>> bandwidth and blindly dumping them on a CPU or OAM processor tha= t may >>>>>>>>> not be expecting them is like DoS attack. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Shahram >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> sorry for the belated response. I checked with some of our HW pe= ople. >>>>>>>>> Here's the gist of their response: >>>>>>>>>>=20 >>>>>>>>>> Of course they wouldn't like parsing TLVs but we established tha= t >>>>>>>>> fact already. Their answer to the problem is slightly different t= hough. >>>>>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the= out- >>>>>>>>> MIPs where, if the frame is not intended for them, it can safely = be >>>>>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e.= the >>>>>>>>> implementation must behave in this exact way in either case. So t= here >>>>>>>>> is at least one way to implement this at line rate without going = back >>>>>>>>> and changing a bunch of RFCs. >>>>>>>>>>=20 >>>>>>>>>> Best, >>>>>>>>>>=20 >>>>>>>>>> Rolf >>>>>>>>>>=20 >>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Ro= ad, >>>>>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On B= ehalf >>>>>>>>>>> Of Shahram Davari >>>>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>>>>> To: Pablo Frank >>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>=20 >>>>>>>>>>> Pablo, >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP = or >>>>>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Thx >>>>>>>>>>> Shahram >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>>>>> To: Shahram Davari >>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I think Shahram raises a very legitimate concern about how expe= nsive >>>>>>>>>>> this could be to implement in hardware. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> As I understand it, the logic proposed by this draft is as foll= ows: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> At the ingress blade: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>=20 >>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>=20 >>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>=20 >>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>=20 >>>>>>>>>>> forward normally (but note we must intercept it again on >>>>>>>>> egress) >>>>>>>>>>>=20 >>>>>>>>>>> ELSE >>>>>>>>>>>=20 >>>>>>>>>>> punt to OAM processor >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> At the egress blade: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>=20 >>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>=20 >>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>=20 >>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>=20 >>>>>>>>>>> punt to OAM processor >>>>>>>>>>>=20 >>>>>>>>>>> ELSE >>>>>>>>>>>=20 >>>>>>>>>>> drop >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Note all this has to be done in the fast-path now at full line = rate >>>>>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast= -path >>>>>>>>>>> had to do was look for TTL-expiry. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix= A.4 >>>>>>>>>>> of >>>>>>>>>>> -03 version of doc) was because it also required a MIP-ID looku= p. >>>>>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>>>>> Ideally, hardware could rely on the reserved bit to do the init= ial >>>>>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID look= up. >>>>>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> This seems like a case where practicality should trump elegance= . >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> regards, >>>>>>>>>>>=20 >>>>>>>>>>> Pablo >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Rolf, >>>>>>>>>>>>=20 >>>>>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>>>>> think you agree with me that this draft requires deep parsing o= f all >>>>>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>>>>>=20 >>>>>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>>>>> OAM >>>>>>>>>>> packet ended up at the right MIP. But may be a simpler solutio= n >>>>>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For ex= ample >>>>>>>>>>> how about using one of the reserved bits in the ACH header. Th= is >>>>>>>>> can >>>>>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Shahram >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>>>>> Behalf Of Rolf Winter >>>>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls= - >>>>>>>>>>> tp-mip-mep-map >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Adrian, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>>>>> before >>>>>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> One thing I didn't understand in your response is that you >>>>>>>>> said >>>>>>>>>>> in-MIP >>>>>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>>>>> that? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> My understanding is that before this draft, the process woul= d >>>>>>>>>>> have >>>>>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>>>>> send the >>>>>>>>>>>>> packet to OAM processor. >>>>>>>>>>>>=20 >>>>>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>>>>> implemented on the ingress, the related RFCs are vague about th= e >>>>>>>>>>> actual placement of the MIP function. See e.g. the OAM Framewor= k >>>>>>>>> (RFC >>>>>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspeci= fied >>>>>>>>>>> location within the node)". >>>>>>>>>>>>=20 >>>>>>>>>>>> Also, I think "before this draft" is not quite accurate in tha= t >>>>>>>>>>> is suggests there is no per-interface MIP addressing possible a= s of >>>>>>>>> now. >>>>>>>>>>> Take RFC 6426. In practice this is where part of the problem li= es. >>>>>>>>> We >>>>>>>>>>> cannot really go back and change all this. There are other >>>>>>>>> constraints. >>>>>>>>>>> E.g. we have a requirement to address a single out-MIP out of a= set >>>>>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>>>>> constraints we worked with. >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>>>>> filtering >>>>>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>>>>> the MEPID >>>>>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>>>>> indicator to >>>>>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>>>>> the data >>>>>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> " In addition to the MEPID, which is used to ultimately accep= t >>>>>>>>>>> or >>>>>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>>>>> simple >>>>>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>>>>> in-MIP or >>>>>>>>>>>>> Out-MIP". >>>>>>>>>>>>=20 >>>>>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>>>>> assume a TLV wouldn't work for the exact reasons you do not lik= e to >>>>>>>>>>> have to do a second lookup, since it would require some parsing= . All >>>>>>>>>>> these constraints and the ones outlined in the document led to = where >>>>>>>>>>> we are. In a sense this is a non-spec since it rather rules out= a >>>>>>>>>>> number of things that seem like a good idea at first but then h= ave a >>>>>>>>>>> catch of some sort. >>>>>>>>>>>>=20 >>>>>>>>>>>> Best, >>>>>>>>>>>>=20 >>>>>>>>>>>> Rolf >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Shahram >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Shahram, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>>>>> during >>>>>>>>>>> WG >>>>>>>>>>>>> last call. >>>>>>>>>>>>>> While comments that improve the document or point out >>>>>>>>>>> fundamental >>>>>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>>>>> flavour "I >>>>>>>>>>>>>> wouldn't have done it like this" that arrive this late in th= e >>>>>>>>>>> process >>>>>>>>>>>>> don't feel very constructive. >>>>>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>>>>> address >>>>>>>>>>>>>> the technical points... >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>>>>> it >>>>>>>>>>> in In- >>>>>>>>>>>>> MIP vs. >>>>>>>>>>>>>> Out- >>>>>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet wil= l >>>>>>>>>>> not >>>>>>>>>>>>> take >>>>>>>>>>>>>>> the same path as data packets. Therefore any MIP identifie= r >>>>>>>>>>> that is >>>>>>>>>>>>>>> proposed in this >>>>>>>>>>>>>> draft >>>>>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>>>>> to >>>>>>>>>>> cost. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>>>>> decide to >>>>>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactl= y >>>>>>>>>>> the >>>>>>>>>>>>> same >>>>>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>>>>> interface >>>>>>>>>>>>>> inspects the packets (at line >>>>>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>>>>> interface. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>>>>> the >>>>>>>>>>> lookup >>>>>>>>>>>>>> as easy as possible. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Perhaps a >>>>>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>>>>> Level) may be >>>>>>>>>>>>>>> used that requires only 3 bits and achieves the same result= . >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Perhaps it could. >>>>>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>>>>> version of >>>>>>>>>>>>>> the I-D arduous? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>>>>> In-MIPs >>>>>>>>>>>>> are >>>>>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>>>>> today on >>>>>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>>>>> proposing >>>>>>>>>>>>> such >>>>>>>>>>>>>> a change, then the discussion is outside the scope of this I= - >>>>>>>>>>> D and >>>>>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>>>>> lookup on >>>>>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>>>>> both >>>>>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>>>>> can do >>>>>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>>>>> lookup on >>>>>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>>>>> the >>>>>>>>>>>>>> incoming interface and the packet marked for easy >>>>>>>>> interception >>>>>>>>>>> on the >>>>>>>>>>>>> outgoing interface. >>>>>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>>>>> longer be >>>>>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>>>>> modified in >>>>>>>>>>>>> flight. >>>>>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>>>>> the >>>>>>>>>>> packet >>>>>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>>>>> needed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>>>>> progressed, >>>>>>>>>>>>>> and some of the alternative solutions were tracked with thei= r >>>>>>>>>>> pros >>>>>>>>>>>>> and >>>>>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>>>>> On >>>>>>>>>>> Behalf >>>>>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>> ; >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>>>>> anything >>>>>>>>>>>>> else? >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>>>>> were >>>>>>>>>>> saying >>>>>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>>>>> backward >>>>>>>>>>>>> compatible". >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>>>>> hoc >>>>>>>>>>>>>> team; >>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> After getting to section 6 and its features (requirements!= ), >>>>>>>>>>> I find >>>>>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it i= s >>>>>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Title >>>>>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>>>>> [Handling >>>>>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a mor= e >>>>>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>>>>> definition of >>>>>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>>>>> says The >>>>>>>>>>>>>>>> preferred solution to per-interface MIP message handling i= s >>>>>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> s1 >>>>>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwardin= g >>>>>>>>>>> engine. >>>>>>>>>>>>>>>> [two on both sides sounds like four in total to me; sugges= t >>>>>>>>>>> 'one on >>>>>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> s4 >>>>>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> s5 >>>>>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] fo= r >>>>>>>>>>> MPLS-TP >>>>>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>>>>> precedents, >>>>>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>>>>> for >>>>>>>>>>> LSPs, >>>>>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>>>>> sentence >>>>>>>>>>> as >>>>>>>>>>>>>>>> redundant] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> s6 >>>>>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>>>>> been >>>>>>>>>>>>> left in >>>>>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>>>>> To: >>>>>>>>>>>>>>>> Cc: ; >>>>>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>>>>> mailing >>>>>>>>>>> list >>>>>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>>>>> with the >>>>>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>=20 >>>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> mpls mailing list >>>>>>>>>>> mpls@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Tue Dec 4 14:55:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C9A21F8BBB; Tue, 4 Dec 2012 14:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcoQkSMDd-oC; Tue, 4 Dec 2012 14:55:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8858721F8BA3; Tue, 4 Dec 2012 14:55:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121204225554.5789.35775.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2012 14:55:54 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:55:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Kamran Raza Filename : draft-ietf-mpls-ldp-multi-topology-06.txt Pages : 19 Date : 2012-12-04 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-multi-topology-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From davari@broadcom.com Tue Dec 4 14:57:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447DE21F8BD4 for ; Tue, 4 Dec 2012 14:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be5TAQwOripv for ; Tue, 4 Dec 2012 14:57:42 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 62C3E21F8BD3 for ; Tue, 4 Dec 2012 14:57:42 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 04 Dec 2012 14:54:46 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 4 Dec 2012 14:57:34 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 4 Dec 2012 14:57:13 -0800 From: "Shahram Davari" To: "mpls@ietf.org" Thread-Topic: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0jC87BnsjwXIzU2iy6kxY4cyEZgJOIig Date: Tue, 4 Dec 2012 22:57:12 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BD39C6A@SJEXCHMB12.corp.ad.broadcom.com> References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> , <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> In-Reply-To: <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CA0A0BC3R014833376-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 22:57:43 -0000 Hi MPLS WG, I would like to summarize our discussion and let the WG decide. 1) The draft requires MIPID to be used by the HW in the Ingress port to sel= ect whether an OAM packet should be sent to CPU for processing or be forwar= ded to egress port(s).=20 2) The draft requires MIPID to be used by the HW in Egress port to select w= hether an OAM packet should be sent to CPU for processing or dropped. 3) The draft solution applies to P2P and P2MP MPLS, and is efficient, meani= ng that it sends OAM packets only to the CPUs that need to be used for proc= essing. And does not overload CPUs that don't need to receive an OAM packet= . 4) The draft solution requires parsing the OAM packets to get to the MIPID = TLV. There are many types of OAM messages with different format (BFD, LSP-P= ing, APS, RFC6374, etc.) and the TLV can be anywhere in the packet. This ma= kes the draft solution not practical to implement in HW, and therefore not = widely deployed. ------------------------------------------------ 5) My proposal is to use a single bit in the ACH to indicate whether the O= AM packet is for in-MIP or out-MIP. This single bit is used by HW in the i= ngress port to select whether an OAM packet should be sent to CPU for proce= ssing or be forwarded to egress port(s). When packet is sent to CPU, then t= he MIPID can be used by CPU to double check that it has received the expect= ed OAM packet. 6) My proposal is for an egress port to send the OAM packet to CPU, if a MI= P is configured on that port, (otherwise drop it in HW. When packet is sent= to CPU, then the MIPID can be used by CPU to double check that it has rece= ived the expected OAM packet. 7) My solution applies to P2P MPLS (which is more than 95% of the LSPs, PW= s) efficiently, meaning that it sends OAM packets only to the CPUs that nee= d to be used for processing. And does not overload CPUs that don't need to = receive an OAM packet. 8) My solution applies to P2MP MPLS (which is less than 5% of the LSPs, PW= s) but NOT efficiently, meaning that it sends OAM packets to the CPUs that = don't need to process the OAM and overloads some CPUs that don't need to re= ceive an OAM packet. The question in front of the WG is which solution to pick. My argument is t= hat although the draft solution is a theoretically a perfect solution but i= s not practical and may never get implemented widely. While my solution is= perfect for more than 95% of the LSPs (P2P LSPs) and is in-efficient for l= ess than 5% of the LSPs (P2MP LSPs). However it is simple and trivial to im= plement in HW. You choose ! This is my last argument email justifying my proposed solution. Thanks, Shahram From gregory.mirsky@ericsson.com Tue Dec 4 15:15:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA57E21F8B99 for ; Tue, 4 Dec 2012 15:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ1jPjV-+NP5 for ; Tue, 4 Dec 2012 15:15:19 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2C121F8AF8 for ; Tue, 4 Dec 2012 15:15:19 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qB4NFHZb014251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Dec 2012 17:15:17 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Dec 2012 18:15:17 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 18:15:17 -0500 From: Gregory Mirsky To: Rolf Winter , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0VxJlaR5XVhT/UaZmQSyL/75l5gHYOjwgAB15ID//6/AQIABFS8AgACovIA= Date: Tue, 4 Dec 2012 23:15:16 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11201F537eusaamb103ericsso_" MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 23:15:20 -0000 --_000_7347100B5761DC41A166AC17F22DF11201F537eusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, I'll think that per MEG MIPs, even though they are on the same LSP/PW, in M= PLS-TP, IMHO, belong in fact to different MEG Levels, hence different SPMEs= . If such interpretation is acceptable, then we can have multiple MIPs but = only one MIP per MEG Level (even though no such construct was introduced in= MPLS-TP OAM model, unfortunately IMHO). And I think that distinction, if any, between in-, out- and nodal MIP shoul= d not be required for unidirectional MPLS-TP constructs as it is not practi= cal since Loopback mode can not be exercised as there's no return path via = data plane. Thus examples with p2mp scenarios are not applicable, IMHO, to = this discussion. Regards, Greg -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] Sent: Tuesday, December 04, 2012 12:00 AM To: Gregory Mirsky; mpls@ietf.org Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map Hi Greg, you might not be convinced but there are operators that have asked for this= functionality based on operational experience. Quoting the OAM framework RFC: " Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets." Clearly having multiple MIPs per LSP is allowed as per the OAM framework. I= think however the sentence "All the intermediate nodes and possibly the en= d nodes host MIP(s)" should really be ""All the intermediate nodes and poss= ibly the end nodes can host MIP(s)" (Is this worth filing an errata?). I do= n't see why one wants to arbitrarily restrict the number of MIPs per LSP. B= TW, as you mention, the support of multiple MIPs in Ethernet is optional. Q= uoting the OAM framework again: "Support of per-interface or per-node MIPs is an implementation choice." So where's the difference? Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Montag, 3. Dezember 2012 21:47 > To: Rolf Winter; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map > > Hi Rolf, > I've been thinking about that requirement for some time and am not > convinced that such requirement, support multiple MIP per LSP/PW on > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single > MIP per MD/MEG Level is required and support of multiple MIPs is optional= . > True, multiple MIPs of different MD/MEG Levels might be enabled on a > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus such > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat- > plane loopback can be used on uni-directional construct. > > Regards, > Greg > > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > ] > Sent: Monday, December 03, 2012 12:15 PM > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > mpls-tp-mip-mep-map@tools.ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map > > Hi Greg, > > But that's the whole point of the document. There can be multiple in- > and out-MIPs per LSP plus in the P2MP case there can be multiple out- > MIPs per node. It cannot be based local configuration. There has to be > information inside the OAM frame to address the respective MIP. > Section > 4 of the document has a (I believe) pretty good example of this. > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > ] > > Sent: Montag, 3. Dezember 2012 19:20 > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Rolf, > > Do you envision that multiple MIPs, both in- and out-, required to be > > supported on a given LSP/PW? I think that only single MIP > required > > per LSP/PW on an LSR/PE node. If that is the case, then there might > be > > no apparent need to explicitly address in- and out- MIP as such > > distinction becomes part of local configuration. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org > > ] On Behalf Of Rolf Winter > > Sent: Monday, December 03, 2012 5:42 AM > > To: Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp- > mip- > > mep-map > > > > Loa, > > > > These have been mentioned: > > > > 1. CV between a MEP and a MIP > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > MIPs > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.nu ] > > > Sent: Freitag, 30. November 2012 11:41 > > > To: mpls@ietf.org > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > > mpls-ads@tools.ietf.org > > > Subject: Re: working group last call on > > > draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Authors, > > > > > > Can you plese give me an indication of which OAM functions the > > > separation of in and out MIPs are intended for? > > > > > > /Loa > > > > > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > > > Working Group, > > > > > > > > This is to start a 2 week working group last call on > > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > > > Please send your comments to the mpls working group mailing list > > > > (mpls@ietf.org). > > > > > > > > Please send both technical comments, and if you are happy with > the > > > > document as is also indications of support. > > > > > > > > This working group last call will end on November 28. > > > > > > > > /Loa > > > > for the wg co-chairs > > > > > > > > > > > > > > -- > > > > > > > > > Loa Andersson email: > > loa.andersson@ericsson.com > > > Sr Strategy and Standards Manager loa@pi.nu > > > Ericsson Inc phone: +46 10 717 52 13 > > > +46 767 72 92 13 > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > --_000_7347100B5761DC41A166AC17F22DF11201F537eusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rolf,
I'll think that per MEG MIPs, even though they are on the same LSP/PW,= in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence different = SPMEs. If such interpretation is acceptable, then we can have multiple MIPs= but only one MIP per MEG Level (even though no such construct was introduced in MPLS-TP OAM model, unfortu= nately IMHO).
And I think that distinction, if any, between in-, out- and nodal MIP = should not be required for unidirectional MPLS-TP constructs as it is not p= ractical since Loopback mode can not be exercised as there's no return path= via data plane. Thus examples with p2mp scenarios are not applicable, IMHO, to this discussion.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Tuesday, December 04, 2012 12:00 AM
To: Gregory Mirsky; mpls@ietf.org
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map=
 
Hi Greg,
 
you might not be convinced but there are operators that have asked for= this functionality based on operational experience.
 
Quoting the OAM framework RFC:
 
" Once a MEG is configured, the operator can enable/disable the M= IPs on
   the nodes within the MEG.  All the intermediate node= s and possibly
   the end nodes host MIP(s).  Local policy allows them= to be enabled
   per function and per MEG.  The local policy is contr= olled by the
   management system, which may delegate it to the control p= lane.  A
   disabled MIP silently discards any received OAM packets.&= quot;
 
Clearly having multiple MIPs per LSP is allowed as per the OAM framewo= rk. I think however the sentence "All the intermediate nodes and possi= bly the end nodes host MIP(s)" should really be ""All the in= termediate nodes and possibly the end nodes can host MIP(s)" (Is this worth filing an errata?). I don't see why one wants t= o arbitrarily restrict the number of MIPs per LSP. BTW, as you mention, the= support of multiple MIPs in Ethernet is optional. Quoting the OAM framewor= k again:
 
"Support of per-interface or per-node MIPs is an implementation c= hoice."
 
So where's the difference?
 
Best,
 
Rolf
 
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
 
 
> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Montag, 3. Dezember 2012 21:47
> To: Rolf Winter; Loa Andersson; mpls@ietf.org
> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ie= tf-
> mpls-tp-mip-mep-map@tools.ietf.org
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-me= p-map
>
> Hi Rolf,
> I've been thinking about that requirement for some time and am no= t
> convinced that such requirement, support multiple MIP per LSP/PW = on
> given LSR/PE, exists. AFAIK, in Ethernet OAM only support of sing= le
> MIP per MD/MEG Level is required and support of multiple MIPs is = optional.
> True, multiple MIPs of different MD/MEG Levels might be enabled o= n a
> node but in MPLS-TP we use SPME to model MD/MEG Levels and thus s= uch
> MIPs are on different LSPs. As for p2mp case, I'm not sure how da= t-
> plane loopback can be used on uni-directional construct.
>
>         Regards,
>           =       Greg
>
> -----Original Message-----
> Sent: Monday, December 03, 2012 12:15 PM
> To: Gregory Mirsky; Loa Andersson; mpls@ietf.org
> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ie= tf-
> mpls-tp-mip-mep-map@tools.ietf.org
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-me= p-map
>
> Hi Greg,
>
> But that's the whole point of the document. There can be multiple= in-
> and out-MIPs per LSP plus in the P2MP case there can be multiple = out-
> MIPs per node. It cannot be based local configuration. There has = to be
> information inside the OAM frame to address the respective MIP. <= /div>
> Section
> 4 of the document has a (I believe) pretty good example of this.<= /div>
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d,
> London W3 6BL | Registered in England 2832014
>
>
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com
> > <mailto:gregory.mirsky@ericsson.com> ]
> > Sent: Montag, 3. Dezember 2012 19:20
> > To: Rolf Winter; Loa Andersson; mpls@ietf.org
> > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; dra= ft-ietf-
> > mpls-tp-mip-mep-map@tools.ietf.org
> > Subject: RE: working group last call on draft-ietf-mpls-tp-m= ip-mep-
> map
> >
> > Hi Rolf,
> > Do you envision that multiple MIPs, both in- and out-, requi= red to be
> > supported on a given LSP/PW? I think that   &= nbsp; only single MIP
> required
> > per LSP/PW on an LSR/PE node. If that is the case, then ther= e might
> be
> > no apparent need to explicitly address in- and out- MIP as s= uch
> > distinction becomes part of local configuration.
> >
> >        Regards,
> >          &= nbsp;     Greg
> >
> > -----Original Message-----
> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org
> > <mailto:mpls-bounces@ietf.org> ] On Behalf Of Rol= f Winter
> > Sent: Monday, December 03, 2012 5:42 AM
> > To: Loa Andersson; mpls@ietf.org
> > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; dra= ft-ietf-
> > mpls-tp-mip-mep-map@tools.ietf.org
> > Subject: Re: [mpls] working group last call on draft-ietf-mp= ls-tp-
> mip-
> > mep-map
> >
> > Loa,
> >
> > These have been mentioned:
> >
> > 1. CV between a MEP and a MIP
> > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW conta= ining
> MIPs
> > 3. data-plane loopback configuration at a MIP 4. diagnostic = tests
> >
> > Best,
> >
> > Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victori= a Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: Loa Andersson [mailto:loa@pi.nu <mailto:loa@pi.nu> ]
> > > Sent: Freitag, 30. November 2012 11:41
> > > To: mpls@ietf.org
> > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux;
> > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org;
> > > mpls-ads@tools.ietf.org
> > > Subject: Re: working group last call on
> > > draft-ietf-mpls-tp-mip-mep-
> > map
> > >
> > > Authors,
> > >
> > > Can you plese give me an indication of which OAM functi= ons the
> > > separation of in and out MIPs are intended for?
> > >
> > > /Loa
> > >
> > >
> > >
> > > On 2012-11-14 16:16, Loa Andersson wrote:
> > > >
> > > > Working Group,
> > > >
> > > > This is to start a 2 week working group last call = on
> > > > draft-ietf-mpls-tp-mip-mep-map.
> > > >
> > > > Please send your comments to the mpls working grou= p mailing list
> > > > (mpls@ietf.org).
> > > >
> > > > Please send both technical comments, and if you ar= e happy with
> the
> > > > document as is also indications of support.
> > > >
> > > > This working group last call will end on November = 28.
> > > >
> > > > /Loa
> > > > for the wg co-chairs
> > > >
> > > >
> > >
> > > --
> > >
> > >
> > > Loa Andersson       =             &nb= sp;     email:
> > loa.andersson@ericsson.com
> > > Sr Strategy and Standards Manager   &nbs= p;        loa@pi.nu
> > > Ericsson Inc       &= nbsp;           &nbs= p;      phone: +46 10 717 52 13
> > >         &n= bsp;            = ;            &n= bsp;            += ;46 767 72 92 13
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
>
 
--_000_7347100B5761DC41A166AC17F22DF11201F537eusaamb103ericsso_-- From marc@sniff.de Tue Dec 4 15:50:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B521F8BB2; Tue, 4 Dec 2012 15:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STxlYa-rzE8Q; Tue, 4 Dec 2012 15:50:02 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8421F8BB0; Tue, 4 Dec 2012 15:50:01 -0800 (PST) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 0F4F62AA0F; Tue, 4 Dec 2012 23:49:56 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16-548157397 From: Marc Binderberger In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> Date: Wed, 5 Dec 2012 00:49:55 +0100 Message-Id: <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> To: Shahram Davari , Gregory Mirsky , "Santiago Alvarez (saalvare)" , Sam Aldrin X-Mailer: Apple Mail (2.1084) Cc: mpls@ietf.org, rtg-bfd@ietf.org, pwe3@ietf.org Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 23:50:03 -0000 --Apple-Mail-16-548157397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Sam, Santiago, Gregory, Sharam et al., thanks for the feedback. Input from the MPLS and PWE3 list is welcome = regarding important timer values for which we would like to have a = common support. Few comments from my side: I can live with an informal document, at least with respect to the = "standard intervals". The document shall help to improve = interoperability and even an informal document can become de-facto = standard when customers request it ;-) There is the aspect of the multiple poll/final sequences to find the = next common interval. I think it is covered by RFC5880 but this = statement may require more discussion on the BFD list. If not covered = then we would need a standard, I think. We will not make any reference to Y.1731 in the text but where intervals = we proposed are close to Y.1731 intervals I'm fine to adjust to Y.1731 = values, which may make a combined "OAM hardware" simpler/cheaper. We list the following values in the draft -03 version o 3.3msec: required by MPLS-TP o 10msec and 20msec: both values allow to detect faster than 50msec, when used with a multiplier of 2 or 3 (for 10msec). A compromise could be a single interval of 15msec. o 50msec: this seems an interval often supported by software implementations, so the assumption here is that for convenience this value should be supported. o 300msec: this would support large scale of 3 x 300msec setups used by customers to have a detection time slightly below 1sec for VoIP setups. o 1sec: as mentioned in RFC5880 We also discussed some time ago that the 300msec could be replaced by = 100msec intervals but this still needs more discussion. And the lower = interval range 10-50msec, especially 10-20msec, I personally tend to = have more "standard values" than less, providing more common intervals = between hardware based BFD and software based BFD; it is at least my = impression that in this range most software-based implementations have = their lower limit and the more common intervals the easier we can = support 50-60msec detect+restore even with software-based BFD (10msec = may just push the limit, 100msec is obviously too slow). This is vague beside the 3.3msec and 1sec, so again if good reasons = exist for specific values from the MPLS, MPLS-TP and PWE3 standards or = applications: input is very welcome! Thanks & Regards, Marc On 2012-12-03, at 20:53 , Sam Aldrin wrote: > I echo what Santiago had said in his email. Good to have an = informational document and do not support the idea of standardizing the = intervals. >=20 > -sam > On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" = wrote: >=20 >> Applicability of BFD is pretty wide. Mandating a set of intervals = driven by Y.1731 doesn=92t sound like a good idea to me. Having lived = through most of the BFD CC interop testing in the context of MPLS-TP, I = can see some value in having an informational doc that would discuss = interval configuration and interoperability. >> Cheers. >> =20 >> SA >> -- >> =20 >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Gregory Mirsky >> Sent: Monday, December 03, 2012 11:33 AM >> To: Marc Binderberger; Shahram Davari >> Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org >> Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >> =20 >> Dear Shahram, Marc, et al., >> I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and = PWE3 WGs have a stake in this discussion. >> I agree that compatibility with intervals standardized for Ether OAM = (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll = note that even with the same transmission intervals failure detection in = BFD-based CC/CV and Ether OAM is different time interval. Not by much = but different nevertheless. >> And I agree with Marc that BFD-based CC is not only for packet or = Ethernet transport applications. And more values of transmission = interval are useful. That is why I believe that we should not = standardize any values, at least not on Standard Track. At most it could = be an informational document. Or, which will be great, have a survey = among providers on what interval values being used (similar to great = survey on PWE VCCV Control Channels). >> =20 >> Regards, >> Greg >> =20 >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Marc Binderberger >> Sent: Monday, December 03, 2012 11:08 AM >> To: Shahram Davari >> Cc: rtg-bfd@ietf.org >> Subject: Re: Commenst on draft-akiya-bfd-intervals-03 >>=20 >> Hello Shahram, >> =20 >> thanks for re-vitalizing this discussion - must admit I was busy with = too many other things. >> =20 >> I do agree with including the values you mention in the list of BFD = supported values, although I question the large values. >> =20 >> On the other hand: we are not re-inventing Ethernet OAM and we _have_ = BFD implementations out there. So we likely need to support other values = as well to fit into the existing world. >> =20 >> =20 >> Regards, Marc >> =20 >> =20 >> =20 >> =20 >> =20 >> On 2012-12-03, at 20:02 , Shahram Davari wrote: >>=20 >>=20 >> Hi, >> I would like to propose standardizing the same intervals as = Y.1731/802.1ag for BFD. This would make the total L2, L3 OAM more = homogeneous. So the proposal is: >> 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min. >> Thank you, >> Shharam >> =20 >> -- >> Marc Binderberger >> =20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 -- Marc Binderberger --Apple-Mail-16-548157397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Sam, Santiago, Gregory, Sharam et al.,

thanks for the = feedback. Input from the MPLS and PWE3 list is welcome regarding = important timer values for which we would like to have a common = support.

Few comments from my = side:

I can live with an informal document, at = least with respect to the "standard intervals". The document shall help = to improve interoperability and even an informal document can become = de-facto standard when customers request it = ;-)

There is the aspect of the multiple = poll/final sequences to find the next common interval. I think it is = covered by RFC5880 but this statement may require more discussion on the = BFD list. If not covered then we would need a standard, I = think.

We will not make any reference to Y.1731 = in the text but where intervals we proposed are close to Y.1731 = intervals I'm fine to adjust to Y.1731 values, which may make a combined = "OAM hardware" = simpler/cheaper.


We list the = following values in the draft -03 = version

   o  3.3msec: = required by MPLS-TP

   o  10msec = and 20msec: both values allow to detect faster than = 50msec,
      when used with a multiplier of 2 = or 3 (for 10msec).  A compromise
      = could be a single interval of 15msec.

  =  o  50msec: this seems an interval often supported by = software
      implementations, so the = assumption here is that for convenience
      = this value should be supported.

   o =  300msec: this would support large scale of 3 x 300msec setups = used
      by customers to have a detection = time slightly below 1sec for VoIP
      = setups.

   o  1sec: as mentioned = in RFC5880


We also = discussed some time ago that the 300msec could be replaced by 100msec = intervals but this still needs more discussion. And the lower interval = range 10-50msec, especially 10-20msec, I personally tend to have more = "standard values" than less, providing more common intervals between = hardware based BFD and software based BFD; it is at least my impression = that in this range most software-based implementations have their lower = limit and the more common intervals the easier we can support 50-60msec = detect+restore even with software-based BFD (10msec may just push the = limit, 100msec is obviously too = slow).


This is vague beside the = 3.3msec and 1sec, so again if good reasons exist for specific values = from the MPLS, MPLS-TP and PWE3 standards or applications: input is very = welcome!


Thanks & = Regards,
Marc



=

On 2012-12-03, at 20:53 , Sam Aldrin wrote:

I echo what Santiago had said = in his email. Good to have an informational document and do not support = the idea of standardizing the = intervals.

-sam
On Dec 3, 2012, at 11:48 = AM, "Santiago Alvarez (saalvare)" <saalvare@cisco.com> = wrote:

Applicability of BFD is = pretty wide.  Mandating a set of intervals driven by Y.1731 doesn=92t= sound like a good idea to me.  Having lived through most of the = BFD CC interop testing in the context of MPLS-TP, I can see some value = in having an informational doc that would discuss interval configuration = and interoperability.
Cheers.
 
--
 
 mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: Monday, December 03, 2012 = 11:33 AM
To: Marc Binderberger; Shahram = Davari
Cc: mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] Commenst on = draft-akiya-bfd-intervals-03
 
Dear Shahram, Marc, et al.,
I think that since BFD is the CC/CV part of = MPLS-TP OAM both MPLS and PWE3 WGs have a stake in this = discussion.
I agree that compatibility with intervals standardized for Ether = OAM (CFM/Y.1731) makes sense and might be helpful in interworking. But = I'll note that even with the same transmission intervals failure = detection in BFD-based CC/CV and Ether OAM is different time interval. = Not by much but different nevertheless.
And I agree with Marc that BFD-based CC is = not only for packet or Ethernet transport applications. And more values = of transmission interval are useful. That is why I believe that we = should not standardize any values, at least not on Standard Track. At = most it could be an informational document. Or, which will be great, = have a survey among providers on what interval values being used = (similar to great survey on PWE VCCV Control = Channels).
        = Greg

 rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc = Binderberger
Sent: Monday, December 03, 2012 = 11:08 AM
To: Shahram = Davari
Cc:  Re: Commenst on = draft-akiya-bfd-intervals-03



--
Marc Binderberger         =   <marc@sniff.de>

= --Apple-Mail-16-548157397-- From hideki.endo.es@hitachi.com Tue Dec 4 16:58:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D221F8BBB for ; Tue, 4 Dec 2012 16:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zx4BmG7pVVB for ; Tue, 4 Dec 2012 16:58:11 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C08921F8A8B for ; Tue, 4 Dec 2012 16:58:11 -0800 (PST) Received: from mlsv5.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 0DB7637AC3; Wed, 5 Dec 2012 09:58:10 +0900 (JST) Received: from mfilter04.hitachi.co.jp by mlsv5.hitachi.co.jp (8.13.1/8.13.1) id qB50wAsA006903; Wed, 5 Dec 2012 09:58:10 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB50w9vF022310; Wed, 5 Dec 2012 09:58:09 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id EEEC0490059; Wed, 5 Dec 2012 09:58:08 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB50w8e8286286; Wed, 5 Dec 2012 09:58:08 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Wed, 5 Dec 2012 09:57:53 +0900 References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD39C6A@SJEXCHMB12.corp.ad.broa> Priority: normal Importance: normal X400-Content-Identifier: X50BE9BE500000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121205095709SPM] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 00:58:12 -0000 Shahram, I think that your summarize is misleading. Our draft does NOT require MIP ID to be parse by the HW. It depends on your implementation. As Rolf replied to you, we have several options, i.e., a TTL-expired OAM frame can simply be copied and forwarded to the out-MIPs where, if the frame is not intended for them, it can safely be dropped. Although you have concern about losing some resources of an OAM processor due to unnecessary OAM packets, even your proposal using ACH header have low effectiveness in case of P2MP tree having many leaves as you said below and I pointed out in other email. Thanks, Hideki Endo > Hi MPLS WG, > >I would like to summarize our discussion and let the WG decide. > >1) The draft requires MIPID to be used by the HW in the Ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). > >2) The draft requires MIPID to be used by the HW in Egress port to select whether an OAM packet should be sent to CPU for processing or dropped. > >3) The draft solution applies to P2P and P2MP MPLS, and is efficient, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet. > >4) The draft solution requires parsing the OAM packets to get to the MIPID TLV. There are many types of OAM messages with different format (BFD, LSP-Ping, APS, RFC6374, etc.) and the TLV can be anywhere in the packet. This makes the draft solution not practical to implement in HW, and therefore not widely deployed. > >------------------------------------------------ > >5) My proposal is to use a single bit in the ACH to indicate whether the OAM packet is for in-MIP or out-MIP. This single bit is used by HW in the ingress port to select whether an OAM packet should be sent to CPU for processing or be forwarded to egress port(s). When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet. > >6) My proposal is for an egress port to send the OAM packet to CPU, if a MIP is configured on that port, (otherwise drop it in HW. When packet is sent to CPU, then the MIPID can be used by CPU to double check that it has received the expected OAM packet. > >7) My solution applies to P2P MPLS (which is more than 95% of the LSPs, PWs) efficiently, meaning that it sends OAM packets only to the CPUs that need to be used for processing. And does not overload CPUs that don't need to receive an OAM packet. > >8) My solution applies to P2MP MPLS (which is less than 5% of the LSPs, PWs) but NOT efficiently, meaning that it sends OAM packets to the CPUs that don't need to process the OAM and overloads some CPUs that don't need to receive an OAM packet. > > >The question in front of the WG is which solution to pick. My argument is that although the draft solution is a theoretically a perfect solution but is not practical and may never get implemented widely. While my solution is perfect for more than 95% of the LSPs (P2P LSPs) and is in-efficient for less than 5% of the LSPs (P2MP LSPs). However it is simple and trivial to implement in HW. > >You choose ! > >This is my last argument email justifying my proposed solution. > >Thanks, >Shahram > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From lizhong.jin@zte.com.cn Tue Dec 4 17:12:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3709521F8BD9 for ; Tue, 4 Dec 2012 17:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.496 X-Spam-Level: X-Spam-Status: No, score=-100.496 tagged_above=-999 required=5 tests=[AWL=2.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+iouz8k-eBM for ; Tue, 4 Dec 2012 17:12:22 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5585221F8BE2 for ; Tue, 4 Dec 2012 17:12:22 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8BF001921D46 for ; Wed, 5 Dec 2012 09:12:11 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 02F58183AA2B; Wed, 5 Dec 2012 09:10:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB51C7lM022202; Wed, 5 Dec 2012 09:12:07 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: <50BDD83C.8010209@cisco.com> To: stbryant@cisco.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Wed, 5 Dec 2012 09:11:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-05 09:12:05, Serialize complete at 2012-12-05 09:12:05 Content-Type: multipart/alternative; boundary="=_alternative 00069CC648257ACB_=" X-MAIL: mse02.zte.com.cn qB51C7lM022202 Cc: mpls@ietf.org Subject: Re: [mpls] wg last call on ethernet-addressing drafts X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 01:12:23 -0000 This is a multipart message in MIME format. --=_alternative 00069CC648257ACB_= Content-Type: text/plain; charset="US-ASCII" Hi Stewart, That's much better. Thanks Lizhong Stewart Bryant wrote 2012/12/04 19:02:20: > On 23/10/2012 03:32, Lizhong Jin wrote: > > > > 2. For the "Ethernet Interface Parameters" application, is it > > allowed to apply GAP Request, Flush or Suppress message specified in > > [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address. > > Yes if it makes sense in your application. I can see that you might > > for example suppress the MAC address refresh and rely on your peer > > to over-ride the request if the address changed. > > > > I am not sure why this needs clarification since the Ethernet draft > > inherits the rules of the GAP protocol. > [Lizhong] in section 4, all the description is for application > "0x0001", while the request/suppress message in [I-D.ietf-mpls-gach- > adv] is for application "0x0000". > e.g, "This document defines a new GAP application, "Ethernet > Interface Parameters", to support the advertisement of Ethernet- > specific parameters associated with the sending interface." > It seems the procedure in section 4 only inherits the GAP message, > but not GAP application "0x0000". It would be good have some > description to say, the GAP application "0x0000" could be also > applied to this draft. > Lizhong > > How about if we add to the GAP draft (immediately before section 4.1) > > "Any application using the GAP inherits the ability to use > facilities provide by Application 0x0000." > > Stewart --=_alternative 00069CC648257ACB_= Content-Type: text/html; charset="US-ASCII"
Hi Stewart,
That's much better. Thanks

Lizhong
 

Stewart Bryant <stbryant@cisco.com> wrote 2012/12/04 19:02:20:

> On 23/10/2012 03:32, Lizhong Jin wrote:
>
>
> > 2. For the "Ethernet Interface Parameters" application, is it
> > allowed to apply GAP Request, Flush or Suppress message specified in
> > [I-D.ietf-mpls-gach-adv]? E.g, to use GAP Request to request MAC address.
> > Yes if it makes sense in your application. I can see that you might
> > for example suppress the MAC address refresh and rely on your peer
> > to over-ride the request if the address changed.
> >
> > I am not sure why this needs clarification since the Ethernet draft
> > inherits the rules of the GAP protocol.
> [Lizhong] in section 4, all the description is for application
> "0x0001", while the request/suppress message in [I-D.ietf-mpls-gach-
> adv] is for application "0x0000".
> e.g, "This document defines a new GAP application, "Ethernet
> Interface Parameters", to support the advertisement of Ethernet-
> specific parameters associated with the sending interface."
> It seems the procedure in section 4 only inherits the GAP message,
> but not GAP application "0x0000". It would be good have some
> description to say, the GAP application "0x0000" could be also
> applied to this draft.
> Lizhong
>
> How about if we add to the GAP draft (immediately before section 4.1)
>
> "Any application using the GAP inherits the ability to use
> facilities provide by Application 0x0000."
>
> Stewart
 --=_alternative 00069CC648257ACB_=-- From hideki.endo.es@hitachi.com Tue Dec 4 18:08:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0210B21F8BB4 for ; Tue, 4 Dec 2012 18:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ud-Skk166yM for ; Tue, 4 Dec 2012 18:08:48 -0800 (PST) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6965821F8BB2 for ; Tue, 4 Dec 2012 18:08:47 -0800 (PST) Received: from mlsv4.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 6CE8537ACA; Wed, 5 Dec 2012 11:08:46 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv4.hitachi.co.jp (8.13.1/8.13.1) id qB528kJG008035; Wed, 5 Dec 2012 11:08:46 +0900 Received: from hitachi.com (localhost.localdomain [127.0.0.1]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB528iHZ023860; Wed, 5 Dec 2012 11:08:46 +0900 Received: from vshuts01.hitachi.co.jp ([vshuts01.hitachi.co.jp [10.201.6.83]]) by mfilter05.hitachi.co.jp with RELAY id qB528jio023869 ; Wed, 5 Dec 2012 11:08:46 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 0BED22F008E; Wed, 5 Dec 2012 11:08:45 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB528it13459500; Wed, 5 Dec 2012 11:08:44 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Wed, 5 Dec 2012 11:08:30 +0900 References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> Priority: normal Importance: normal X400-Content-Identifier: X50BEAC7A00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml281212051107543DD] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working grouplastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 02:08:50 -0000 Shahram, Yes, this issue is an internal matter to the box as you said, and I have some experiences to implement this feature in commercial products. Therefore, I initially had same concern as you. We, the authors of this draft, requested the fixed location of MIP ID TLV or using ACH header. However, as Rolf sent to you, in that case, we would need to go back and make changes to a few RFCs. That was also something people weren't really happy about. And, I have understood this issue can be resolved by an optimized implementation. As Rolf sent, we need this feature for some functions as below; 1. CV between a MEP and a MIP 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs 3. data-plane loopback configuration at a MIP 4. diagnostic tests In these functions, 1(On-demand CV) and 2(traceroute) would be very slow rate protocol. Therefor, it is possible for OAM processor/CPU to parse TLVs. On the other hand, 3(data-plane loopback) and 4(diagnostic tests) would be very fast rate protocol. It means that these function should be implemented in specific HW with capacity to parse MIP ID TLV at line rate. If your proposal using ACH header is applied, the specific HW parsing MIP ID TLV at line rate is required for these functions, right? Thanks, Hideki Endo >Hideki, > >The whole point of this draft has been to ensure OAM packets addressed to out-MIP reach to the egress ports and are not filtered by in-MIP. And a single bit does that work. Efficiency is an internal matter to the box: > >" This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP." > > >It makes me wonder Have you implemented this feature or just doing a research exercise? I as a chip architect have hard time implementing this feature. This is a fact, and you can choose to ignore it. > > > >Regards, >Shahram > > >On Dec 4, 2012, at 3:49 AM, "hideki.endo.es@hitachi.com" wrote: > >> Shahram, >> >> You replied to Rolf in other mail; >> "For in-MIP a single bit is enough. However for out-MIP >> the CPU has to drop the unwanted OAM. Not efficient but >> the system still works. " >> Yes, that's right. >> This was my point. >> >> Again, even if your solution using ACH header is applied, >> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >> in the case of P2MP tree having 100 leafs. >> >> Thanks, >> Hideki Endo >> >> >>> I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU. >>> >>> Regards, >>> Shahram >>> >>> >>> On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" wrote: >>> >>>> Sharhram, >>>> >>>> I didn't mean new requirement similar to Figure 7. >>>> I do think that OAM packets must go through the normal forwarding engine >>>> without bypass. >>>> >>>> As Rolf said in other e-mail, >>>> -------------------------- >>>> | -----| >>>> | | MIP1| >>>> | ->-| |->---- >>>> | | | Out | >>>> | | | i/f | >>>> | | -----| >>>> |----- | -----| >>>> | MIP0| ---- | | MIP2| >>>> | | | |- | | >>>> ----->-| In |->-| FW |--->-| Out |->---- >>>> | i/f | | |- | i/f | >>>> |----- ---- | -----| >>>> | | -----| >>>> | | | MIP3| >>>> | | | | >>>> | ->-| Out |->---- >>>> | | i/f | >>>> | -----| >>>> -------------------------- >>>> The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually. >>>> Here, each out-MIP has different MIP ID. >>>> If you don't need this machanism, >>>> how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? >>>> >>>> Thanks, >>>> Hideki Endo >>>> >>>> >>>>> Hideki, >>>>> >>>>> In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding engine and do unicast forwarding of a multicast OAM packet to a single outgoing port. This kind of behavior is explicitly rejected in the draft. >>>>> >>>>> Regards, >>>>> Shahram >>>>> >>>>> >>>>> On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: >>>>> >>>>>> Hi Hideki, >>>>>> >>>>>> I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP. >>>>>> >>>>>> But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Shahram >>>>>> >>>>>> >>>>>> On Dec 3, 2012, at 5:24 PM, wrote: >>>>>> >>>>>>> Hi Shahram, >>>>>>> >>>>>>> Back and forth. >>>>>>> Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not. >>>>>>> >>>>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>>>> Don't you consider the case when MIPs is configured in the Egress port B,C and D? >>>>>>> In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D. >>>>>>> In that case, your solution has low effectiveness as I pointed out. >>>>>>> Do I miss something? >>>>>>> >>>>>>> Thanks, >>>>>>> Hideki Endo >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW. >>>>>>>> >>>>>>>> Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shahram >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Shahram Davari >>>>>>>> Sent: Monday, December 03, 2012 4:53 PM >>>>>>>> To: 'hideki.endo.es@hitachi.com' >>>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>> >>>>>>>> Hi Hideki, >>>>>>>> >>>>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>>>>> >>>>>>>> Thx >>>>>>>> Shahram >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>>>>>> Sent: Monday, December 03, 2012 4:48 PM >>>>>>>> To: Shahram Davari >>>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>> >>>>>>>> Hi Shahram, >>>>>>>> >>>>>>>> First, as Rolf sent, we need in/out-MIP for >>>>>>>> 1. CV between a MEP and a MIP >>>>>>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >>>>>>>> 3. data-plane loopback configuration at a MIP >>>>>>>> 4. diagnostic tests >>>>>>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>>>>>> >>>>>>>> Second, you wrote; >>>>>>>> "The issue is that each CPU/processor has limited resources. >>>>>>>> By sending all OAM MIP packets to both processor you are >>>>>>>> losing 1/2 of the capacity of each processor. " >>>>>>>> It depends on implementations, >>>>>>>> and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. >>>>>>>> Let's consider P2MP case as you pointed out. >>>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>>>> This means that the OAM processor at port D loses its capacity. >>>>>>>> If we consider the larger number of ports in the LSR which has 100 ports, for example, >>>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>>>> This means that the OAM processors at the other 98 ports lose those capacities. >>>>>>>> Even if your solution using ACH header is applied, >>>>>>>> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >>>>>>>> in the case of P2MP for 100 ports. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hideki Endo >>>>>>>> >>>>>>>> >>>>>>>>> Rolf, >>>>>>>>> >>>>>>>>> For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: >>>>>>>>> >>>>>>>>> 1) MIP on port A (In-MIP), or >>>>>>>>> 2) MIP on port B (out-MIP), or >>>>>>>>> 3) MEIP on Port A and B >>>>>>>>> >>>>>>>>> A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. >>>>>>>>> >>>>>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. >>>>>>>>> >>>>>>>>> So the Pseudo-code is like this: >>>>>>>>> >>>>>>>>> Ingress Port: >>>>>>>>> >>>>>>>>> If packet is OAM and TTL=1 >>>>>>>>> If MIP is enabled >>>>>>>>> If packet indicates In-MIP >>>>>>>>> Send to local CPU >>>>>>>>> Else >>>>>>>>> Forward to egress port >>>>>>>>> End >>>>>>>>> Else >>>>>>>>> Forward normally >>>>>>>>> End >>>>>>>>> Else >>>>>>>>> >>>>>>>>> Egress Port: >>>>>>>>> >>>>>>>>> If packet is OAM and TTL=1 >>>>>>>>> If MIP is enabled >>>>>>>>> If packet indicates In-MIP >>>>>>>>> Drop packet >>>>>>>>> Else If packet indicates Out-MIP >>>>>>>>> Send to local CPU >>>>>>>>> End >>>>>>>>> Else >>>>>>>>> Drop packet >>>>>>>>> End >>>>>>>>> End >>>>>>>>> >>>>>>>>> >>>>>>>>> Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Shahram >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>>>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>>>>>> To: Shahram Davari >>>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>>> >>>>>>>>> But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. >>>>>>>>> >>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>>>>>> To: Rolf Winter >>>>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>>>>>>>>> mep-map >>>>>>>>>> >>>>>>>>>> Hi Rolf, >>>>>>>>>> >>>>>>>>>> Your HW guys are correct as long as the amount of data sent to the in- >>>>>>>>>> MIP processor is not much. But from your previous email to Loa I see >>>>>>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>>>>>>>>> not be expecting them is like DoS attack. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Shahram >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> sorry for the belated response. I checked with some of our HW people. >>>>>>>>>> Here's the gist of their response: >>>>>>>>>>> >>>>>>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>>>>>> fact already. Their answer to the problem is slightly different though. >>>>>>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>>>>>>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>>>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>>>>>>>> implementation must behave in this exact way in either case. So there >>>>>>>>>> is at least one way to implement this at line rate without going back >>>>>>>>>> and changing a bunch of RFCs. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> >>>>>>>>>>> Rolf >>>>>>>>>>> >>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>>>>>>>>> Of Shahram Davari >>>>>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>>>>>> To: Pablo Frank >>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>> >>>>>>>>>>>> Pablo, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thx >>>>>>>>>>>> Shahram >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>>>>>> To: Shahram Davari >>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think Shahram raises a very legitimate concern about how expensive >>>>>>>>>>>> this could be to implement in hardware. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At the ingress blade: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>> >>>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>> >>>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>> >>>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>> >>>>>>>>>>>> forward normally (but note we must intercept it again on >>>>>>>>>> egress) >>>>>>>>>>>> >>>>>>>>>>>> ELSE >>>>>>>>>>>> >>>>>>>>>>>> punt to OAM processor >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> At the egress blade: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>> >>>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>> >>>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>> >>>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>> >>>>>>>>>>>> punt to OAM processor >>>>>>>>>>>> >>>>>>>>>>>> ELSE >>>>>>>>>>>> >>>>>>>>>>>> drop >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-path >>>>>>>>>>>> had to do was look for TTL-expiry. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>>>>>>>> of >>>>>>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> regards, >>>>>>>>>>>> >>>>>>>>>>>> Pablo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Rolf, >>>>>>>>>>>>> >>>>>>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>>>>>> think you agree with me that this draft requires deep parsing of all >>>>>>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>>>>>> >>>>>>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>>>>>> OAM >>>>>>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For example >>>>>>>>>>>> how about using one of the reserved bits in the ACH header. This >>>>>>>>>> can >>>>>>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Shahram >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Rolf Winter >>>>>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>>>>>>> tp-mip-mep-map >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Adrian, >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>>>>>> before >>>>>>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One thing I didn't understand in your response is that you >>>>>>>>>> said >>>>>>>>>>>> in-MIP >>>>>>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>>>>>> that? >>>>>>>>>>>>>> >>>>>>>>>>>>>> My understanding is that before this draft, the process would >>>>>>>>>>>> have >>>>>>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>>>>>> send the >>>>>>>>>>>>>> packet to OAM processor. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>>>>>> (RFC >>>>>>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>>>>>>>> location within the node)". >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>>>>>>> is suggests there is no per-interface MIP addressing possible as of >>>>>>>>>> now. >>>>>>>>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>>>>>>>> We >>>>>>>>>>>> cannot really go back and change all this. There are other >>>>>>>>>> constraints. >>>>>>>>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>>>>>> constraints we worked with. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>>>>>> filtering >>>>>>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>>>>>> the MEPID >>>>>>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>>>>>> indicator to >>>>>>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>>>>>> the data >>>>>>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>>>>> >>>>>>>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>>>>>>> or >>>>>>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>>>>>> simple >>>>>>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>>>>>> in-MIP or >>>>>>>>>>>>>> Out-MIP". >>>>>>>>>>>>> >>>>>>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>>>>>>>> have to do a second lookup, since it would require some parsing. All >>>>>>>>>>>> these constraints and the ones outlined in the document led to where >>>>>>>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>>>>>>> number of things that seem like a good idea at first but then have a >>>>>>>>>>>> catch of some sort. >>>>>>>>>>>>> >>>>>>>>>>>>> Best, >>>>>>>>>>>>> >>>>>>>>>>>>> Rolf >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Shahram >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Shahram, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>>>>>> during >>>>>>>>>>>> WG >>>>>>>>>>>>>> last call. >>>>>>>>>>>>>>> While comments that improve the document or point out >>>>>>>>>>>> fundamental >>>>>>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>>>>>> flavour "I >>>>>>>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>>>>>>> process >>>>>>>>>>>>>> don't feel very constructive. >>>>>>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>>>>>> address >>>>>>>>>>>>>>> the technical points... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>>>>>> it >>>>>>>>>>>> in In- >>>>>>>>>>>>>> MIP vs. >>>>>>>>>>>>>>> Out- >>>>>>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>>>>>>> not >>>>>>>>>>>>>> take >>>>>>>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>>>>>>> that is >>>>>>>>>>>>>>>> proposed in this >>>>>>>>>>>>>>> draft >>>>>>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>>>>>> to >>>>>>>>>>>> cost. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>>>>>> decide to >>>>>>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>>>>>>> the >>>>>>>>>>>>>> same >>>>>>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>>>>>> interface >>>>>>>>>>>>>>> inspects the packets (at line >>>>>>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>>>>>> interface. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>>>>>> the >>>>>>>>>>>> lookup >>>>>>>>>>>>>>> as easy as possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps a >>>>>>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>>>>>> Level) may be >>>>>>>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps it could. >>>>>>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>>>>>> version of >>>>>>>>>>>>>>> the I-D arduous? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>>>>>> In-MIPs >>>>>>>>>>>>>> are >>>>>>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>>>>>> today on >>>>>>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>>>>>> proposing >>>>>>>>>>>>>> such >>>>>>>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>>>>>>> D and >>>>>>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>>>>>> lookup on >>>>>>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>>>>>> both >>>>>>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>>>>>> can do >>>>>>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>>>>>> lookup on >>>>>>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>>>>>> the >>>>>>>>>>>>>>> incoming interface and the packet marked for easy >>>>>>>>>> interception >>>>>>>>>>>> on the >>>>>>>>>>>>>> outgoing interface. >>>>>>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>>>>>> longer be >>>>>>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>>>>>> modified in >>>>>>>>>>>>>> flight. >>>>>>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>>>>>> the >>>>>>>>>>>> packet >>>>>>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>>>>>> needed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>>>>>> progressed, >>>>>>>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>>>>>>> pros >>>>>>>>>>>>>> and >>>>>>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>>>>>> On >>>>>>>>>>>> Behalf >>>>>>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>>> ; >>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>>>>>> anything >>>>>>>>>>>>>> else? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>>>>>> were >>>>>>>>>>>> saying >>>>>>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>>>>>> backward >>>>>>>>>>>>>> compatible". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>>>>>> hoc >>>>>>>>>>>>>>> team; >>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>>>>>>> I find >>>>>>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Title >>>>>>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>>>>>> [Handling >>>>>>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>>>>>> definition of >>>>>>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>>>>>> says The >>>>>>>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s1 >>>>>>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>>>>>>> engine. >>>>>>>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>>>>>>> 'one on >>>>>>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s4 >>>>>>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s5 >>>>>>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>>>>>>> MPLS-TP >>>>>>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>>>>>> precedents, >>>>>>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>>>>>> for >>>>>>>>>>>> LSPs, >>>>>>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>>>>>> sentence >>>>>>>>>>>> as >>>>>>>>>>>>>>>>> redundant] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> s6 >>>>>>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>>>>>> been >>>>>>>>>>>>>> left in >>>>>>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>>>>>> To: >>>>>>>>>>>>>>>>> Cc: ; >>>>>>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>>>>>> mailing >>>>>>>>>>>> list >>>>>>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>>>>>> with the >>>>>>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>> >>>>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> mpls mailing list >>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> mpls mailing list >>>>>>>>> mpls@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >> > > From Rolf.Winter@neclab.eu Wed Dec 5 00:10:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629C021F866F for ; Wed, 5 Dec 2012 00:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOAx3hi9CrU8 for ; Wed, 5 Dec 2012 00:10:31 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5921F85C8 for ; Wed, 5 Dec 2012 00:10:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EDC54102866; Wed, 5 Dec 2012 09:10:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6rXvxDhNjix; Wed, 5 Dec 2012 09:10:23 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id CDF7D102861; Wed, 5 Dec 2012 09:10:13 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 09:10:12 +0100 From: Rolf Winter To: Shahram Davari , "mpls@ietf.org" Thread-Topic: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0hWDaHf1a4ba/kiftxEwtEw3V5gIrIkAgACD7ACAAKiwUA== Date: Wed, 5 Dec 2012 08:10:11 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55545FF4@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD2FBBB@SJEXCHMB12.corp.ad.broa> <38DFCE5F-A496-4AAC-A2C5-0450B5260EAD@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> , <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> <4A6CE49E6084B141B15C0713B8993F281BD39C6A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD39C6A@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:10:32 -0000 Hi Shahram, thanks for the summary. It is not 100% accurate but I have explained before= how we believe this can work so I won't repeat myself again. "Your" soluti= on is essentially what we had considered before and dismissed for the reaso= ns that I have also stated on the list before (some of these reasons have b= een documented in the penultimate version of the draft which have only rece= ntly been removed). Changing the document would only be a matter of using s= ome old text and put it back in. We would also need to make this a standard= s track document which (at least) updates 5586. But this is just a procedur= al note. But you are absolutely correct that the WG need to decide on this.= It would be nice to see other people comment.=20 Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Dienstag, 4. Dezember 2012 23:57 > To: mpls@ietf.org > Subject: Re: [mpls] working group lastcallondraft-ietf-mpls-tp-mip-mep- > map >=20 > Hi MPLS WG, >=20 > I would like to summarize our discussion and let the WG decide. >=20 > 1) The draft requires MIPID to be used by the HW in the Ingress port to > select whether an OAM packet should be sent to CPU for processing or be > forwarded to egress port(s). >=20 > 2) The draft requires MIPID to be used by the HW in Egress port to > select whether an OAM packet should be sent to CPU for processing or > dropped. >=20 > 3) The draft solution applies to P2P and P2MP MPLS, and is efficient, > meaning that it sends OAM packets only to the CPUs that need to be used > for processing. And does not overload CPUs that don't need to receive > an OAM packet. >=20 > 4) The draft solution requires parsing the OAM packets to get to the > MIPID TLV. There are many types of OAM messages with different format > (BFD, LSP-Ping, APS, RFC6374, etc.) and the TLV can be anywhere in the > packet. This makes the draft solution not practical to implement in HW, > and therefore not widely deployed. >=20 > ------------------------------------------------ >=20 > 5) My proposal is to use a single bit in the ACH to indicate whether > the OAM packet is for in-MIP or out-MIP. This single bit is used by HW > in the ingress port to select whether an OAM packet should be sent to > CPU for processing or be forwarded to egress port(s). When packet is > sent to CPU, then the MIPID can be used by CPU to double check that it > has received the expected OAM packet. >=20 > 6) My proposal is for an egress port to send the OAM packet to CPU, if > a MIP is configured on that port, (otherwise drop it in HW. When packet > is sent to CPU, then the MIPID can be used by CPU to double check that > it has received the expected OAM packet. >=20 > 7) My solution applies to P2P MPLS (which is more than 95% of the LSPs, > PWs) efficiently, meaning that it sends OAM packets only to the CPUs > that need to be used for processing. And does not overload CPUs that > don't need to receive an OAM packet. >=20 > 8) My solution applies to P2MP MPLS (which is less than 5% of the LSPs, > PWs) but NOT efficiently, meaning that it sends OAM packets to the CPUs > that don't need to process the OAM and overloads some CPUs that don't > need to receive an OAM packet. >=20 >=20 > The question in front of the WG is which solution to pick. My argument > is that although the draft solution is a theoretically a perfect > solution but is not practical and may never get implemented widely. > While my solution is perfect for more than 95% of the LSPs (P2P LSPs) > and is in-efficient for less than 5% of the LSPs (P2MP LSPs). However > it is simple and trivial to implement in HW. >=20 > You choose ! >=20 > This is my last argument email justifying my proposed solution. >=20 > Thanks, > Shahram >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From Rolf.Winter@neclab.eu Wed Dec 5 00:23:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567F421F8CA1 for ; Wed, 5 Dec 2012 00:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.408 X-Spam-Level: X-Spam-Status: No, score=-103.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmKTiz2qk6vq for ; Wed, 5 Dec 2012 00:23:28 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F10B121F8C9A for ; Wed, 5 Dec 2012 00:23:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 49A3D102866; Wed, 5 Dec 2012 09:23:27 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKzGS+PCTCQJ; Wed, 5 Dec 2012 09:23:27 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 2CC4C102868; Wed, 5 Dec 2012 09:23:17 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 09:23:15 +0100 From: Rolf Winter To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLCAAD1PAIAAL8Jw///5M4CAAMon4IAA8bMAgACmioA= Date: Wed, 5 Dec 2012 08:23:15 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:23:29 -0000 Hi Greg, see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > Hi Rolf, > I'll think that per MEG MIPs, even though they are on the same LSP/PW, > in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence > different SPMEs. If such interpretation is acceptable, then we can have > multiple MIPs but only one MIP per MEG Level (even though no such > construct was introduced in MPLS-TP OAM model, unfortunately IMHO). Again, I don't see why to force this, what this would actually gain, why to= introduce an artificial constraint and force people to manage MEG levels a= s opposed to multiple MIPs per MEG. You can implement it this way if you wi= sh but I do not see a compelling argument why to force it (and therefore di= sallow something that _all_ RFCs have allowed to date). > And I think that distinction, if any, between in-, out- and nodal MIP > should not be required for unidirectional MPLS-TP constructs as it is > not practical since Loopback mode can not be exercised as there's no > return path via data plane. Thus examples with p2mp scenarios are not > applicable, IMHO, to this discussion. A return path will be out of band, yes. But if you proclaim that if there i= s no data plane return path and therefore in- and out- MIP distinction is u= seless that doesn't compute at my end. I mean, if MIP functionality is usef= ul in any scenario, the distinction can help operators to do a better OAM j= ob (and I believe restricting the discussion to loopback is not helpful her= e either). >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > ] > Sent: Tuesday, December 04, 2012 12:00 AM > To: Gregory Mirsky; mpls@ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Greg, >=20 > you might not be convinced but there are operators that have asked for > this functionality based on operational experience. >=20 > Quoting the OAM framework RFC: >=20 > " Once a MEG is configured, the operator can enable/disable the MIPs on > the nodes within the MEG. All the intermediate nodes and possibly > the end nodes host MIP(s). Local policy allows them to be enabled > per function and per MEG. The local policy is controlled by the > management system, which may delegate it to the control plane. A > disabled MIP silently discards any received OAM packets." >=20 > Clearly having multiple MIPs per LSP is allowed as per the OAM > framework. I think however the sentence "All the intermediate nodes and > possibly the end nodes host MIP(s)" should really be ""All the > intermediate nodes and possibly the end nodes can host MIP(s)" (Is this > worth filing an errata?). I don't see why one wants to arbitrarily > restrict the number of MIPs per LSP. BTW, as you mention, the support > of multiple MIPs in Ethernet is optional. Quoting the OAM framework > again: >=20 > "Support of per-interface or per-node MIPs is an implementation > choice." >=20 > So where's the difference? >=20 > Best, >=20 > Rolf >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > ] > > Sent: Montag, 3. Dezember 2012 21:47 > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Rolf, > > I've been thinking about that requirement for some time and am not > > convinced that such requirement, support multiple MIP per LSP/PW on > > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single > > MIP per MD/MEG Level is required and support of multiple MIPs is > optional. > > True, multiple MIPs of different MD/MEG Levels might be enabled on a > > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus such > > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat- > > plane loopback can be used on uni-directional construct. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > > > > ] > > Sent: Monday, December 03, 2012 12:15 PM > > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Greg, > > > > But that's the whole point of the document. There can be multiple in- > > and out-MIPs per LSP plus in the P2MP case there can be multiple out- > > MIPs per node. It cannot be based local configuration. There has to > be > > information inside the OAM frame to address the respective MIP. > > Section > > 4 of the document has a (I believe) pretty good example of this. > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > > > > > > > > ] > > > Sent: Montag, 3. Dezember 2012 19:20 > > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Hi Rolf, > > > Do you envision that multiple MIPs, both in- and out-, required to > be > > > supported on a given LSP/PW? I think that only single MIP > > required > > > per LSP/PW on an LSR/PE node. If that is the case, then there might > > be > > > no apparent need to explicitly address in- and out- MIP as such > > > distinction becomes part of local configuration. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org > > > > > > ] On Behalf Of Rolf Winter > > > Sent: Monday, December 03, 2012 5:42 AM > > > To: Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp- > > mip- > > > mep-map > > > > > > Loa, > > > > > > These have been mentioned: > > > > > > 1. CV between a MEP and a MIP > > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > > MIPs > > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > > > > > Best, > > > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.nu > > > > > ] > > > > Sent: Freitag, 30. November 2012 11:41 > > > > To: mpls@ietf.org > > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > > > mpls-ads@tools.ietf.org > > > > Subject: Re: working group last call on > > > > draft-ietf-mpls-tp-mip-mep- > > > map > > > > > > > > Authors, > > > > > > > > Can you plese give me an indication of which OAM functions the > > > > separation of in and out MIPs are intended for? > > > > > > > > /Loa > > > > > > > > > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > > > > > Working Group, > > > > > > > > > > This is to start a 2 week working group last call on > > > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > > > > > Please send your comments to the mpls working group mailing > list > > > > > (mpls@ietf.org). > > > > > > > > > > Please send both technical comments, and if you are happy with > > the > > > > > document as is also indications of support. > > > > > > > > > > This working group last call will end on November 28. > > > > > > > > > > /Loa > > > > > for the wg co-chairs > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > >=20 From loa@pi.nu Wed Dec 5 01:14:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1065321F8CAC for ; Wed, 5 Dec 2012 01:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKWKsa7X6nXn for ; Wed, 5 Dec 2012 01:14:19 -0800 (PST) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3202521F8CAA for ; Wed, 5 Dec 2012 01:14:19 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 830C682388; Wed, 5 Dec 2012 10:14:14 +0100 (CET) Message-ID: <50BF105F.5030004@pi.nu> Date: Wed, 05 Dec 2012 10:14:07 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: [mpls] IPR poll on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 09:14:20 -0000 Working Group and authors; The authors of draft-ietf-mpls-ldp-dod has indicated that the draft is ready for working last call. Before starting the working group last call we will do an IPR poll to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-ldp-dod? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Rolf.Winter@neclab.eu Wed Dec 5 02:50:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5053221F8908 for ; Wed, 5 Dec 2012 02:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeX66R3SGCA8 for ; Wed, 5 Dec 2012 02:50:38 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3647D21F8904 for ; Wed, 5 Dec 2012 02:50:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 92F11102869 for ; Wed, 5 Dec 2012 11:50:37 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtbburDxNWj8 for ; Wed, 5 Dec 2012 11:50:37 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7535310285D for ; Wed, 5 Dec 2012 11:50:32 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 11:50:10 +0100 From: Rolf Winter To: "mpls@ietf.org" Thread-Topic: one more thing on per-interface MIP addressing... Thread-Index: AQHN0tZM4N1Ul3/ysk+VTVnuVaoG8g== Date: Wed, 5 Dec 2012 10:50:09 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D555460B8@DAPHNIS.office.hd> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.198] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] one more thing on per-interface MIP addressing... X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 10:50:39 -0000 Hi, let me add one more thing to the discussion. We had many of these discussio= ns at various places like the mailing list, the meetings etc. The fixed loc= ation ID TLV e.g. was one of those and I attached one dated Email exchange = on this, where I argued that this would be beneficial for an implementation= at line rate. This is about 20 months ago. I really appreciate the debate = we are having at the moment (I only wish we had it at the time when we disc= ussed the various options and not during last call). So what I would like t= o say is that we should not go through all possible HW-friendly options aga= in that have been discussed (at least not without going through the mailing= list archives before hand) and reiterate the same discussions we had 2 yea= rs ago. I don't mind discussing two, but let as not add more. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Rolf Winter > Sent: Montag, 28. M=E4rz 2011 12:19 > To: Eric Gray > Cc: mpls@ietf.org > Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > demand-cv-03 >=20 > Hi, >=20 > I still think there is a logical error. Let me explain. In case there > is no IP you simply cannot use it. You say you could enable IP but then > that is not a case where there is no IP. In order to be constructive > here is a text change suggestion: >=20 > "In certain MPLS-TP deployment scenarios IP addressing might not be > available. In those cases On-demand CV and/or route tracing MUST be run > without IP addressing, using the ACH channel type specified in Section > 3. In other cases it might be available, however, it may be preferred > to use some form of non-IP encapsulation. In those cases, the > procedures as outlined in section 3 SHOULD also be used." >=20 > Regarding the per-interface MIP discussion. The HW aspect also popped > up in the PWE3 session and I think this is an important consideration, > in particular for OAM. Even if we talk about TLVs, we could make it a > MUST that an Address TLV is always the first one to appear. If you can > facilitate an easy implementation in hardware, I see no reason to > deliberately not do it. >=20 > Best, >=20 > Rolf >=20 >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@ericsson.com] > > Sent: Montag, 28. M=E4rz 2011 11:43 > > To: Rolf Winter > > Cc: loa@pi.nu; mpls@ietf.org > > Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > demand-cv-03 > > > > Rolf, > > > > With regard to the use of SHOULD (verses MUST) - the intent > > (according to RFC 2119 - see the quote below) is consistent with this > > case. If - for some reason - one had a really good reason to use IP > > addressing in some specific case, one could take steps to make IP > > addressing available. > > > > This could be said to introduce a logical disconnect, but we are > > saved from going down that path by the fact that the statement also > > includes the case where (for some reason) there is a case in which > > some other addressing scheme might be preferred. In many of the > cases > > where another addressing scheme may be preferred, it is still > possible > > (in fact likely) that IP addressing is available. > > > > Otherwise, it would not have been necessary to distinguish this > case > > from the one in which IP addressing is not available. > > > > For the case where IP addressing is not the preferred mode, we > are > > recommending a mode in which it is not necessary. > > > > With regard to having addresses located in the same place, this > > protocol is meant for connectivity testing on an on-demand basis and > > is therefore not optimized for processing in hardware. > > > > Whether addresses or identifiers, if we are talking about TLV > > contents, there are issues with trying to guarantee location of > > specific content, because of the fact that the TLV in question will > > probably follow other TLVs - thus making locations difficult to > > predict in any case. > > > > With regard to needing more text on per-interface MIPs, do you > have > > specific suggestions as to what text we might add? > > > > I understand (from discussion with WG chairs) that we are not > allowed > > to explicitly address last call comments during the IETF meeting in > > Prague, because the last call is still ongoing at that time. > > > > -- > > Eric > > > > PS - > > From RFC 2119 - > > 'SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to > > ignore a particular item, but the full implications must > > be understood and carefully weighed before choosing a > > different course.' > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Rolf Winter > > Sent: Tuesday, March 22, 2011 4:57 AM > > To: loa@pi.nu; mpls@ietf.org > > Subject: Re: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > demand-cv-03 > > > > Hi, > > > > some comments below: > > > > Section 1.3 says: " In certain MPLS-TP deployment scenarios IP > > addressing might not be > > available or it may be preferred to use some form of non-IP > > encapsulation for On-demand CV, route tracing and BFD packets. In > > such scenarios, On-demand CV and/or route tracing SHOULD be run > > without IP addressing..." > > > > I am not sure the "SHOULD" is right here. If no IP addressing is > > available, this thing MUST be run without IP addressing, mustn't it? > > > > I think some additional text regarding per-interface MIP addressing > > would be nice. As far as I understand the document, all TLVs will be > > inside the LSP ping packet (rather than as ACH TLVs). > > > > Some people had concerns earlier, that addressing information should > > be in a fixed location for easier processing. Is this the case here I > > wonder? > > > > It would be nice if you could address this in your presentation in > > Prague. > > > > Thanks, > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > Of > > > loa@pi.nu > > > Sent: Mittwoch, 16. M=E4rz 2011 00:26 > > > To: mpls@ietf.org > > > Cc: MPLS-TP ad hoc team > > > Subject: [mpls] Working Group Las Call on draft-ietf-mpls-tp-on- > > demand- > > > cv-03 > > > > > > Working Group, > > > > > > this is to start a 3 week working group last call on > > > > > > draft-ietf-mpls-tp-on-demand-cv-03 > > > > > > Please send comments to the working group mailing list > mpls@ietf.org > > > > > > The working group last call ends on April 8, 2011. > > > > > > /Loa > > > > > > > > > > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From bruno.decraene@orange.com Wed Dec 5 03:01:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431D821F8602 for ; Wed, 5 Dec 2012 03:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNc86ZLmZZGe for ; Wed, 5 Dec 2012 03:01:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60C21F85EA for ; Wed, 5 Dec 2012 03:01:51 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C2A3022C85D; Wed, 5 Dec 2012 12:01:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A229627C06A; Wed, 5 Dec 2012 12:01:49 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 12:01:49 +0100 From: To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-ldp-dod Thread-Index: AQHN0sjoyI10X576wUqNUjkZLSp7L5gKCZJg Date: Wed, 5 Dec 2012 11:01:48 +0000 Message-ID: <25739_1354705309_50BF299D_25739_59_1_53C29892C857584299CBF5D05346208A114466@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <50BF105F.5030004@pi.nu> In-Reply-To: <50BF105F.5030004@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-dod@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 11:01:52 -0000 Loa, all I'm not aware of any IPR on draft-ietf-mpls-ldp-dod. Bruno >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: Wednesday, December 05, 2012 10:14 AM >To: mpls@ietf.org >Cc: draft-ietf-mpls-ldp-dod@tools.ietf.org; mpls-chairs@tools.ietf.org; Ad= rian >Farrel; Martin Vigoureux >Subject: IPR poll on draft-ietf-mpls-ldp-dod > >Working Group and authors; > >The authors of draft-ietf-mpls-ldp-dod has indicated that the draft is >ready for working last call. > >Before starting the working group last call we will do an IPR poll to >check whether there is IPR on the document that needs to be disclosed. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-ldp-dod? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >documents will not advance to the next stage until a response >has been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >(as MPLS WG co-chair) >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From kvivek@broadcom.com Wed Dec 5 03:19:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92221F885A for ; Wed, 5 Dec 2012 03:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL3V2sBpLTTo for ; Wed, 5 Dec 2012 03:19:31 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 69EB121F881D for ; Wed, 5 Dec 2012 03:19:31 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 05 Dec 2012 03:14:49 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 5 Dec 2012 03:19:16 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 5 Dec 2012 03:18:55 -0800 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPA== Date: Wed, 5 Dec 2012 11:18:55 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CA1F32339W5579821-01-01 Content-Type: multipart/alternative; boundary=_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FFSJEXCHMB09corpa_ Subject: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 11:19:32 -0000 --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FFSJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Authors, I have some question. 1) The draft-xu-mpls-in-udp-04 main purpose seems to be for proving l= oad balancing in IP network for MPLS packets. Is that the only use case of= this new encapsulation method or there can be some more ? 2) The draft says that ingress PE router will calculate entropy and e= ncapsulate UDP header with src port containing entropy value . Does this me= an that only PE routers can do UDP encap since PE router can look deep insi= de the packet to calculate entropy ? What if LSR's want to initiate UDP tunnel ? Kindly provide your comments . Regards, Vivek --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FFSJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi  Authors,

  

I have some question.

 

1)      The  draft-xu-mpls-in-udp-04 main purpose seem= s to be for proving load balancing in IP network for MPLS packets.  Is= that the only use case of this new encapsulation method or there can be so= me more ?

 

2)      The draft says that ingress PE router will calculat= e entropy and  encapsulate UDP header with src port containing entropy= value . Does this mean that only PE routers can do UDP encap since PE rout= er can look deep inside the packet to calculate entropy ?

        &nbs= p;       What if LSR’s want to initiate= UDP tunnel ?

 

Kindly provide your comments .

 

Regards,

Vivek

 

 

--_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FFSJEXCHMB09corpa_-- From michelg@upperside.fr Wed Dec 5 04:21:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB6121F8973 for ; Wed, 5 Dec 2012 04:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdCVup6RzRZq for ; Wed, 5 Dec 2012 04:21:10 -0800 (PST) Received: from smtp08.msg.oleane.net (smtp08.msg.oleane.net [62.161.4.8]) by ietfa.amsl.com (Postfix) with ESMTP id BB89D21F896C for ; Wed, 5 Dec 2012 04:21:09 -0800 (PST) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp08.msg.oleane.net (MSA) with ESMTP id qB5CL6Lq006520 for ; Wed, 5 Dec 2012 13:21:06 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Wed, 5 Dec 2012 13:20:59 +0100 Message-ID: <000901cdd2e3$00715950$01540bf0$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CDD2EB.623747F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3S4t4uE3DTyRDTR+KPAbzUjipoQw== Content-Language: fr X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.5.120915 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS World 2013 agenda: the SDN impact X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 12:21:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CDD2EB.623747F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SDN and OpenFlow intersection with MPLS will be key sessions of the upcoming MPLS & Ethernet World Congress (Paris, March 19-22, 2013). The first day of the conference will cover technical issues and uncertainties that have arisen with the appearance of the so called SDN architecture. The day will end with the debate,< If we don't have a definition of what it is, what isn't SDN? >. The MPLS & Ethernet World Congress won't forget to address key technical issues during the two following days, including end-to-end architectures, LTE mobile backhaul, protection, edge and traffic optimization. More information: http://www.uppersideconferences.com/ ------=_NextPart_000_000A_01CDD2EB.623747F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SDN and = OpenFlow intersection with MPLS will be key sessions of the upcoming = MPLS & Ethernet World Congress  (Paris, March 19-22, = 2013).

The first day = of the conference will cover technical issues and uncertainties that = have arisen with the appearance of the so called SDN = architecture.

The day will = end with the debate,« If we don't have a definition of = what it is, what isn't SDN? ».

The MPLS & Ethernet World Congress won’t forget to address = key technical issues during the two following days, including end-to-end = architectures, LTE mobile backhaul, protection, edge and traffic = optimization.

More = information: http://www.uppersideconfere= nces.com/

 =

------=_NextPart_000_000A_01CDD2EB.623747F0-- From cpignata@cisco.com Wed Dec 5 10:36:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7321F8C64 for ; Wed, 5 Dec 2012 10:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.496 X-Spam-Level: X-Spam-Status: No, score=-108.496 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnCNsPIjW7r4 for ; Wed, 5 Dec 2012 10:36:02 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A921F87CA for ; Wed, 5 Dec 2012 10:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53656; q=dns/txt; s=iport; t=1354732562; x=1355942162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CEvQBkIgeS//zS4ESz5CgXIIFcTHE0V1myY9KNZ2s2Q=; b=QNfec6cly8Zus7n1udp1iYNudSWBJxqu0dHYoH+f3yG54nbPleBpvlcf 0o3yfIo4h3jbaKy7cBgkC0oTBrepM74B5nOlDS8rvayoCiV+zjfARr+lv ePwl0Bxeu2KCut5GZEwowpJQ+s0397ghZupBQo2EkdAzSbFuBWzzk+PZm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHKTv1CtJXG//2dsb2JhbABEgkmDa7Z8dBZzgh8BAQQOVxQQAgEGAiIWAQYFAgIwFBECBA4FCBOHdZRjmmsIkwuMN4MqNmEDpkqCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149754746" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2012 18:36:01 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB5Ia1nQ013796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Dec 2012 18:36:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 12:36:01 -0600 From: "Carlos Pignataro (cpignata)" To: Xuxiaohu Thread-Topic: Technical Review of draft-xu-mpls-in-udp-03 Thread-Index: AQHN0PtkrdRX1gjCK0Czwht46ucobJgGlN5QgARcfYA= Date: Wed, 5 Dec 2012 18:36:00 +0000 Message-ID: <95067C434CE250468B77282634C96ED322759BA0@xmb-aln-x02.cisco.com> References: <95067C434CE250468B77282634C96ED322747C5C@xmb-aln-x02.cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586332@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.55] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322759BA0xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Technical Review of draft-xu-mpls-in-udp-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 18:36:05 -0000 --_000_95067C434CE250468B77282634C96ED322759BA0xmbalnx02ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWGlhb2h1LA0KDQpUaGFua3MsIHBsZWFzZSBzZWUgaW5saW5lLg0KDQpPbiBEZWMgMywgMjAx MiwgYXQgMTo1MiBBTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlh b2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQ2FybG9zLA0KDQpUaGFua3MgYSBsb3QgZm9y IHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW4gbGluZS4NCg0Kt6K8/sjL OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHt IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0Kt6LLzcqxvOQ6IDIwMTLE6jEy1MIzyNUgMTA6 MTENCsrVvP7IyzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCrOty806IGRy YWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWlu LXVkcEB0b29scy5pZXRmLm9yZz4NCtb3zOI6IFttcGxzXSBUZWNobmljYWwgUmV2aWV3IG9mIGRy YWZ0LXh1LW1wbHMtaW4tdWRwLTAzDQoNCkhpLA0KDQpQbGVhc2UgZmluZCBhIHNldCBvZiBvYnNl cnZhdGlvbnMsIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyByZWdhcmRpbmcgZHJhZnQteHUtbXBs cy1pbi11ZHAtMDMsIGZyb20gcmVhZGluZyBhbmQgcmV2aWV3aW5nIHRoZSBkb2N1bWVudC4gSSBk byBmaW5kIHRoZSBkb2N1bWVudCB2ZXJ5IHdlbGwgd3JpdHRlbiwgYW5kIHdoaWxlIHRoZSByZXF1 aXJlbWVudHMgYXJlIHdlbGwgYXJ0aWN1bGF0ZWQsIHRoZXJlIGFyZSBzb21lIGFwcGFyZW50IGxl YXBzIGFzIGRlc2NyaWJlZCBiZWxvdy4NCg0KTW9yZSBzdWJzdGFudGl2ZToNCg0KDQoxLiBJbnRy b2R1Y3Rpb24NCg0KDQoNCiAgIEhvd2V2ZXIsIHdpdGggZXhpc3RpbmcgSVAtYmFzZWQNCg0KICAg ZW5jYXBzdWxhdGlvbiBtZXRob2RzIGFzIGRlZmluZWQgaW4gW1JGQzQwMjNdIChlLmcuLCBNUExT LWluLUlQIGFuZA0KDQogICBNUExTLWluLUdSRSksIGRpc3RpbmN0IGN1c3RvbWVyIHRyYWZmaWMg Zmxvd3Mgb2YgdmFyaW91cyBNUExTDQoNCiAgIGFwcGxpY2F0aW9ucyAoZS5nLiwgTVBMUy1iYXNl ZCBMMlZQTiBvciBMM1ZQTikgYmV0d2VlbiBhIGdpdmVuIFBFDQoNCiAgIHBhaXIgd291bGQgYmUg ZW5jYXBzdWxhdGVkIHdpdGggdGhlIHNhbWUgSVAgb3IgR1JFIHR1bm5lbCBoZWFkZXINCg0KICAg cHJpb3IgdG8gdHJhdmVyc2luZyB0aGUgSVAgY29yZS4gU2luY2UgdGhlIGVuY2Fwc3VsYXRpbmcg dHJhZmZpYyBpcw0KDQogICBuZWl0aGVyIFRDUCBub3IgVURQIHRyYWZmaWMsIGNvcmUgcm91dGVy cyBjb3VsZCBvbmx5IHBlcmZvcm0gaGFzaA0KDQogICBjYWxjdWxhdGlvbiBvbiB0aGUgZmllbGRz IGluIHRoZSBJUCBoZWFkZXIgb2YgSVAgb3IgR1JFIHR1bm5lbHMuDQoNClRoZSBJbnRyb2R1Y3Rp b24gaW4gdGhpcyBkb2N1bWVudCBtYWtlcyBzb21lIGZhaXJseSBzdHJvbmcgc3RhdGVtZW50cyBz dXBwb3J0aW5nIGl0cyBjb25jbHVzaW9uLiBGb3IgZXhhbXBsZSwgIlNpbmNlIHRoZSBlbmNhcHN1 bGF0aW9uIGlzIG5laXRoZXIgVENQIG5vciBVRFAsIGNvcmUgcm91dGVycyBjb3VsZCBvbmx5IHBl cmZvcm0gYSBoYXNoIG9uIElQIGhlYWRlciBmaWVsZHMiLiBJIGFtIG5vdCBzdXJlIG9mIHRoZSBp bnRlbmRlZCBtZWFuaW5nIG9mIHRoZSAiY291bGQiIGluIHRoYXQgc2VudGVuY2UgLS0gaG93ZXZl ciBmcm9tIGEgdGVjaG5pY2FsIHBlcnNwZWN0aXZlLCBpdCdzIGluY29tcGxldGUuIENlcnRhaW5s eSwgY29yZSByb3V0ZXJzICJjb3VsZCIgcGVyZm9ybSBhIGhhc2ggY2FsY3VsYXRpb24gZm9yIGxv YWQtYmFsYW5jaW5nIGZyb20gb3RoZXIgZmllbGRzLiBGb3IgTVBMUy1pbi1JUCwgYW5kIGluIHBh cnRpY3VsYXIgZm9yIHRoZSBjYXNlIG9mIE1QTFMtaW4tSVB2NiwgdGhlIElQdjYgRmxvdyBMYWJl bCAiY291bGQiIGJlIHVzZWQgW1JGQyA2NDM4XS4gRm9yIEdSRSwgdGhlIEdSQyBLZXkgY2FuIGJl IHVzZWQgW1JGQyA1NjQwXS4NCg0KDQoNCg0KICAgQXMNCg0KICAgYSByZXN1bHQsIGNvcmUgcm91 dGVycyBjb3VsZCBub3QgYWNoaWV2ZSBhbiBlZmZlY3RpdmUgbG9hZC1iYWxhbmNpbmcNCg0KICAg Zm9yIHRoZXNlIHRyYWZmaWMgZmxvd3MgaW4gdGhlIG5ldHdvcmsgZHVlIHRvIHRoZSBsYWNrIG9m IGFkZXF1YXRlDQoNCiAgIGVudHJvcHkgaW5mb3JtYXRpb24uDQoNCkNvbnNlcXVlbnRseSwgImxh Y2sgb2YgZW50cm9weSBpbmZvcm1hdGlvbiIgaXMgbm90IGEgcmVhc29uLiBUaGUgZmllbGRzIGFu ZCBlbnRyb3B5IGV4aXN0IGFscmVhZHkuDQoNCltYaWFvaHVdIFRoZSBhYm92ZSBzdGF0ZW1lbnQg aXMgYWJvdXQgdGhlIE1QTFMtaW4tR1JFIGVuY2FwIHdpdGhvdXQgdXNpbmcgdGhlIEtleSBmaWVs ZCBhcyBhIKGwbG9hZC1iYWxhbmNpbmehsSBmaWVsZC4gQXMgZm9yIHRoZSBsb2FkLWJhbGFuY2lu ZyBhcHByb2FjaCBmb3IgTVBMUy1pbi1HUkUgdXNpbmcgS2V5IGZpZWxkIGFzIGEgobBsb2FkLWJh bGFuY2luZ6GxIGZpZWxkLCBpdCBpcyBkaXNjdXNzZWQgaW4gdGhlIHN1YnNlcXVlbnQgcGFyYWdy YXBoLiBCVFcsIHRoZXNlIHN0YXRlbWVudHMgaGF2ZSBiZWVuIHJlb3JnYW5pemVkIGZvciByZWFk YWJpbGl0eSBpbiB0aGUgLTA0IHZlcnNpb24uIFBsZWFzZSBzZWUgd2hldGhlciBpdKGvcyBPSy4N Cg0KDQoNClRoaXMgaXMgbXVjaCBtb3JlIHJlYWRhYmxlIC0tIGJ1dCBJIHRoaW5rIGl0IHN0aWxs IGhhcyBzZW50ZW5jZXMgdGhhdCBhcmUgb3ZlcnJlYWNoaW5nLiBGb3IgZXhhbXBsZSwgdGhlIGZv bGxvd2luZyB0d28gc2VudGVuY2VzIHJlbGF0ZSB0byAiV2l0aCBleGlzdGluZyBJUC1iYXNlZCBl bmNhcHN1bGF0aW9uIG1ldGhvZHMgZm9yIE1QTFMgYXBwbGljYXRpb25zIjoNCg0KDQogICBTaW5j ZSB0aGUNCiAgIGVuY2Fwc3VsYXRlZCB0cmFmZmljIGlzIG5laXRoZXIgVENQIG5vciBVRFAgdHJh ZmZpYywgY29yZSByb3V0ZXJzDQogICBjb3VsZCBvbmx5IHBlcmZvcm0gaGFzaCBjYWxjdWxhdGlv biBvbiBmaWVsZHMgaW4gdGhlIElQIGhlYWRlcnMgb2YNCiAgIHRob3NlIHR1bm5lbHMgKGkuZS4s IHNvdXJjZSBJUCBhZGRyZXNzLCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzKS4NCg0KYW5kDQoNCg0K ICAgQXMNCiAgIGEgcmVzdWx0LCBjb3JlIHJvdXRlcnMgY291bGQgbm90IGFjaGlldmUgYSBmaW5l LWdyYWluZWQgbG9hZA0KICAgYmFsYW5jaW5nIG9mIHRoZXNlIHRyYWZmaWMgZmxvd3MgYWNyb3Nz IHRoZSBuZXR3b3JrIGNvcmUgZHVlIHRvIHRoZQ0KICAgbGFjayBvZiBhZGVxdWF0ZSBlbnRyb3B5 IGluZm9ybWF0aW9uLg0KDQphbmQgYXMgaW5kaWNhdGVkIHRoZXNlIGFyZSBvdmVyZ2VuZXJhbGl6 ZWQgc2luY2UgeW91IGFyZSB0YWxraW5nIG9mICJleGlzdGluZyBJUC1iYXNlZCBlbmNhcHN1bGF0 aW9uIG1ldGhvZHMiLg0KDQpGdXJ0aGVyLCB0aGUgY2FzZSBtYWRlIGluIHRoaXMgZG9jdW1lbnQg aXMgYmFzZWQgb24gdHdvIHJlcXVpcmVtZW50czogaS4gTVBMUy1pbi1zb21lX2Zvcm1fb2YtSVAs IGFuZCBpaS4sIElQIGxvYWQtYmFsYW5jaW5nIGJhc2VkIG9uIFVEUC9UQ1AgdHJhbnNwb3J0IHBv cnRzLiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBjaXRhdGlvbnMgdGhhdCB3b3VsZCBxdWFs aWZ5LCBxdWFudGlmeSwgYW5kIGJldHRlciBzdWJzdGFudGlhdGUgdGhlc2UgcmVxdWlyZW1lbnRz LiBQb2ludGVycz8NCg0KQWRkaXRpb25hbGx5LCB0aGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSBj cmVhdGlvbiBvZiBhIG5ldyBNUExTLWluLUlQIGVuY2Fwc3VsYXRpb24uIFRoaXMgbmV3IGVuY2Fw c3VsYXRpb24gcmVxdWlyZXMgbm90IG9ubHkgc3BlY2lmaWNhdGlvbiBidXQgYWxzbyBkZXZlbG9w bWVudC4gSG93ZXZlciwgdGhlIHJlcXVpcmVtZW50cyB0aGF0IGRyaXZlIHRoZSBkb2N1bWVudCwg YnkgaW1wbGljYXRpb24sIHNlZW0gdG8gYmUgdW5kZXIgdGhlIHByZW1pc2UgdGhhdCBjb3JlIGxv YWRiYWxhbmNpbmcgb2Ygb3RoZXIgZW50cm9weSBmaWVsZHMgaXMgbm90IGEgc29sdXRpb24gYXMg aXQgaXMgbm90IGRldmVsb3BlZC4gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gdW5kZXJzdGFu ZCBhIGNvbXBhcmF0aXZlIGFuYWx5c2lzIG9mIGhhc2hpbmcgb24gb3RoZXIgdHJhbnNwb3J0cyBh bmQgYWRkaW5nIHRvIHRoZSBMQiBwYXRocywgdmVyc3VzIGNyZWF0aW5nIGEgbmV3IGVuY2Fwc3Vs YXRpb24uDQoNCltYaWFvaHVdIEdhcCBhbmFseXNpcyBvZiBleGlzdGluZyB0ZWNobm9sb2dpZXMg YW5kIHRoZSBtb3RpdmF0aW9uIGZvciBNUExTLWluLVVEUCBoYXZlIGJlZW4gZXhwbGFpbmVkIG1v cmUgY2xlYXJseSBpbiB0aGUgLTA0IHZlcnNpb24sIHBsZWFzZSBzZWUgd2hldGhlciBpdKGvcyBP Sy4NCg0KDQoNCkl0IGlzIGJldHRlciBleHBsYWluZWQsIHllcy4gVGhhbmtzLg0KDQoNCjMuIEVu Y2Fwc3VsYXRpb24gaW4gVURQDQoNCg0KDQouLi4NCg0KICAgICAgICAgICAgU291cmNlIFBvcnQg b2YgVURQDQoNCg0KDQogICAgICAgICAgICAgICAgVG8gZW5zdXJlIHRoYXQgdGhlIHNvdXJjZQ0K DQogICAgICAgICAgICAgICAgcG9ydCBudW1iZXIgaXMgYWx3YXlzIGluIHRoZSByYW5nZSA0OTE1 MiB0byA2NTUzNSB3aGljaA0KDQogICAgICAgICAgICAgICAgbWF5IGJlIHJlcXVpcmVkIGluIHNv bWUgY2FzZXMsIGluc3RlYWQgb2YgY2FsY3VsYXRpbmcgYQ0KDQogICAgICAgICAgICAgICAgMTYt Yml0IGhhc2gsIHRoZSBpbmdyZXNzIFBFIHJvdXRlciBjb3VsZCBjYWxjdWxhdGUgYSAxNC0NCg0K ICAgICAgICAgICAgICAgIGJpdCBoYXNoIGFuZCB1c2UgdGhvc2UgMTQgYml0cyBhcyB0aGUgbGVh c3Qgc2lnbmlmaWNhbnQNCg0KICAgICAgICAgICAgICAgIGJpdHMgb2YgdGhlIHNvdXJjZSBwb3J0 IGZpZWxkIHdoaWxlIHRoZSBtb3N0IHNpZ25pZmljYW50DQoNCiAgICAgICAgICAgICAgICB0d28g Yml0cyB3b3VsZCBiZSBzZXQgdG8gYmluYXJ5IDExLiBUaGF0IHN0aWxsIGNvbnZleXMNCg0KICAg ICAgICAgICAgICAgIDE0IGJpdHMgb2YgZW50cm9weSBpbmZvcm1hdGlvbiB3aGljaCB3b3VsZCBi ZSBlbm91Z2ggYXMNCg0KICAgICAgICAgICAgICAgIHdlbGwgaW4gcHJhY3RpY2UuDQoNCklzIHRo ZXJlIGFuIGltcGxpY2F0aW9uIG9mIDE0IGJpdHMgb2YgZW50cm9weSB2ZXJzdXMgMzIgYml0cyBv ZiBLZXksIDIwIGJpdHMgb2YgRmxvdyBMYWJlbC9NUExTIExhYmVsLCBldGM/DQoNCltYaWFvaHVd IFdpbGwgYWRkIGEgZGVzY3JpcHRpb24gb2YgdGhpcyBpbXBsaWNhdGlvbiBpbiB0aGUgbmV4dCBy ZXZpc2lvbi4NCg0KDQpUaGFua3MuDQoNCg0KICAgICAgICAgICAgVURQIENoZWNrc3VtDQoNCg0K DQogICAgICAgICAgICAgICAgVGhlIHVzYWdlIG9mIHRoaXMgZmllbGQgaXMgaW4gYWNjb3JkYW5j ZSB3aXRoIHRoZQ0KDQogICAgICAgICAgICAgICAgY3VycmVudCBVRFAgc3BlY2lmaWNhdGlvbi4g VG8gc2ltcGxpZnkgdGhlIG9wZXJhdGlvbiBvbg0KDQogICAgICAgICAgICAgICAgZWdyZXNzIFBF IHJvdXRlciwgdGhpcyBmaWVsZCBpcyByZWNvbW1lbmRlZCB0byBiZSBzZXQgdG8NCg0KICAgICAg ICAgICAgICAgIHplcm8uDQoNCg0KQW5kIGZvciBNUExTLW92ZXItVURQLW92ZXItSVB2Nj8gZHJh ZnQtaWV0Zi02bWFuLXVkcHplcm8tMDcgYW5kIGRyYWZ0LWlldGYtNm1hbi11ZHBjaGVja3N1bXMt MDQ/DQoNCltYaWFvaHVdIFdpbGwgYWRkIHJlZmVyZW5jZXMgdG8gdGhlIGFib3ZlIHR3byBkcmFm dHMgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNClRoYW5rcy4NCg0KDQoNCjQuIFNpZ25hbGluZyBm b3IgRW5jYXBzdWxhdGlvbiBpbiBVRFANCg0KSSBhZ3JlZSB3aXRoIEVyaWMgT3Nib3JuZSdzIG9i c2VydmF0aW9ucyBvbiB0aGlzIHNlY3Rpb24uIEFkZGl0aW9uYWxseSwgdGhpcyBzZWN0aW9uIHJl YWxseSBwb2xsdXRlcyBhbiAiZW5jYXBzdWxhdGlvbiIgZHJhZnQuDQoNCltYaWFvaHVdICBUaGlz IHNlY3Rpb24gaGFzIGJlZW4gc2ltcGxpZmllZCBncmVhdGx5IGluIHRoZSAwNCB2ZXJzaW9uLiBJ ZiB0aGUgV0cgY29uc2Vuc3VzIGlzIHRoYXQgdGhpcyBzZWN0aW9uIHNob3VsZCBiZSByZW1vdmVk IGNvbXBsZXRlbHksIHdlIGNhbiBkbyB0aGF0IGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQoNCklz IHRoZSBzZWN0aW9uIG5lZWRlZCBhdCBhbGw/DQoNCg0KOC4gSUFOQSBDb25zaWRlcmF0aW9ucw0K DQoNCg0KICAgVHdvIGRpc3RpbmN0IFVEUCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMgaW5kaWNh dGluZyBNUExTIGFuZCBNUExTDQoNCiAgIHdpdGggdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwgcmVz cGVjdGl2ZWx5IG5lZWQgdG8gYmUgYXNzaWduZWQgYnkNCg0KICAgSUFOQS4NCg0KSXQgaXMgbm90 IGV2aWRlbnQgKG9yIGV4cGxpY2l0KSBpbiB0aGUgZG9jdW1lbnQgd2h5IHR3byBwb3J0cywgd2hl biBvdGhlciBNUExTLWluLUlQIGVuY2FwcyBkbyBub3QgaGF2ZSBzZXBhcmF0ZSBvbmVzLg0KDQoN CltYaWFvaHVdIE1QTFMtaW4tR1JFIGFsc28gbmVlZHMgdHdvIHByb3RvdHlwZSBjb2RlcyB0byBy ZXByZXNlbnQgTVBMUyBhbmQgTVBMUyB3aXRoIGEgdXBzdHJlYW0tYXNzaWduZWQgbGFiZWwgcmVz cGVjdGl2ZWx5LiBQbGVhc2Ugc2VlIHNlY3Rpb24gNCBvZiBSRkM0MDIzLCBpdCBzYWlkIKGwVGhl IHByb3RvY29sIHR5cGUgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgIE1VU1QgYmUgc2V0IHRvIHRo ZSBFdGhlcnR5cGUgdmFsdWUgZm9yIE1QTFMgVW5pY2FzdCAoMHg4ODQ3KSBvciAgTXVsdGljYXN0 ICgweDg4NDgpLqGxDQoNCg0KTW9yZSBlZGl0b3JpYWw6DQoNCg0KICAgW1JGQzU2NDBdIGRlc2Ny aWJlcyBhIG1ldGhvZCBmb3IgaW1wcm92aW5nIHRoZSBsb2FkLWJhbGFuY2luZyBpbg0KDQogICBT b2Z0d2lyZSBtZXNoIG5ldHdvcmtzIFtSRkM1NTY1XS4gSG93ZXZlciwgdGhpcyBtZXRob2QgcmVx dWlyZXMgY29yZQ0KDQogICByb3V0ZXJzIHRvIGJlIGFibGUgdG8gcGVyZm9ybSBoYXNoIGNhbGN1 bGF0aW9uIG9uIHRoZSBmaWVsZHMNCg0KICAgaW5jbHVkaW5nIHRoZSAibG9hZC1iYWxhbmNpbmci IGZpZWxkIGNvbnRhaW5lZCBpbiB0aGUgTDJUUHYzIG9yIEdSRQ0KDQogICB0dW5uZWwgaGVhZGVy Lg0KDQpTaW5jZSB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB2YXJpb3VzIE1QTFMtaW4tSVAgZW5j YXBzdWxhdGlvbnMgYW5kIHRoZWlyIGNhcGFiaWxpdGllcyBmb3IgTEIsIHNob3VsZCBwcm9iYWJs eSBhbHNvIGluY2x1ZGUgYW5kIGNpdGUgW1JGQyA0ODE3XQ0KDQpbWGlhb2h1XSBUaGUgcmVmZXJl bmNlIHRvIFtSRkMgNDgxN10gaGFzIGJlZW4gYWRkZWQgaW4gdGhlIC0wNCB2ZXJzaW9uIGFjY29y ZGluZyB0byB5b3VyIHByZXZpb3VzIHN1Z2dlc3Rpb24uDQoNCg0KNS4gUHJvY2Vzc2luZyBGdW5j dGlvbnMNCg0KDQoNCg0KDQogICBQIHJvdXRlcnMsIHVwb24gcmVjZWl2aW5nIHRoZXNlIFVEUCBl bmNhcHN1bGF0ZWQgcGFja2V0cywgY291bGQNCg0KICAgYmFsYW5jZSB0aGVzZSBwYWNrZXRzIGJh c2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVEUA0KDQogICBwYWNrZXRzLg0K DQpJcyB0aGlzIHNldHRpbmcgYSBuZXcgcmVxdWlyZW1lbnQgZm9yICJQIHJvdXRlcnMiLCBtYWtp bmcgYSBzdGF0ZW1lbnQgb2YgZXhpc3RpbmcgdWJpcXVpdG91cyBzdXBwb3J0IChjaXRhdGlvbiks IG9yIGRlc2NyaWJpbmcgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yIHRoZSBlbmNhcHN1 bGF0aW9uPw0KDQpbWGlhb2h1XSBObyBuZXcgcmVxdWlyZW1lbnQgZm9yIFAgcm91dGVycy4gSXQg anVzdCBkZXNjcmliZXMgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQuDQoNCg0KICAgVXBvbiBy ZWNlaXZpbmcgdGhlc2UgVURQIGVuY2Fwc3VsYXRlZCBwYWNrZXRzLCBlZ3Jlc3MgUEUgcm91dGVy cw0KDQogICB3b3VsZCBkZWNhcHN1bGF0ZSB0aGVtIGJ5IHJlbW92aW5nIHRoZSBVRFAgaGVhZGVy cyBhbmQgdGhlbiBwcm9jZXNzDQoNCiAgIHRoZW0gYWNjb3JkaW5nbHkuDQoNCg0KVGhlIGRvY3Vt ZW50IHNob3VsZCBhbHNvIGRpc2N1c3MgcGFja2V0IHNpemUgaXNzdWVzLCBQTVRVRCwgTVRVLCBl dGMuDQoNCltYaWFvaHVdIFlvdXIgb2JzZXJ2YXRpb24gaXMgY29ycmVjdC4gVGhpcyBoYXMgYmVl biBhZGRyZXNzZWQgaW4gdGhlIC0wNCB2ZXJzaW9uIGFjY29yZGluZyB0byBFcmljIE9zYm9ybmUn cyBjb21tZW50Lg0KDQoNCkkgYW0gbm90IHN1cmUgSSBzZWUgYW55IGRpc2N1c3Npb24gb24gcGFj a2V0IHNpemUuDQoNClRoYW5rcyBhZ2FpbiBmb3IgeW91ciB2YWx1YWJsZSBjb21tZW50cy4NCg0K DQpUaGFua3MgdG8geW91IGZvciBhIG1vc3QgcXVpY2sgdHVybmFyb3VuZCBhbmQgcmVzcG9uZGlu ZyBhbmQgYWRkcmVzc2luZyBhbGwgY29tbWVudHMhDQoNCi0tIENhcmxvcy4NCg0KQmVzdCByZWdh cmRzLA0KWGlhb2h1DQoNClRoYW5rcywNCg0KLS0gQ2FybG9zLg0KDQoNCg== --_000_95067C434CE250468B77282634C96ED322759BA0xmbalnx02ciscoc_ Content-Type: text/html; charset="gb2312" Content-ID: <1F92CCCE178B644EB58729700E0A6838@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Xiaohu,

Thanks, please see inline.

On Dec 3, 2012, at 1:52 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi Carlos,
 
Thanks a lot for your comments. Please s= ee my response in line.
 
=B7=A2=BC= =FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] =B4=FA= =B1=ED Carlos Pignataro (cpignata)
=B7= =A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12= =D4=C23=C8=D5 10:11
=CA=D5=BC=FE=C8=CB: mpls@= ietf.org
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org
=D6=F7=CC=E2: [mpls] Technical Review= of draft-xu-mpls-in-udp-03
 
Hi,
 
Please find a set of observations, comments and sugges= tions regarding draft-xu-mpls-in-udp-03, from reading and reviewing the document. I do fin= d the document very well written, and while the requirements are well articulated, there are some apparent leaps as de= scribed below.
 
More substantive:
 
1. Introduction 
 
   However, with existing IP-bas=
ed 
   encapsulation methods as=
 defined in [RFC4023] (e.g., MPLS-in-IP and 
   MPLS-in-GRE), distinct c=
ustomer traffic flows of various MPLS 
   applications (e.g., MPLS=
-based L2VPN or L3VPN) between a given PE 
   pair would be encapsulat=
ed with the same IP or GRE tunnel header 
   prior to traversing the =
IP core. Since the encapsulating traffic is 
   neither TCP nor UDP traf=
fic, core routers could only perform hash 
   calculation on the field=
s in the IP header of IP or GRE tunnels.
The Introduction in this document makes some fairly st= rong statements supporting its conclusion. For example, "Since the encapsulation is neith= er TCP nor UDP, core routers could only perform a hash on IP header fields". I am not sure of the intended meaning of= the "could" in that sentence -- however from a technical perspec= tive, it's incomplete. Certainly, core routers "could" perform a = hash calculation for load-balancing from other fields. For MPLS-in-IP, and in particular for the case of MPLS-in-IPv6, the IPv6 Flow = Label "could" be used [RFC 6438<= /span>]. For GRE, the GRC K= ey can be used [RFC 5640].
 
 
 
   As 
   a result, core routers c=
ould not achieve an effective load-balancing 
   for these traffic flows =
in the network due to the lack of adequate 
   entropy information.
Consequently, "lack of entropy information" = is not a reason. The= fields and entropy exist already.
 
[Xiaohu] The above statement is about th= e MPLS-in-GRE encap without using the Key field as a =A1=B0load-balancing= =A1=B1 field. As for the load-balancing approach for MPLS-in-GRE using Key field as a =A1=B0load-balancing=A1=B1 field, it = is discussed in the subsequent paragraph. BTW, these statements have been r= eorganized for readability in the -04 version. Please see whether it=A1=AFs= OK.
 


This is much more readable -- but I think it still has sentences that = are overreaching. For example, the following two sentences relate to "= With existing IP-based encapsulation methods for MPLS applications": 

   Since the
   encapsulated traffic is neither TCP nor UDP traffic, core routers
   could only perform hash calculation on fields in the IP headers of
   those tunnels (i.e., source IP address, destination IP address).
and

   As
   a result, core routers could not achieve a fine-grained load
   balancing of these traffic flows across the network core due to the
   lack of adequate entropy information.

and as indicated these are overgeneralized since you are talking of &q= uot;existing IP-based encapsulation methods".

Further, the case made in t= his document is based on two requirements: i. MPLS-in-some_form_of-IP, and = ii., IP load-balancing based on UDP/TCP transport ports. It would be useful= to have citations that would qualify, quantify, and better substantiate these requirements. Pointers?
 
Additionally, this document proposes the creation of a= new MPLS-in-IP encapsulation. This new encapsulation requires not only spe= cification but also development. However, the requirements that drive the d= ocument, by implication, seem to be under the premise that core loadbalancing of other entropy fields is not a= solution as it is not developed. It would be interesting to understand a c= omparative analysis of hashing on other transports and adding to the LB pat= hs, versus creating a new encapsulation.
 
[Xiaohu] Gap analysis of existing techno= logies and the motivation for MPLS-in-UDP have been explained more clearly = in the -04 version, please see whether it=A1=AFs OK.
 


It is better explained, yes. Thanks.

3. Encapsulation in UDP =

 
...
       =
     Source Port of UDP 
 
       =
         To ensure that the source =

       =
         port number is always=
 in the range 49152 to 65535 which 
       =
         may be required in so=
me cases, instead of calculating a 
       =
         16-bit hash, the ingr=
ess PE router could calculate a 14-
       =
         bit hash and use those 14 =
bits as the least significant 
       =
         bits of the source po=
rt field while the most significant 
       =
         two bits would be set=
 to binary 11. That still conveys 
       =
         14 bits of entropy in=
formation which would be enough as 
       =
         well in practice.&nbs=
p;     
Is there an implication of 14 bits of entropy versus 3= 2 bits of Key, 20 bits of Flow Label/MPLS Label, etc?
 
[Xiaohu] Will add a description of this = implication in the next revision.
 

Thanks.

       =
     UDP Checksum      &n=
bsp; 
 
       =
         The usage of this field is=
 in accordance with the 
       =
         current UDP specifica=
tion. To simplify the operation on 
       =
         egress PE router, thi=
s field is recommended to be set to 
       =
         zero.  &nbs=
p; 
 
And for MPLS-over-UDP-over-= IPv6? draft-ietf-6man-udpzero-07 and = draft-ietf-6man-udpchecksums-04?
 
[Xiaohu] Will add references to the abov= e two drafts in the next revision.

Thanks.

 
4. Signaling for Encapsulation in UDP
I agree with Eric Osborne's observations on this secti= on. Additionally, this section really pollutes an "encapsulation"= draft.
 
[Xiaohu]  This section has been sim= plified greatly in the 04 version. If the WG consensus is that this section= should be removed completely, we can do that in the next revision.
 

Is the section needed at all?

8. IANA Considerations <=
/pre>

 


   Two distinct UDP destination =
port numbers indicating MPLS and MPLS 


   with upstream-assigned l=
abel respectively need to be assigned by 


   IANA. =






It is not evident (or explicit) in the document why tw=
o ports, when other MPLS-in-IP encaps do not have separate ones.



 


[=
Xiaohu] MPLS-in-GRE also needs two prototype codes to represent MPLS and MP=
LS with a upstream-assigned label respectively. Please see section 4 of RFC=
4023, it said =A1=B0The protocol type field in the GRE header  MUST be=
 set to the Ethertype value for MPLS Unicast (0x8847) or  Multicast (0=
x8848).=A1=B1
 
More editorial:
 
   [RFC5640] describes a method =
for improving the load-balancing in 
   Softwire mesh networks [=
RFC5565]. However, this method requires core 
   routers to be able to pe=
rform hash calculation on the fields 
   including the "load=
-balancing" field contained in the L2TPv3 or GRE 

   tunnel header.
Since this document describes various MPLS-in-IP encap= sulations and their capabilities for LB, should probably also include and c= ite [RFC 4817]
 
[Xiaohu] The reference to [RFC 4817] has= been added in the -04 version according to your previous suggestion.<= /o:p>
 
5. Processing Functions  <=
/span>
 
 
   P routers, upon receiving the=
se UDP encapsulated packets, could 
   balance these packets ba=
sed on the hash of the five-tuple of UDP 
   packets. 
Is this setting a new requirement for "P routers&= quot;, making a statement of existing ubiquitous support (citation), or des= cribing an applicability statement for the encapsulation?
 
[Xiaohu] No new requirement for P router= s. It just describes an applicability statement.
 
   Upon receiving these UDP enca=
psulated packets, egress PE routers 
   would decapsulate them b=
y removing the UDP headers and then process 
   them accordingly. <=
/o:p>
 
The document should also discuss packet size issues, P= MTUD, MTU, etc.
 
[Xiaohu] Your observation is correct. Th= is has been addressed in the -04 version according to Eric Osborne's commen= t.
 

I am not sure I see any discussion on packet size.

Thanks again for your valuable comments.=
 

Thanks to you for a most quick turnaround and responding and addressin= g all comments!

-- Carlos.

Best regards,
Xiaohu
 
Thanks,
 
-- Carlos.
 

--_000_95067C434CE250468B77282634C96ED322759BA0xmbalnx02ciscoc_-- From loa@pi.nu Wed Dec 5 11:54:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7C21F8CBD for ; Wed, 5 Dec 2012 11:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFhnAnhS4KsE for ; Wed, 5 Dec 2012 11:54:22 -0800 (PST) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8343621F8CB8 for ; Wed, 5 Dec 2012 11:54:22 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 4C457820F2; Wed, 5 Dec 2012 20:54:18 +0100 (CET) Message-ID: <50BFA663.5050504@pi.nu> Date: Wed, 05 Dec 2012 20:54:11 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org, Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] requst for review of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:54:23 -0000 Working Group, Back in August the authors of draft-ietf-mpls-ldp-ip-pw-capability-02.txt asked for review of the document since it had been update due to feedback on the working group mailing list. To date I've not seen any comments, and is prepared to take this as a silent consent. However, there we will keep the request for review open for one more week before starting the working group last call process. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lucy.yong@huawei.com Wed Dec 5 12:22:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AAA21F8B9A for ; Wed, 5 Dec 2012 12:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SzspioudPWK for ; Wed, 5 Dec 2012 12:22:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 626FE21F89E4 for ; Wed, 5 Dec 2012 12:22:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN25985; Wed, 05 Dec 2012 20:22:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 20:22:04 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 20:22:35 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 12:22:28 -0800 From: Lucy yong To: Vivek Kumar , "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrw Date: Wed, 5 Dec 2012 20:22:28 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.123] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D4485F82Cdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:22:39 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D4485F82Cdfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vivek, I share my opinion. Please see below. From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Viv= ek Kumar Sent: Wednesday, December 05, 2012 5:19 AM To: mpls@ietf.org Subject: [mpls] Some question on draft-xu-mpls-in-udp-04 Hi Authors, I have some question. 1) The draft-xu-mpls-in-udp-04 main purpose seems to be for proving l= oad balancing in IP network for MPLS packets. Is that the only use case of= this new encapsulation method or there can be some more ? [Lucy] This draft proposes mpls-in-udp format to enable better load balanci= ng in IP network for MPLS payload. In fact, as section 4 states, the udp en= capsulation can apply other applications beside MPLS, for example, IP. Howe= ver, potential for other applications are outside scope of this draft. We p= lan to have another draft describe the udp encapsulation in general as ment= ioned in section 4. 2) The draft says that ingress PE router will calculate entropy and e= ncapsulate UDP header with src port containing entropy value . Does this me= an that only PE routers can do UDP encap since PE router can look deep insi= de the packet to calculate entropy ? What if LSR's want to initiate UDP tunnel ? [Lucy] Yes, the solution requires PE to support UDP and proposes to reserve= two UDP port number to indicate the payload type. PE understands the paylo= ad and can get some flow entropy from the payload and insert into UDP src p= ort. Could you elaborate what is the UDP tunnel? Lucy Kindly provide your comments . Regards, Vivek --_000_2691CE0099834E4A9C5044EEC662BB9D4485F82Cdfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vivek,

 

I share my opinion. Pl= ease see below.

 

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04<= /span>

 

Hi  Authors,

  

I have some question.

 

1)      The  draft-xu-mpls-in-udp-04 main purpose seem= s to be for proving load balancing in IP network for MPLS packets.  Is= that the only use case of this new encapsulation method or there can be so= me more ?

[Lucy] This draf= t proposes mpls-in-udp format to enable better load balancing in IP network= for MPLS payload. In fact, as section 4 states, the udp encapsulation can = apply other applications beside MPLS, for example, IP. However, potential for other applications are outside sco= pe of this draft. We plan to have another draft describe the udp encapsulat= ion in general as mentioned in section 4.

 

2)      The draft says that ingress PE router will calculat= e entropy and  encapsulate UDP header with src port containing entropy= value . Does this mean that only PE routers can do UDP encap since PE rout= er can look deep inside the packet to calculate entropy ?

        &nbs= p;       What if LSR’s want to initiate= UDP tunnel ?

[Lucy] Yes, the = solution requires PE to support UDP and proposes to reserve two UDP port nu= mber to indicate the payload type. PE understands the payload and can get s= ome flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP tunnel?=

 

Lucy<= /b>

 

Kindly provide your comments .

 

Regards,

Vivek

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D4485F82Cdfweml505mbx_-- From gregory.mirsky@ericsson.com Wed Dec 5 15:41:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8948E21F85E8 for ; Wed, 5 Dec 2012 15:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyDkaykRjnk1 for ; Wed, 5 Dec 2012 15:41:39 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A5DCA21F85DA for ; Wed, 5 Dec 2012 15:41:39 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qB5Np4XM011286; Wed, 5 Dec 2012 17:51:05 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Dec 2012 18:41:32 -0500 Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 18:41:31 -0500 From: Gregory Mirsky To: Rolf Winter , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHN0VxJlaR5XVhT/UaZmQSyL/75l5gHYOjwgAB15ID//6/AQIABFS8AgACovICAAPAtgIAAqA8Q Date: Wed, 5 Dec 2012 23:41:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11201FC2B@eusaamb103.ericsson.se> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11201FC2Beusaamb103ericsso_" MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:41:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11201FC2Beusaamb103ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rolf, please find my notes in-lined below and tagged by GIM>>. Regards, Greg -----Original Message----- From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] Sent: Wednesday, December 05, 2012 12:23 AM To: Gregory Mirsky; mpls@ietf.org Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map Hi Greg, see inline. NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 > Hi Rolf, > I'll think that per MEG MIPs, even though they are on the same LSP/PW, > in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence > different SPMEs. If such interpretation is acceptable, then we can > have multiple MIPs but only one MIP per MEG Level (even though no such > construct was introduced in MPLS-TP OAM model, unfortunately IMHO). Again, I don't see why to force this, what this would actually gain, why to= introduce an artificial constraint and force people to manage MEG levels a= s opposed to multiple MIPs per MEG. You can implement it this way if you wi= sh but I do not see a compelling argument why to force it (and therefore di= sallow something that _all_ RFCs have allowed to date). GIM>> Yes, some architectural constrcts, paradigms have to be enforced. Sup= port of multiple MIPs on a given LSP/PW on particular LSR/(S-)PE through us= e of SPME, IMHO, acceptable solution to the requirement. And as I've been w= riting previous sentense I've realized I'm not sure whether MPLS-TP OAM all= ows MIP on LER/T-PE nodes, i.e. where MEPs reside. Ethernet OAM, AFAIK, mak= es such combination optional, but not a requirement. > And I think that distinction, if any, between in-, out- and nodal MIP > should not be required for unidirectional MPLS-TP constructs as it is > not practical since Loopback mode can not be exercised as there's no > return path via data plane. Thus examples with p2mp scenarios are not > applicable, IMHO, to this discussion. A return path will be out of band, yes. But if you proclaim that if there i= s no data plane return path and therefore in- and out- MIP distinction is u= seless that doesn't compute at my end. I mean, if MIP functionality is usef= ul in any scenario, the distinction can help operators to do a better OAM j= ob (and I believe restricting the discussion to loopback is not helpful her= e either). GIM>> RFC 6435 states in Section 4.1 Operational Prerequisites: Obviously, for the loopback function to operate, there are several prerequisites: - There must be a return path, so the transport path under test must be bidirectional. I read it that out of band return path would not suffice the abovementioned= requirement to use MPLS-TP loopback. Perhaps another packet transport can = work, but not MPLS-TP. > > Regards, > Greg > > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > ] > Sent: Tuesday, December 04, 2012 12:00 AM > To: Gregory Mirsky; mpls@ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map > > Hi Greg, > > you might not be convinced but there are operators that have asked for > this functionality based on operational experience. > > Quoting the OAM framework RFC: > > " Once a MEG is configured, the operator can enable/disable the MIPs on > the nodes within the MEG. All the intermediate nodes and possibly > the end nodes host MIP(s). Local policy allows them to be enabled > per function and per MEG. The local policy is controlled by the > management system, which may delegate it to the control plane. A > disabled MIP silently discards any received OAM packets." > > Clearly having multiple MIPs per LSP is allowed as per the OAM > framework. I think however the sentence "All the intermediate nodes > and possibly the end nodes host MIP(s)" should really be ""All the > intermediate nodes and possibly the end nodes can host MIP(s)" (Is > this worth filing an errata?). I don't see why one wants to > arbitrarily restrict the number of MIPs per LSP. BTW, as you mention, > the support of multiple MIPs in Ethernet is optional. Quoting the OAM > framework > again: > > "Support of per-interface or per-node MIPs is an implementation > choice." > > So where's the difference? > > Best, > > Rolf > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > ] > > Sent: Montag, 3. Dezember 2012 21:47 > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Rolf, > > I've been thinking about that requirement for some time and am not > > convinced that such requirement, support multiple MIP per LSP/PW on > > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single > > MIP per MD/MEG Level is required and support of multiple MIPs is > optional. > > True, multiple MIPs of different MD/MEG Levels might be enabled on a > > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus such > > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat- > > plane loopback can be used on uni-directional construct. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > > > > ] > > Sent: Monday, December 03, 2012 12:15 PM > > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft-ietf- > > mpls-tp-mip-mep-map@tools.ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Greg, > > > > But that's the whole point of the document. There can be multiple > > in- and out-MIPs per LSP plus in the P2MP case there can be multiple > > out- MIPs per node. It cannot be based local configuration. There > > has to > be > > information inside the OAM frame to address the respective MIP. > > Section > > 4 of the document has a (I believe) pretty good example of this. > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > > > > > > > > ] > > > Sent: Montag, 3. Dezember 2012 19:20 > > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: RE: working group last call on > > > draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Hi Rolf, > > > Do you envision that multiple MIPs, both in- and out-, required to > be > > > supported on a given LSP/PW? I think that only single MIP > > required > > > per LSP/PW on an LSR/PE node. If that is the case, then there > > > might > > be > > > no apparent need to explicitly address in- and out- MIP as such > > > distinction becomes part of local configuration. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org > > > > > > ] On Behalf Of Rolf Winter > > > Sent: Monday, December 03, 2012 5:42 AM > > > To: Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp- > > mip- > > > mep-map > > > > > > Loa, > > > > > > These have been mentioned: > > > > > > 1. CV between a MEP and a MIP > > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > > MIPs > > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > > > > > Best, > > > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.nu > > > > > ] > > > > Sent: Freitag, 30. November 2012 11:41 > > > > To: mpls@ietf.org > > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > > > mpls-ads@tools.ietf.org > > > > Subject: Re: working group last call on > > > > draft-ietf-mpls-tp-mip-mep- > > > map > > > > > > > > Authors, > > > > > > > > Can you plese give me an indication of which OAM functions the > > > > separation of in and out MIPs are intended for? > > > > > > > > /Loa > > > > > > > > > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > > > > > Working Group, > > > > > > > > > > This is to start a 2 week working group last call on > > > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > > > > > Please send your comments to the mpls working group mailing > list > > > > > (mpls@ietf.org). > > > > > > > > > > Please send both technical comments, and if you are happy with > > the > > > > > document as is also indications of support. > > > > > > > > > > This working group last call will end on November 28. > > > > > > > > > > /Loa > > > > > for the wg co-chairs > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Loa Andersson email: > > > loa.andersson@ericsson.com > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > +46 767 72 92 13 > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > --_000_7347100B5761DC41A166AC17F22DF11201FC2Beusaamb103ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Rolf,
please find my notes in-lined below and tagged by GIM>>.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
Sent: Wednesday, December 05, 2012 12:23 AM
To: Gregory Mirsky; mpls@ietf.org
Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map=
 
Hi Greg,
 
see inline.
 
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, Lo= ndon W3 6BL | Registered in England 2832014
 
 
> Hi Rolf,
> I'll think that per MEG MIPs, even though they are on the same LS= P/PW,
> in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence <= /div>
> different SPMEs. If such interpretation is acceptable, then we ca= n
> have multiple MIPs but only one MIP per MEG Level (even though no= such
> construct was introduced in MPLS-TP OAM model, unfortunately IMHO= ).
 
Again, I don't see why to force this, what this would actually gain, w= hy to introduce an artificial constraint and force people to manage MEG lev= els as opposed to multiple MIPs per MEG. You can implement it this way if y= ou wish but I do not see a compelling argument why to force it (and therefore disallow something that _all_ RFCs = have allowed to date).
 
GIM>> Yes, some architectural constrcts, pa= radigms have to be enforced. Support of multiple MIPs on a given LSP/PW on = particular LSR/(S-)PE through use of SPME, IMHO, acceptable solution to the= requirement. And as I've been writing previous sentense I've realized I'm not sure whether MPLS-TP OAM allows MIP on LER/T= -PE nodes, i.e. where MEPs reside. Ethernet OAM, AFAIK, makes such combinat= ion optional, but not a requirement.
 
> And I think that distinction, if any, between in-, out- and nodal= MIP
> should not be required for unidirectional MPLS-TP constructs as i= t is
> not practical since Loopback mode can not be exercised as there's= no
> return path via data plane. Thus examples with p2mp scenarios are= not
> applicable, IMHO, to this discussion.
 
A return path will be out of band, yes. But if you proclaim that if th= ere is no data plane return path and therefore in- and out- MIP distinction= is useless that doesn't compute at my end. I mean, if MIP functionality is= useful in any scenario, the distinction can help operators to do a better OAM job (and I believe restricting the di= scussion to loopback is not helpful here either).
 
GIM>> RFC 6435 states in Section 4.1 Operat= ional Prerequisites:
   Obviously, for the loopback function= to operate, there are several
   prerequisites:
 
   -  There must be a return path,= so the transport path under test must
      be bidirectional.<= /font>
 
I read it that out of band return path would not = suffice the abovementioned requirement to use MPLS-TP loopback. Perhaps ano= ther packet transport can work, but not MPLS-TP.
 
>
>         Regards,
>           =       Greg
>
> -----Original Message-----
> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu
> Sent: Tuesday, December 04, 2012 12:00 AM
> To: Gregory Mirsky; mpls@ietf.org
> Subject: RE: working group last call on draft-ietf-mpls-tp-mip-me= p-map
>
> Hi Greg,
>
> you might not be convinced but there are operators that have aske= d for
> this functionality based on operational experience.
>
> Quoting the OAM framework RFC:
>
> " Once a MEG is configured, the operator can enable/disable = the MIPs on
>    the nodes within the MEG.  All the interme= diate nodes and possibly
>    the end nodes host MIP(s).  Local policy a= llows them to be enabled
>    per function and per MEG.  The local polic= y is controlled by the
>    management system, which may delegate it to the= control plane.  A
>    disabled MIP silently discards any received OAM= packets."
>
> Clearly having multiple MIPs per LSP is allowed as per the OAM
> framework. I think however the sentence "All the intermediat= e nodes
> and possibly the end nodes host MIP(s)" should really be &qu= ot;"All the
> intermediate nodes and possibly the end nodes can host MIP(s)&quo= t; (Is
> this worth filing an errata?). I don't see why one wants to
> arbitrarily restrict the number of MIPs per LSP. BTW, as you ment= ion,
> the support of multiple MIPs in Ethernet is optional. Quoting the= OAM
> framework
> again:
>
> "Support of per-interface or per-node MIPs is an implementat= ion
> choice."
>
> So where's the difference?
>
> Best,
>
> Rolf
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Roa= d,
> London W3 6BL | Registered in England 2832014
>
>
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com
> > <mailto:gregory.mirsky@ericsson.com> ]
> > Sent: Montag, 3. Dezember 2012 21:47
> > To: Rolf Winter; Loa Andersson; mpls@ietf.org
> > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; dra= ft-ietf-
> > mpls-tp-mip-mep-map@tools.ietf.org
> > Subject: RE: working group last call on draft-ietf-mpls-tp-m= ip-mep-
> map
> >
> > Hi Rolf,
> > I've been thinking about that requirement for some time and = am not
> > convinced that such requirement, support multiple MIP per LS= P/PW on
> > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of= single
> > MIP per MD/MEG Level is required and support of multiple MIP= s is
> optional.
> > True, multiple MIPs of different MD/MEG Levels might be enab= led on a
> > node but in MPLS-TP we use SPME to model MD/MEG Levels and t= hus such
> > MIPs are on different LSPs. As for p2mp case, I'm not sure h= ow dat-
> > plane loopback can be used on uni-directional construct.
> >
> >         Regards,
> >          &= nbsp;      Greg
> >
> > -----Original Message-----
> > From: Rolf Winter [= mailto:Rolf.Winter@neclab.eu
> > Sent: Monday, December 03, 2012 12:15 PM
> > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org
> > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; dra= ft-ietf-
> > mpls-tp-mip-mep-map@tools.ietf.org
> > Subject: RE: working group last call on draft-ietf-mpls-tp-m= ip-mep-
> map
> >
> > Hi Greg,
> >
> > But that's the whole point of the document. There can be mul= tiple
> > in- and out-MIPs per LSP plus in the P2MP case there can be = multiple
> > out- MIPs per node. It cannot be based local configuration. = There
> > has to
> be
> > information inside the OAM frame to address the respective M= IP.
> > Section
> > 4 of the document has a (I believe) pretty good example of t= his.
> >
> > Best,
> >
> > Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victori= a Road,
> > London W3 6BL | Registered in England 2832014
> >
> >
> > > -----Original Message-----
> > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com
> > > <mailto:gregory.mirsky@ericsson.com>
> > > Sent: Montag, 3. Dezember 2012 19:20
> > > To: Rolf Winter; Loa Andersson; mpls@ietf.org
> > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org= ; draft-
> ietf-
> > > mpls-tp-mip-mep-map@tools.ietf.org
> > > Subject: RE: working group last call on
> > > draft-ietf-mpls-tp-mip-mep-
> > map
> > >
> > > Hi Rolf,
> > > Do you envision that multiple MIPs, both in- and out-, = required to
> be
> > > supported on a given LSP/PW? I think that  &n= bsp;  only single MIP
> > required
> > > per LSP/PW on an LSR/PE node. If that is the case, then= there
> > > might
> > be
> > > no apparent need to explicitly address in- and out- MIP= as such
> > > distinction becomes part of local configuration.
> > >
> > >        Regards,
> > >         &n= bsp;      Greg
> > >
> > > -----Original Message-----
> > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org
> > > <mailto:mpls-bounces@ietf.org> > ] On Beh= alf Of Rolf Winter
> > > Sent: Monday, December 03, 2012 5:42 AM
> > > To: Loa Andersson; mpls@ietf.org
> > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org= ; draft-
> ietf-
> > > mpls-tp-mip-mep-map@tools.ietf.org
> > > Subject: Re: [mpls] working group last call on draft-ie= tf-mpls-tp-
> > mip-
> > > mep-map
> > >
> > > Loa,
> > >
> > > These have been mentioned:
> > >
> > > 1. CV between a MEP and a MIP
> > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW = containing
> > MIPs
> > > 3. data-plane loopback configuration at a MIP 4. diagno= stic tests
> > >
> > > Best,
> > >
> > > Rolf
> > >
> > > NEC Europe Limited | Registered Office: NEC House, 1 Vi= ctoria
> > > Road, London W3 6BL | Registered in England 2832014
> > >
> > >
> > > > -----Original Message-----
> > > > From: Loa Andersson [= mailto:loa@pi.nu <mailto:loa@pi.nu> <= /div>
> > > > Sent: Freitag, 30. November 2012 11:41
> > > > To: mpls@ietf.org
> > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux;<= /div>
> > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org;
> > > > mpls-ads@tools.ietf.org
> > > > Subject: Re: working group last call on
> > > > draft-ietf-mpls-tp-mip-mep-
> > > map
> > > >
> > > > Authors,
> > > >
> > > > Can you plese give me an indication of which OAM f= unctions the
> > > > separation of in and out MIPs are intended for?
> > > >
> > > > /Loa
> > > >
> > > >
> > > >
> > > > On 2012-11-14 16:16, Loa Andersson wrote:
> > > > >
> > > > > Working Group,
> > > > >
> > > > > This is to start a 2 week working group last = call on
> > > > > draft-ietf-mpls-tp-mip-mep-map.
> > > > >
> > > > > Please send your comments to the mpls working= group mailing
> list
> > > > > (mpls@ietf.org).
> > > > >
> > > > > Please send both technical comments, and if y= ou are happy with
> > the
> > > > > document as is also indications of support.
> > > > >
> > > > > This working group last call will end on Nove= mber 28.
> > > > >
> > > > > /Loa
> > > > > for the wg co-chairs
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Loa Andersson      &= nbsp;           &nbs= p;      email:
> > > loa.andersson@ericsson.com
> > > > Sr Strategy and Standards Manager   = ;         loa@pi.nu
> > > > Ericsson Inc      &n= bsp;            = ;       phone: +46 10 717 52 13
> > > >        &nb= sp;            =             &nb= sp;            = +46 767 72 92 13
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> >
>
 
 --_000_7347100B5761DC41A166AC17F22DF11201FC2Beusaamb103ericsso_-- From Manuel.Paul@telekom.de Wed Dec 5 15:50:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA62221F8C57 for ; Wed, 5 Dec 2012 15:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB9LuSwTNla8 for ; Wed, 5 Dec 2012 15:50:21 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3187121F8C51 for ; Wed, 5 Dec 2012 15:50:21 -0800 (PST) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 06 Dec 2012 00:50:19 +0100 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE113414.emea1.cds.t-internal.com (10.125.65.80) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 6 Dec 2012 00:50:17 +0100 Received: from HE101452.emea1.cds.t-internal.com ([10.125.92.148]) by HE113559.emea1.cds.t-internal.com ([2002:7cd:4165::7cd:4165]) with mapi; Thu, 6 Dec 2012 00:50:17 +0100 From: To: , , Date: Thu, 6 Dec 2012 00:50:16 +0100 Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLCAAD1PAIAAL8Jw///5M4CAAMon4IAA8bMAgACmioCAAF7wAA== Message-ID: <9435EDACD941174099E143BCA2BCD615FB98C2AAD4@HE101452.emea1.cds.t-internal.com> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 23:50:23 -0000 VmVyeSB3ZWxsIHB1dCwgUm9sZi4NCg0KSXQgaXMgYWxzbyBiZSBjb25zaWRlcmVkLCB0aGF0IHRo ZSBjdXJyZW50IFNQTUUgY29uc3RydWN0IGhhcyBzb21lIChtb3N0bHkgb3BlcmF0aW9uYWwpIGRl ZmljaWVuY2llcyBvZiBpdCdzIG93biwgYXMgcG9pbnRlZCBvdXQgYnkgZHJhZnQtaWV0Zi1tcGxz LXRwLXRlbXBvcmFsLWhpdGxlc3MtcHNtLg0KDQpUaGFua3MsDQpNYW51ZWwNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBSb2xmIFdpbnRlcg0KPiBT ZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDA1LCAyMDEyIDU6MjMgUE0NCj4gVG86IEdyZWdvcnkg TWlyc2t5OyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbXBsc10gd29ya2luZyBncm91 cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXRwLW1pcC1tZXAtDQo+IG1hcA0KPg0KPiBI aSBHcmVnLA0KPg0KPiBzZWUgaW5saW5lLg0KPg0KPiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdp c3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbg0KPiBXMyA2 QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzMjAxNA0KPg0KPg0KPiA+IEhpIFJvbGYsDQo+ ID4gSSdsbCB0aGluayB0aGF0IHBlciBNRUcgTUlQcywgZXZlbiB0aG91Z2ggdGhleSBhcmUgb24g dGhlIHNhbWUgTFNQL1BXLA0KPiA+IGluIE1QTFMtVFAsIElNSE8sIGJlbG9uZyBpbiBmYWN0IHRv IGRpZmZlcmVudCBNRUcgTGV2ZWxzLCBoZW5jZQ0KPiA+IGRpZmZlcmVudCBTUE1Fcy4gSWYgc3Vj aCBpbnRlcnByZXRhdGlvbiBpcyBhY2NlcHRhYmxlLCB0aGVuIHdlIGNhbiBoYXZlDQo+ID4gbXVs dGlwbGUgTUlQcyBidXQgb25seSBvbmUgTUlQIHBlciBNRUcgTGV2ZWwgKGV2ZW4gdGhvdWdoIG5v IHN1Y2gNCj4gPiBjb25zdHJ1Y3Qgd2FzIGludHJvZHVjZWQgaW4gTVBMUy1UUCBPQU0gbW9kZWws IHVuZm9ydHVuYXRlbHkgSU1ITykuDQo+DQo+IEFnYWluLCBJIGRvbid0IHNlZSB3aHkgdG8gZm9y Y2UgdGhpcywgd2hhdCB0aGlzIHdvdWxkIGFjdHVhbGx5IGdhaW4sIHdoeQ0KPiB0byBpbnRyb2R1 Y2UgYW4gYXJ0aWZpY2lhbCBjb25zdHJhaW50IGFuZCBmb3JjZSBwZW9wbGUgdG8gbWFuYWdlIE1F Rw0KPiBsZXZlbHMgYXMgb3Bwb3NlZCB0byBtdWx0aXBsZSBNSVBzIHBlciBNRUcuIFlvdSBjYW4g aW1wbGVtZW50IGl0IHRoaXMgd2F5DQo+IGlmIHlvdSB3aXNoIGJ1dCBJIGRvIG5vdCBzZWUgYSBj b21wZWxsaW5nIGFyZ3VtZW50IHdoeSB0byBmb3JjZSBpdCAoYW5kDQo+IHRoZXJlZm9yZSBkaXNh bGxvdyBzb21ldGhpbmcgdGhhdCBfYWxsXyBSRkNzIGhhdmUgYWxsb3dlZCB0byBkYXRlKS4NCj4N Cj4gPiBBbmQgSSB0aGluayB0aGF0IGRpc3RpbmN0aW9uLCBpZiBhbnksIGJldHdlZW4gaW4tLCBv dXQtIGFuZCBub2RhbCBNSVANCj4gPiBzaG91bGQgbm90IGJlIHJlcXVpcmVkIGZvciB1bmlkaXJl Y3Rpb25hbCBNUExTLVRQIGNvbnN0cnVjdHMgYXMgaXQgaXMNCj4gPiBub3QgcHJhY3RpY2FsIHNp bmNlIExvb3BiYWNrIG1vZGUgY2FuIG5vdCBiZSBleGVyY2lzZWQgYXMgdGhlcmUncyBubw0KPiA+ IHJldHVybiBwYXRoIHZpYSBkYXRhIHBsYW5lLiBUaHVzIGV4YW1wbGVzIHdpdGggcDJtcCBzY2Vu YXJpb3MgYXJlIG5vdA0KPiA+IGFwcGxpY2FibGUsIElNSE8sIHRvIHRoaXMgZGlzY3Vzc2lvbi4N Cj4NCj4gQSByZXR1cm4gcGF0aCB3aWxsIGJlIG91dCBvZiBiYW5kLCB5ZXMuIEJ1dCBpZiB5b3Ug cHJvY2xhaW0gdGhhdCBpZiB0aGVyZQ0KPiBpcyBubyBkYXRhIHBsYW5lIHJldHVybiBwYXRoIGFu ZCB0aGVyZWZvcmUgaW4tIGFuZCBvdXQtIE1JUCBkaXN0aW5jdGlvbiBpcw0KPiB1c2VsZXNzIHRo YXQgZG9lc24ndCBjb21wdXRlIGF0IG15IGVuZC4gSSBtZWFuLCBpZiBNSVAgZnVuY3Rpb25hbGl0 eSBpcw0KPiB1c2VmdWwgaW4gYW55IHNjZW5hcmlvLCB0aGUgZGlzdGluY3Rpb24gY2FuIGhlbHAg b3BlcmF0b3JzIHRvIGRvIGEgYmV0dGVyDQo+IE9BTSBqb2IgKGFuZCBJIGJlbGlldmUgcmVzdHJp Y3RpbmcgdGhlIGRpc2N1c3Npb24gdG8gbG9vcGJhY2sgaXMgbm90DQo+IGhlbHBmdWwgaGVyZSBl aXRoZXIpLg0KPg0KPiA+DQo+ID4gICAgICAgICBSZWdhcmRzLA0KPiA+ICAgICAgICAgICAgICAg ICBHcmVnDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFJv bGYgV2ludGVyIFttYWlsdG86Um9sZi5XaW50ZXJAbmVjbGFiLmV1DQo+ID4gPG1haWx0bzpSb2xm LldpbnRlckBuZWNsYWIuZXU+IF0NCj4gPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAx MiAxMjowMCBBTQ0KPiA+IFRvOiBHcmVnb3J5IE1pcnNreTsgbXBsc0BpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFJFOiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAt bWlwLW1lcC1tYXANCj4gPg0KPiA+IEhpIEdyZWcsDQo+ID4NCj4gPiB5b3UgbWlnaHQgbm90IGJl IGNvbnZpbmNlZCBidXQgdGhlcmUgYXJlIG9wZXJhdG9ycyB0aGF0IGhhdmUgYXNrZWQgZm9yDQo+ ID4gdGhpcyBmdW5jdGlvbmFsaXR5IGJhc2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuDQo+ ID4NCj4gPiBRdW90aW5nIHRoZSBPQU0gZnJhbWV3b3JrIFJGQzoNCj4gPg0KPiA+ICIgT25jZSBh IE1FRyBpcyBjb25maWd1cmVkLCB0aGUgb3BlcmF0b3IgY2FuIGVuYWJsZS9kaXNhYmxlIHRoZSBN SVBzIG9uDQo+ID4gICAgdGhlIG5vZGVzIHdpdGhpbiB0aGUgTUVHLiAgQWxsIHRoZSBpbnRlcm1l ZGlhdGUgbm9kZXMgYW5kIHBvc3NpYmx5DQo+ID4gICAgdGhlIGVuZCBub2RlcyBob3N0IE1JUChz KS4gIExvY2FsIHBvbGljeSBhbGxvd3MgdGhlbSB0byBiZSBlbmFibGVkDQo+ID4gICAgcGVyIGZ1 bmN0aW9uIGFuZCBwZXIgTUVHLiAgVGhlIGxvY2FsIHBvbGljeSBpcyBjb250cm9sbGVkIGJ5IHRo ZQ0KPiA+ICAgIG1hbmFnZW1lbnQgc3lzdGVtLCB3aGljaCBtYXkgZGVsZWdhdGUgaXQgdG8gdGhl IGNvbnRyb2wgcGxhbmUuICBBDQo+ID4gICAgZGlzYWJsZWQgTUlQIHNpbGVudGx5IGRpc2NhcmRz IGFueSByZWNlaXZlZCBPQU0gcGFja2V0cy4iDQo+ID4NCj4gPiBDbGVhcmx5IGhhdmluZyBtdWx0 aXBsZSBNSVBzIHBlciBMU1AgaXMgYWxsb3dlZCBhcyBwZXIgdGhlIE9BTQ0KPiA+IGZyYW1ld29y ay4gSSB0aGluayBob3dldmVyIHRoZSBzZW50ZW5jZSAiQWxsIHRoZSBpbnRlcm1lZGlhdGUgbm9k ZXMgYW5kDQo+ID4gcG9zc2libHkgdGhlIGVuZCBub2RlcyBob3N0IE1JUChzKSIgc2hvdWxkIHJl YWxseSBiZSAiIkFsbCB0aGUNCj4gPiBpbnRlcm1lZGlhdGUgbm9kZXMgYW5kIHBvc3NpYmx5IHRo ZSBlbmQgbm9kZXMgY2FuIGhvc3QgTUlQKHMpIiAoSXMgdGhpcw0KPiA+IHdvcnRoIGZpbGluZyBh biBlcnJhdGE/KS4gSSBkb24ndCBzZWUgd2h5IG9uZSB3YW50cyB0byBhcmJpdHJhcmlseQ0KPiA+ IHJlc3RyaWN0IHRoZSBudW1iZXIgb2YgTUlQcyBwZXIgTFNQLiBCVFcsIGFzIHlvdSBtZW50aW9u LCB0aGUgc3VwcG9ydA0KPiA+IG9mIG11bHRpcGxlIE1JUHMgaW4gRXRoZXJuZXQgaXMgb3B0aW9u YWwuIFF1b3RpbmcgdGhlIE9BTSBmcmFtZXdvcmsNCj4gPiBhZ2FpbjoNCj4gPg0KPiA+ICJTdXBw b3J0IG9mIHBlci1pbnRlcmZhY2Ugb3IgcGVyLW5vZGUgTUlQcyBpcyBhbiBpbXBsZW1lbnRhdGlv bg0KPiA+IGNob2ljZS4iDQo+ID4NCj4gPiBTbyB3aGVyZSdzIHRoZSBkaWZmZXJlbmNlPw0KPiA+ DQo+ID4gQmVzdCwNCj4gPg0KPiA+IFJvbGYNCj4gPg0KPiA+IE5FQyBFdXJvcGUgTGltaXRlZCB8 IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4gPiBMb25k b24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQNCj4gPg0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogR3JlZ29yeSBNaXJza3kg W21haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20NCj4gPiA+IDxtYWlsdG86Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPiBdDQo+ID4gPiBTZW50OiBNb250YWcsIDMuIERlemVtYmVy IDIwMTIgMjE6NDcNCj4gPiA+IFRvOiBSb2xmIFdpbnRlcjsgTG9hIEFuZGVyc3NvbjsgbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gQ2M6IG1wbHMtYWRzQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi0NCj4gPiA+IG1wbHMtdHAtbWlwLW1lcC1tYXBAdG9v bHMuaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv biBkcmFmdC1pZXRmLW1wbHMtdHAtbWlwLW1lcC0NCj4gPiBtYXANCj4gPiA+DQo+ID4gPiBIaSBS b2xmLA0KPiA+ID4gSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHRoYXQgcmVxdWlyZW1lbnQgZm9y IHNvbWUgdGltZSBhbmQgYW0gbm90DQo+ID4gPiBjb252aW5jZWQgdGhhdCBzdWNoIHJlcXVpcmVt ZW50LCBzdXBwb3J0IG11bHRpcGxlIE1JUCBwZXIgTFNQL1BXIG9uDQo+ID4gPiBnaXZlbiBMU1Iv UEUsIGV4aXN0cy4gQUZBSUssIGluIEV0aGVybmV0IE9BTSBvbmx5IHN1cHBvcnQgb2Ygc2luZ2xl DQo+ID4gPiBNSVAgcGVyIE1EL01FRyBMZXZlbCBpcyByZXF1aXJlZCBhbmQgc3VwcG9ydCBvZiBt dWx0aXBsZSBNSVBzIGlzDQo+ID4gb3B0aW9uYWwuDQo+ID4gPiBUcnVlLCBtdWx0aXBsZSBNSVBz IG9mIGRpZmZlcmVudCBNRC9NRUcgTGV2ZWxzIG1pZ2h0IGJlIGVuYWJsZWQgb24gYQ0KPiA+ID4g bm9kZSBidXQgaW4gTVBMUy1UUCB3ZSB1c2UgU1BNRSB0byBtb2RlbCBNRC9NRUcgTGV2ZWxzIGFu ZCB0aHVzIHN1Y2gNCj4gPiA+IE1JUHMgYXJlIG9uIGRpZmZlcmVudCBMU1BzLiBBcyBmb3IgcDJt cCBjYXNlLCBJJ20gbm90IHN1cmUgaG93IGRhdC0NCj4gPiA+IHBsYW5lIGxvb3BiYWNrIGNhbiBi ZSB1c2VkIG9uIHVuaS1kaXJlY3Rpb25hbCBjb25zdHJ1Y3QuDQo+ID4gPg0KPiA+ID4gICAgICAg ICBSZWdhcmRzLA0KPiA+ID4gICAgICAgICAgICAgICAgIEdyZWcNCj4gPiA+DQo+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogUm9sZiBXaW50ZXIgW21haWx0bzpS b2xmLldpbnRlckBuZWNsYWIuZXUNCj4gPiA+IDxtYWlsdG86Um9sZi5XaW50ZXJAbmVjbGFiLmV1 PiA8bWFpbHRvOlJvbGYuV2ludGVyQG5lY2xhYi5ldQ0KPiA+ID4gPG1haWx0bzpSb2xmLldpbnRl ckBuZWNsYWIuZXU+ID4gXQ0KPiA+ID4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAx MjoxNSBQTQ0KPiA+ID4gVG86IEdyZWdvcnkgTWlyc2t5OyBMb2EgQW5kZXJzc29uOyBtcGxzQGll dGYub3JnDQo+ID4gPiBDYzogbXBscy1hZHNAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLQ0KPiA+ID4gbXBscy10cC1taXAtbWVwLW1hcEB0b29s cy5pZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtbXBscy10cC1taXAtbWVwLQ0KPiA+IG1hcA0KPiA+ID4NCj4gPiA+IEhpIEdy ZWcsDQo+ID4gPg0KPiA+ID4gQnV0IHRoYXQncyB0aGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRvY3Vt ZW50LiBUaGVyZSBjYW4gYmUgbXVsdGlwbGUgaW4tDQo+ID4gPiBhbmQgb3V0LU1JUHMgcGVyIExT UCBwbHVzIGluIHRoZSBQMk1QIGNhc2UgdGhlcmUgY2FuIGJlIG11bHRpcGxlIG91dC0NCj4gPiA+ IE1JUHMgcGVyIG5vZGUuIEl0IGNhbm5vdCBiZSBiYXNlZCBsb2NhbCBjb25maWd1cmF0aW9uLiBU aGVyZSBoYXMgdG8NCj4gPiBiZQ0KPiA+ID4gaW5mb3JtYXRpb24gaW5zaWRlIHRoZSBPQU0gZnJh bWUgdG8gYWRkcmVzcyB0aGUgcmVzcGVjdGl2ZSBNSVAuDQo+ID4gPiBTZWN0aW9uDQo+ID4gPiA0 IG9mIHRoZSBkb2N1bWVudCBoYXMgYSAoSSBiZWxpZXZlKSBwcmV0dHkgZ29vZCBleGFtcGxlIG9m IHRoaXMuDQo+ID4gPg0KPiA+ID4gQmVzdCwNCj4gPiA+DQo+ID4gPiBSb2xmDQo+ID4gPg0KPiA+ ID4gTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBW aWN0b3JpYSBSb2FkLA0KPiA+ID4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAyODMyMDE0DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPiA+ID4gRnJvbTogR3JlZ29yeSBNaXJza3kgW21haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb20NCj4gPiA+ID4gPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+ DQo+ID4gPiA+IDxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tDQo+ID4gPiA+IDxt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPiA+IF0NCj4gPiA+ID4gU2VudDogTW9u dGFnLCAzLiBEZXplbWJlciAyMDEyIDE5OjIwDQo+ID4gPiA+IFRvOiBSb2xmIFdpbnRlcjsgTG9h IEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZw0KPiA+ID4gPiBDYzogbXBscy1hZHNAdG9vbHMuaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC0NCj4gPiBpZXRmLQ0KPiA+ ID4gPiBtcGxzLXRwLW1pcC1tZXAtbWFwQHRvb2xzLmlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6 IFJFOiB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtdHAtbWlwLW1l cC0NCj4gPiA+IG1hcA0KPiA+ID4gPg0KPiA+ID4gPiBIaSBSb2xmLA0KPiA+ID4gPiBEbyB5b3Ug ZW52aXNpb24gdGhhdCBtdWx0aXBsZSBNSVBzLCBib3RoIGluLSBhbmQgb3V0LSwgcmVxdWlyZWQg dG8NCj4gPiBiZQ0KPiA+ID4gPiBzdXBwb3J0ZWQgb24gYSBnaXZlbiBMU1AvUFc/IEkgdGhpbmsg dGhhdCAgICAgb25seSBzaW5nbGUgTUlQDQo+ID4gPiByZXF1aXJlZA0KPiA+ID4gPiBwZXIgTFNQ L1BXIG9uIGFuIExTUi9QRSBub2RlLiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGVuIHRoZXJlIG1p Z2h0DQo+ID4gPiBiZQ0KPiA+ID4gPiBubyBhcHBhcmVudCBuZWVkIHRvIGV4cGxpY2l0bHkgYWRk cmVzcyBpbi0gYW5kIG91dC0gTUlQIGFzIHN1Y2gNCj4gPiA+ID4gZGlzdGluY3Rpb24gYmVjb21l cyBwYXJ0IG9mIGxvY2FsIGNvbmZpZ3VyYXRpb24uDQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICBS ZWdhcmRzLA0KPiA+ID4gPiAgICAgICAgICAgICAgICBHcmVnDQo+ID4gPiA+DQo+ID4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gPiA8bWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZz4gPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4g PG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+ID4gXSBPbiBCZWhhbGYgT2YgUm9sZiBXaW50 ZXINCj4gPiA+ID4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiA1OjQyIEFNDQo+ID4g PiA+IFRvOiBMb2EgQW5kZXJzc29uOyBtcGxzQGlldGYub3JnDQo+ID4gPiA+IENjOiBtcGxzLWFk c0B0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LQ0KPiA+ IGlldGYtDQo+ID4gPiA+IG1wbHMtdHAtbWlwLW1lcC1tYXBAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+ ID4gU3ViamVjdDogUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1p ZXRmLW1wbHMtdHAtDQo+ID4gPiBtaXAtDQo+ID4gPiA+IG1lcC1tYXANCj4gPiA+ID4NCj4gPiA+ ID4gTG9hLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGVzZSBoYXZlIGJlZW4gbWVudGlvbmVkOg0KPiA+ ID4gPg0KPiA+ID4gPiAxLiBDViBiZXR3ZWVuIGEgTUVQIGFuZCBhIE1JUA0KPiA+ID4gPiAyLiB0 cmFjZXJvdXRlIG92ZXIgYW4gTVBMUy1UUCBMU1AgYW5kL29yIGFuIE1QTFMtVFAgUFcgY29udGFp bmluZw0KPiA+ID4gTUlQcw0KPiA+ID4gPiAzLiBkYXRhLXBsYW5lIGxvb3BiYWNrIGNvbmZpZ3Vy YXRpb24gYXQgYSBNSVAgNC4gZGlhZ25vc3RpYyB0ZXN0cw0KPiA+ID4gPg0KPiA+ID4gPiBCZXN0 LA0KPiA+ID4gPg0KPiA+ID4gPiBSb2xmDQo+ID4gPiA+DQo+ID4gPiA+IE5FQyBFdXJvcGUgTGlt aXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwNCj4g PiA+ID4gTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ ID4gPiBGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51IDxtYWlsdG86bG9hQHBp Lm51Pg0KPiA+ID4gPiA+IDxtYWlsdG86bG9hQHBpLm51IDxtYWlsdG86bG9hQHBpLm51PiA+IF0N Cj4gPiA+ID4gPiBTZW50OiBGcmVpdGFnLCAzMC4gTm92ZW1iZXIgMjAxMiAxMTo0MQ0KPiA+ID4g PiA+IFRvOiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4gQ2M6IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnOyBNYXJ0aW4gVmlnb3VyZXV4Ow0KPiA+ID4gPiA+IGRyYWZ0LWlldGYtbXBscy10cC0g bWlwLW1lcC1tYXBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4gPiA+ID4gbXBscy1hZHNAdG9vbHMuaWV0 Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24N Cj4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtbWlwLW1lcC0NCj4gPiA+ID4gbWFwDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBBdXRob3JzLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQ2FuIHlvdSBw bGVzZSBnaXZlIG1lIGFuIGluZGljYXRpb24gb2Ygd2hpY2ggT0FNIGZ1bmN0aW9ucyB0aGUNCj4g PiA+ID4gPiBzZXBhcmF0aW9uIG9mIGluIGFuZCBvdXQgTUlQcyBhcmUgaW50ZW5kZWQgZm9yPw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gL0xvYQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4g Pg0KPiA+ID4gPiA+IE9uIDIwMTItMTEtMTQgMTY6MTYsIExvYSBBbmRlcnNzb24gd3JvdGU6DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gV29ya2luZyBHcm91cCwNCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPiBUaGlzIGlzIHRvIHN0YXJ0IGEgMiB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs IG9uDQo+ID4gPiA+ID4gPiBkcmFmdC1pZXRmLW1wbHMtdHAtbWlwLW1lcC1tYXAuDQo+ID4gPiA+ ID4gPg0KPiA+ID4gPiA+ID4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3 b3JraW5nIGdyb3VwIG1haWxpbmcNCj4gPiBsaXN0DQo+ID4gPiA+ID4gPiAobXBsc0BpZXRmLm9y ZykuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gUGxlYXNlIHNlbmQgYm90aCB0ZWNobmljYWwg Y29tbWVudHMsIGFuZCBpZiB5b3UgYXJlIGhhcHB5IHdpdGgNCj4gPiA+IHRoZQ0KPiA+ID4gPiA+ ID4gZG9jdW1lbnQgYXMgaXMgYWxzbyBpbmRpY2F0aW9ucyBvZiBzdXBwb3J0Lg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgd2lsbCBlbmQgb24g Tm92ZW1iZXIgMjguDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gL0xvYQ0KPiA+ID4gPiA+ID4g Zm9yIHRoZSB3ZyBjby1jaGFpcnMNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gLS0NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDoNCj4gPiA+ID4gbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb20NCj4gPiA+ID4gPiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFn ZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4gPiA+ID4gPiBFcmljc3NvbiBJbmMgICAgICAgICAg ICAgICAgICAgICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQo+ID4gPiA+ID4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMN Cj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbXBsc0BpZXRmLm9yZw0KPiA+ID4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPiA+ID4gPGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscz4NCj4gPiA+ID4gPGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4gPiA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPiA+DQo+ID4gPg0KPiA+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGlu ZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQo= From hideki.endo.es@hitachi.com Wed Dec 5 17:41:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391D21F8AF1 for ; Wed, 5 Dec 2012 17:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXey9XPp2yzb for ; Wed, 5 Dec 2012 17:41:21 -0800 (PST) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by ietfa.amsl.com (Postfix) with ESMTP id 879B021F8BB6 for ; Wed, 5 Dec 2012 17:41:20 -0800 (PST) Received: from mlsv6.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 94DD337C8C; Thu, 6 Dec 2012 10:41:19 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv6.hitachi.co.jp (8.13.1/8.13.1) id qB61fJ4N017731; Thu, 6 Dec 2012 10:41:19 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id qB61fI8C014342; Thu, 6 Dec 2012 10:41:19 +0900 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 5C71449005A; Thu, 6 Dec 2012 10:41:18 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id qB61fI211321540; Thu, 6 Dec 2012 10:41:18 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , From: Date: Thu, 6 Dec 2012 10:40:56 +0900 References: <5098CF68.2000105@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD338A7@SJEXCHMB12.corp.ad.broa> <791AD3077F94194BB2BDD13565B6295D555415E0@DAPHNIS.office.hd> <791AD3077F94194BB2BDD13565B6295D55542847@DAPHNIS.office.hd> <4A6CE49E6084B141B15C0713B8993F281BD389A3@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD38CA7@SJEXCHMB12.corp.ad.broa> <63293273-A276-4F9F-AD24-27A70977E445@yahoo.com> <175D51A2-5876-4EEE-9D36-AEE78017A99D@broadcom.com> Priority: normal Importance: normal X400-Content-Identifier: X50BFF78900000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28121206104025USY] Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] working grouplastcallondraft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 01:41:23 -0000 Shahram and Rolf, It is seemed to me that we will reach same conclusions. (1)Shahram's proposal that uses AHC header for identifing in/out-MIP is usuful for a P2P path, but few effectiveness for a P2MP path. (2)Even if Shahram's proposal is applied, we need to parse MIP ID TLV at line rate for fast rate protocol such as diagnostic function. So far, do you agree? If yes, we have a difficulty to implement fast rate protocols in HW. As Rolf sent in other email, we need to consider fixed location of ID TLV. However, we don't need to reconsider all of OAM functions. I mean we need to consider fixed location ID TLV only for fast rate protocol functions. My proposal is that we add some texts such as "The hardware friendly solution such as fixed location of ID TLV should be considered, if the OAM protocol requiring fast rate (e.g. line rate) processing will be developed." Thanks, Hideki Endo >Shahram, > >Yes, this issue is an internal matter to the box as you said, >and I have some experiences to implement this feature in commercial products. >Therefore, I initially had same concern as you. >We, the authors of this draft, requested the fixed location of MIP ID TLV or using ACH header. >However, as Rolf sent to you, in that case, we would need to go back and make changes to a few RFCs. >That was also something people weren't really happy about. > >And, I have understood this issue can be resolved by an optimized implementation. >As Rolf sent, we need this feature for some functions as below; >1. CV between a MEP and a MIP >2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >3. data-plane loopback configuration at a MIP >4. diagnostic tests >In these functions, 1(On-demand CV) and 2(traceroute) would be very slow rate protocol. >Therefor, it is possible for OAM processor/CPU to parse TLVs. >On the other hand, 3(data-plane loopback) and 4(diagnostic tests) would be very fast rate protocol. >It means that these function should be implemented in specific HW with capacity to parse MIP ID TLV >at line rate. > >If your proposal using ACH header is applied, >the specific HW parsing MIP ID TLV at line rate is required for these functions, right? > >Thanks, >Hideki Endo > > >>Hideki, >> >>The whole point of this draft has been to ensure OAM packets addressed to out-MIP reach to the egress ports and are not filtered by in-MIP. And a single bit does that work. Efficiency is an internal matter to the box: >> >>" This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP." >> >> >>It makes me wonder Have you implemented this feature or just doing a research exercise? I as a chip architect have hard time implementing this feature. This is a fact, and you can choose to ignore it. >> >> >> >>Regards, >>Shahram >> >> >>On Dec 4, 2012, at 3:49 AM, "hideki.endo.es@hitachi.com" wrote: >> >>> Shahram, >>> >>> You replied to Rolf in other mail; >>> "For in-MIP a single bit is enough. However for out-MIP >>> the CPU has to drop the unwanted OAM. Not efficient but >>> the system still works. " >>> Yes, that's right. >>> This was my point. >>> >>> Again, even if your solution using ACH header is applied, >>> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >>> in the case of P2MP tree having 100 leafs. >>> >>> Thanks, >>> Hideki Endo >>> >>> >>>> I didn't say I don't need MIPID. I said MIPID lookup can happen in CPU. >>>> >>>> Regards, >>>> Shahram >>>> >>>> >>>> On Dec 4, 2012, at 12:56 AM, "hideki.endo.es@hitachi.com" wrote: >>>> >>>>> Sharhram, >>>>> >>>>> I didn't mean new requirement similar to Figure 7. >>>>> I do think that OAM packets must go through the normal forwarding engine >>>>> without bypass. >>>>> >>>>> As Rolf said in other e-mail, >>>>> -------------------------- >>>>> | -----| >>>>> | | MIP1| >>>>> | ->-| |->---- >>>>> | | | Out | >>>>> | | | i/f | >>>>> | | -----| >>>>> |----- | -----| >>>>> | MIP0| ---- | | MIP2| >>>>> | | | |- | | >>>>> ----->-| In |->-| FW |--->-| Out |->---- >>>>> | i/f | | |- | i/f | >>>>> |----- ---- | -----| >>>>> | | -----| >>>>> | | | MIP3| >>>>> | | | | >>>>> | ->-| Out |->---- >>>>> | | i/f | >>>>> | -----| >>>>> -------------------------- >>>>> The OAM framework describes needs for identifing MIP1 or MIP2 or MIP3 in the P2MP tree individually. >>>>> Here, each out-MIP has different MIP ID. >>>>> If you don't need this machanism, >>>>> how does a out-MIP verify whether the OAM packet is sent to the out-MIP or not? >>>>> >>>>> Thanks, >>>>> Hideki Endo >>>>> >>>>> >>>>>> Hideki, >>>>>> >>>>>> In summary your requirement is similar to Figure 7 , where you are going to bypass the normal forwarding engine and do unicast forwarding of a multicast OAM packet to a single outgoing port. This kind of behavior is explicitly rejected in the draft. >>>>>> >>>>>> Regards, >>>>>> Shahram >>>>>> >>>>>> >>>>>> On Dec 3, 2012, at 10:00 PM, "S. Davari" wrote: >>>>>> >>>>>>> Hi Hideki, >>>>>>> >>>>>>> I think we have a fundamental problem statement difference. Based on your examples I think you are looking in to how to send an OAM packet only to a single out-MIP out of Nxout-MIPs in a P2MP LSP. >>>>>>> >>>>>>> But I don't think this is architecturally sound or even required. Imagine there is no in-MIP at all. We want a multicast OAM packet behaves like a data packet and be replicated to all egress ports. Now if a MIP is configured in say 2 of the egress ports and not the other 98 ones, then the 98 egress ports will drop the OAM packet in HW and won't send them to their CPU. For the other 2 ports with Out-MIP, both will send the packets to their CPU and both CPUs have to process and respond such as with link trace reply or Loopback reply, etc. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Shahram >>>>>>> >>>>>>> >>>>>>> On Dec 3, 2012, at 5:24 PM, wrote: >>>>>>> >>>>>>>> Hi Shahram, >>>>>>>> >>>>>>>> Back and forth. >>>>>>>> Here, let's focus on whether using MIP ID requires unnecessarily parsing in HW or not. >>>>>>>> >>>>>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>>>>> Don't you consider the case when MIPs is configured in the Egress port B,C and D? >>>>>>>> In the case of P2MP, we need to identify the only one out-MIP of these out-MIPs in port B,C and D. >>>>>>>> In that case, your solution has low effectiveness as I pointed out. >>>>>>>> Do I miss something? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hideki Endo >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Using MIP ID as the only method to filter OAM packets to CPU/Processor is not practical. There are many OAM PDUs such as BFD, LSP-Ping, RFC6374 LM/DM, etc. Each has its own format and the TLV can be anywhere. Using MIP ID as the only identifier requires unnecessarily parsing of all these different packet types at line rate in HW. >>>>>>>>> >>>>>>>>> Why not just use a simple bit in the ACH header? We need a n indicator in a fixed location or the solution is not going to be practical in HW. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shahram >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Shahram Davari >>>>>>>>> Sent: Monday, December 03, 2012 4:53 PM >>>>>>>>> To: 'hideki.endo.es@hitachi.com' >>>>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>>>> Subject: RE: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>>> >>>>>>>>> Hi Hideki, >>>>>>>>> >>>>>>>>> I think you need to look at my p-code. F a MIP is not configured in the Egress port, then that egress port won't sent the OAM packet to its processor and drops it. So there is no issue with my proposed method. >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> Shahram >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >>>>>>>>> Sent: Monday, December 03, 2012 4:48 PM >>>>>>>>> To: Shahram Davari >>>>>>>>> Cc: Rolf.Winter@neclab.eu; mpls@ietf.org >>>>>>>>> Subject: Re:Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>>> >>>>>>>>> Hi Shahram, >>>>>>>>> >>>>>>>>> First, as Rolf sent, we need in/out-MIP for >>>>>>>>> 1. CV between a MEP and a MIP >>>>>>>>> 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs >>>>>>>>> 3. data-plane loopback configuration at a MIP >>>>>>>>> 4. diagnostic tests >>>>>>>>> Here, CV means On-demand CV. You may misunderstand as Proactive CV. >>>>>>>>> >>>>>>>>> Second, you wrote; >>>>>>>>> "The issue is that each CPU/processor has limited resources. >>>>>>>>> By sending all OAM MIP packets to both processor you are >>>>>>>>> losing 1/2 of the capacity of each processor. " >>>>>>>>> It depends on implementations, >>>>>>>>> and this issue could NOT be resolved by even your solution that uses ACH header to indicate in/out-MIP. >>>>>>>>> Let's consider P2MP case as you pointed out. >>>>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>>>>> This means that the OAM processor at port D loses its capacity. >>>>>>>>> If we consider the larger number of ports in the LSR which has 100 ports, for example, >>>>>>>>> All OAM MIP packets for out-MIPs port(B, C) are sent to all out-MIPs. >>>>>>>>> This means that the OAM processors at the other 98 ports lose those capacities. >>>>>>>>> Even if your solution using ACH header is applied, >>>>>>>>> it can reduce OAM packets only for in-MIP, which means only 1/101 effectiveness >>>>>>>>> in the case of P2MP for 100 ports. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hideki Endo >>>>>>>>> >>>>>>>>> >>>>>>>>>> Rolf, >>>>>>>>>> >>>>>>>>>> For clarity it is better to use an example. Assume that an LSR has 4 ports (A, B, C, D). Now assume that it receives packets on a unicast LSP-X from port A and forwards them to port B. there can only be 3 configurations: >>>>>>>>>> >>>>>>>>>> 1) MIP on port A (In-MIP), or >>>>>>>>>> 2) MIP on port B (out-MIP), or >>>>>>>>>> 3) MEIP on Port A and B >>>>>>>>>> >>>>>>>>>> A single OAM packet can be terminated and processed only by one of these MIPs. Now assume OAM packet (P) is meant for out-MIP (MIPID =port B). In your example, you are saying send a copy of the P to the CPU/Processor on Port A, and send a copy also to CPU/Processor on Port B. Port A CPU will drop the packet since the MIP-ID is not A. The issue is that each CPU/processor has limited resources. By sending all OAM MIP packets to both processor you are losing 1/2 of the capacity of each processor. The practical solution is to have a simple indicator in the packet header that this OAM packet is meant for Out-MIP. Then port A just switches the OAM packet to Port B, and Port B terminates and sends it to its CPU/processor. >>>>>>>>>> >>>>>>>>>> Lest get to P2MP example. Assume LSP-Y is a P2MP LSP that enters the chip from Port A and is sent to ports B, C, D. Also assume that there is In-MIP on port A and out-MIPs of ports B, C (not D). Now assume a Multicast OAM packet is meant for out-MIPs (B, C). In such case the OAM packet should not be sent to port A CPU/Processor. It is therefore multicast to ports B, C, D. Ports B, C send the OAM packet to their CPU. Port D drops the OAM packets and does not send it to its CPU, since there is no MIP configured for that MPLS label. >>>>>>>>>> >>>>>>>>>> So the Pseudo-code is like this: >>>>>>>>>> >>>>>>>>>> Ingress Port: >>>>>>>>>> >>>>>>>>>> If packet is OAM and TTL=1 >>>>>>>>>> If MIP is enabled >>>>>>>>>> If packet indicates In-MIP >>>>>>>>>> Send to local CPU >>>>>>>>>> Else >>>>>>>>>> Forward to egress port >>>>>>>>>> End >>>>>>>>>> Else >>>>>>>>>> Forward normally >>>>>>>>>> End >>>>>>>>>> Else >>>>>>>>>> >>>>>>>>>> Egress Port: >>>>>>>>>> >>>>>>>>>> If packet is OAM and TTL=1 >>>>>>>>>> If MIP is enabled >>>>>>>>>> If packet indicates In-MIP >>>>>>>>>> Drop packet >>>>>>>>>> Else If packet indicates Out-MIP >>>>>>>>>> Send to local CPU >>>>>>>>>> End >>>>>>>>>> Else >>>>>>>>>> Drop packet >>>>>>>>>> End >>>>>>>>>> End >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using this example could you please describe your reasoning for not requiring HW to identify In-MEP vs out-MIPs? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Shahram >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu] >>>>>>>>>> Sent: Monday, December 03, 2012 12:10 PM >>>>>>>>>> To: Shahram Davari >>>>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>>>> Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>> >>>>>>>>>> But the MIP that is addressed needs to be able to handle this _plus_ take an appropriate action and in the P2MP case this will always be the case since there are 2 or more out MIPs. >>>>>>>>>> >>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Shahram Davari [mailto:davari@broadcom.com] >>>>>>>>>>> Sent: Montag, 3. Dezember 2012 16:27 >>>>>>>>>>> To: Rolf Winter >>>>>>>>>>> Cc: Pablo Frank; mpls@ietf.org >>>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip- >>>>>>>>>>> mep-map >>>>>>>>>>> >>>>>>>>>>> Hi Rolf, >>>>>>>>>>> >>>>>>>>>>> Your HW guys are correct as long as the amount of data sent to the in- >>>>>>>>>>> MIP processor is not much. But from your previous email to Loa I see >>>>>>>>>>> that you want to also terminate CV at MIPs. CVs are fast and high >>>>>>>>>>> bandwidth and blindly dumping them on a CPU or OAM processor that may >>>>>>>>>>> not be expecting them is like DoS attack. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Shahram >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Dec 3, 2012, at 5:53 AM, "Rolf Winter" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> sorry for the belated response. I checked with some of our HW people. >>>>>>>>>>> Here's the gist of their response: >>>>>>>>>>>> >>>>>>>>>>>> Of course they wouldn't like parsing TLVs but we established that >>>>>>>>>>> fact already. Their answer to the problem is slightly different though. >>>>>>>>>>> A TTL-expired OAM frame can simply be copied and forwarded to the out- >>>>>>>>>>> MIPs where, if the frame is not intended for them, it can safely be >>>>>>>>>>> dropped. In the P2MP case e.g. this needs to be done anyway, i.e. the >>>>>>>>>>> implementation must behave in this exact way in either case. So there >>>>>>>>>>> is at least one way to implement this at line rate without going back >>>>>>>>>>> and changing a bunch of RFCs. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Rolf >>>>>>>>>>>> >>>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>>>>>>>>>>> London W3 6BL | Registered in England 2832014 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf >>>>>>>>>>>>> Of Shahram Davari >>>>>>>>>>>>> Sent: Mittwoch, 28. November 2012 18:46 >>>>>>>>>>>>> To: Pablo Frank >>>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>>> >>>>>>>>>>>>> Pablo, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That was exactly my point. Let's use a flag to indicate in-MIP or >>>>>>>>>>>>> out- MIP and then the offline processor can do MEPID lookup to >>>>>>>>>>>>> determine whether this is a legitimate OAM packet or not. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thx >>>>>>>>>>>>> Shahram >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> From: Pablo Frank [mailto:pabloisnot@gmail.com] >>>>>>>>>>>>> Sent: Wednesday, November 28, 2012 8:22 AM >>>>>>>>>>>>> To: Shahram Davari >>>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>> draft-ietf-mpls-tp-mip- mep-map >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I think Shahram raises a very legitimate concern about how expensive >>>>>>>>>>>>> this could be to implement in hardware. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As I understand it, the logic proposed by this draft is as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> At the ingress blade: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>>> >>>>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>>> >>>>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>>> >>>>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>>> >>>>>>>>>>>>> forward normally (but note we must intercept it again on >>>>>>>>>>> egress) >>>>>>>>>>>>> >>>>>>>>>>>>> ELSE >>>>>>>>>>>>> >>>>>>>>>>>>> punt to OAM processor >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> At the egress blade: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> IF TTL-expired && GAL-is-present && GACh-type-is-X THEN >>>>>>>>>>>>> >>>>>>>>>>>>> Parse MIP-ID TLV >>>>>>>>>>>>> >>>>>>>>>>>>> Lookup MIP-ID >>>>>>>>>>>>> >>>>>>>>>>>>> IF MIP-is-egress, THEN >>>>>>>>>>>>> >>>>>>>>>>>>> punt to OAM processor >>>>>>>>>>>>> >>>>>>>>>>>>> ELSE >>>>>>>>>>>>> >>>>>>>>>>>>> drop >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Note all this has to be done in the fast-path now at full line rate >>>>>>>>>>>>> (and hardware guys hate TLVs). Before, the only thing the fast-path >>>>>>>>>>>>> had to do was look for TTL-expiry. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The only reason that ACH reserved bit was rejected (in Appendix A.4 >>>>>>>>>>>>> of >>>>>>>>>>>>> -03 version of doc) was because it also required a MIP-ID lookup. >>>>>>>>>>>>> But I don't see anything wrong with combining both mechanisms. >>>>>>>>>>>>> Ideally, hardware could rely on the reserved bit to do the initial >>>>>>>>>>>>> filtering at full line-rate and then a presumably much more >>>>>>>>>>>>> cost-efficient OAM hardware block could perform the MIP-ID lookup. >>>>>>>>>>>>> Instead of the complex logic above, the fast path gets a simple >>>>>>>>>>>>> modification to TTL handling and the OAM block does the heavy >>>>>>>>>>> lifting of dealing with ACH TLVs, etc. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This seems like a case where practicality should trump elegance. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Pablo >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Nov 26, 2012 at 11:48 AM, Shahram Davari >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Rolf, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am sure you know that TLVs are not Hardware friendly. And I >>>>>>>>>>>>> think you agree with me that this draft requires deep parsing of all >>>>>>>>>>>>> packets at line rate to get to the MIPID TLV. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I still think the MIPID TLV is required to decide whether an >>>>>>>>>>> OAM >>>>>>>>>>>>> packet ended up at the right MIP. But may be a simpler solution >>>>>>>>>>>>> could be augmented to decide between In-MIP and Out-MIP. For example >>>>>>>>>>>>> how about using one of the reserved bits in the ACH header. This >>>>>>>>>>> can >>>>>>>>>>>>> easily be done in hardware with minimum complexity. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Shahram >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On >>>>>>>>>>>>> Behalf Of Rolf Winter >>>>>>>>>>>>>> Sent: Wednesday, November 21, 2012 12:13 PM >>>>>>>>>>>>>> To: S. Davari; adrian@olddog.co.uk >>>>>>>>>>>>>> Cc: mpls@ietf.org >>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on draft-ietf-mpls- >>>>>>>>>>>>> tp-mip-mep-map >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Adrian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You are right and I should have sent these types of comments >>>>>>>>>>>>> before >>>>>>>>>>>>>>> last call. I completely understand the procedure. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One thing I didn't understand in your response is that you >>>>>>>>>>> said >>>>>>>>>>>>> in-MIP >>>>>>>>>>>>>>> requires to do the MEPID lookup at line rate anyway. Why is >>>>>>>>>>>>> that? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My understanding is that before this draft, the process would >>>>>>>>>>>>> have >>>>>>>>>>>>>>> been for the ingress to look at TTL and if it is expired then >>>>>>>>>>>>> send the >>>>>>>>>>>>>>> packet to OAM processor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes (and no). While I assume likely MIP functionality will be >>>>>>>>>>>>> implemented on the ingress, the related RFCs are vague about the >>>>>>>>>>>>> actual placement of the MIP function. See e.g. the OAM Framework >>>>>>>>>>> (RFC >>>>>>>>>>>>> 6371) "per-node MIPs (i.e., a single MIP per node in an unspecified >>>>>>>>>>>>> location within the node)". >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, I think "before this draft" is not quite accurate in that >>>>>>>>>>>>> is suggests there is no per-interface MIP addressing possible as of >>>>>>>>>>> now. >>>>>>>>>>>>> Take RFC 6426. In practice this is where part of the problem lies. >>>>>>>>>>> We >>>>>>>>>>>>> cannot really go back and change all this. There are other >>>>>>>>>>> constraints. >>>>>>>>>>>>> E.g. we have a requirement to address a single out-MIP out of a set >>>>>>>>>>>>> of out-MIPs on a P2MP branch point. So this was part of the >>>>>>>>>>>>> constraints we worked with. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The MEPID that you suggest in this draft is very useful for >>>>>>>>>>>>> filtering >>>>>>>>>>>>>>> out leaked OAM frames from upstream. But lets leave lookup of >>>>>>>>>>>>> the MEPID >>>>>>>>>>>>>>> to the OAM processing module (at slower rate) and add an >>>>>>>>>>>>> indicator to >>>>>>>>>>>>>>> the OAM packet to indicate whether it should be taken out of >>>>>>>>>>>>> the data >>>>>>>>>>>>>>> path in the Ingress or egress. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So can I suggest adding the following text to the draft: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> " In addition to the MEPID, which is used to ultimately accept >>>>>>>>>>>>> or >>>>>>>>>>>>>>> filter out received OAM packets, OAM packets should have a >>>>>>>>>>>>> simple >>>>>>>>>>>>>>> indicator that identifies whether the OAM packet belongs to >>>>>>>>>>>>> in-MIP or >>>>>>>>>>>>>>> Out-MIP". >>>>>>>>>>>>>> >>>>>>>>>>>>>> We also have the question on where to retrofit those bits. I >>>>>>>>>>>>> assume a TLV wouldn't work for the exact reasons you do not like to >>>>>>>>>>>>> have to do a second lookup, since it would require some parsing. All >>>>>>>>>>>>> these constraints and the ones outlined in the document led to where >>>>>>>>>>>>> we are. In a sense this is a non-spec since it rather rules out a >>>>>>>>>>>>> number of things that seem like a good idea at first but then have a >>>>>>>>>>>>> catch of some sort. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rolf >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Shahram >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Nov 21, 2012, at 1:16 AM, "Adrian Farrel" >>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Shahram, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am worried about the precedent of a comment like this >>>>>>>>>>> during >>>>>>>>>>>>> WG >>>>>>>>>>>>>>> last call. >>>>>>>>>>>>>>>> While comments that improve the document or point out >>>>>>>>>>>>> fundamental >>>>>>>>>>>>>>>> flaws are welcome whenever they arrive, points with the >>>>>>>>>>>>> flavour "I >>>>>>>>>>>>>>>> wouldn't have done it like this" that arrive this late in the >>>>>>>>>>>>> process >>>>>>>>>>>>>>> don't feel very constructive. >>>>>>>>>>>>>>>> But I will leave the chair to worry about process and try to >>>>>>>>>>>>> address >>>>>>>>>>>>>>>> the technical points... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Identifying whether to terminate an OAM packet and process >>>>>>>>>>> it >>>>>>>>>>>>> in In- >>>>>>>>>>>>>>> MIP vs. >>>>>>>>>>>>>>>> Out- >>>>>>>>>>>>>>>>> MIP requires line rate lookup, otherwise the OAM packet will >>>>>>>>>>>>> not >>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>>> the same path as data packets. Therefore any MIP identifier >>>>>>>>>>>>> that is >>>>>>>>>>>>>>>>> proposed in this >>>>>>>>>>>>>>>> draft >>>>>>>>>>>>>>>>> requires one extra lookup and therefore adds significantly >>>>>>>>>>> to >>>>>>>>>>>>> cost. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If I am not wrong, this is a feature of an out-MIP. If you >>>>>>>>>>>>> decide to >>>>>>>>>>>>>>>> implement out-MIPs, and if you want the OAM to follow exactly >>>>>>>>>>>>> the >>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>> path as the data, then it is a requirement that the out >>>>>>>>>>>>> interface >>>>>>>>>>>>>>>> inspects the packets (at line >>>>>>>>>>>>>>>> rate) to determine whether they are OAM and targeted at the >>>>>>>>>>>>> interface. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We cannot change that aspect. All we can do is aim to make >>>>>>>>>>> the >>>>>>>>>>>>> lookup >>>>>>>>>>>>>>>> as easy as possible. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps a >>>>>>>>>>>>>>>>> similar method to Ethernet MDL/MEL (Maintenance Domain >>>>>>>>>>>>> Level) may be >>>>>>>>>>>>>>>>> used that requires only 3 bits and achieves the same result. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps it could. >>>>>>>>>>>>>>>> But before going there, why is the lookup in the current >>>>>>>>>>>>> version of >>>>>>>>>>>>>>>> the I-D arduous? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Presumably you do not propose making any change to the way >>>>>>>>>>>>> In-MIPs >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>> currently identified, so the lookups being done at line rate >>>>>>>>>>>>> today on >>>>>>>>>>>>>>>> the incoming interfaces will not be changed. If you are >>>>>>>>>>>>> proposing >>>>>>>>>>>>>>> such >>>>>>>>>>>>>>>> a change, then the discussion is outside the scope of this I- >>>>>>>>>>>>> D and >>>>>>>>>>>>>>>> becomes a much wider question for the working group. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This leaves me with the trade-off of enabling a *simpler* >>>>>>>>>>>>> lookup on >>>>>>>>>>>>>>>> the outgoing interfaces versus doing identical lookups on >>>>>>>>>>> both >>>>>>>>>>>>>>>> interfaces. My assumption was that if the incoming interface >>>>>>>>>>>>> can do >>>>>>>>>>>>>>>> the lookup at line rate, it is not hard to perform the same >>>>>>>>>>>>> lookup on >>>>>>>>>>>>>>>> the outgoing interface. Furthermore, there is a reduction in >>>>>>>>>>>>>>> complexity by having fewer things to look up. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Another possibility is that the full lookup could be done on >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> incoming interface and the packet marked for easy >>>>>>>>>>> interception >>>>>>>>>>>>> on the >>>>>>>>>>>>>>> outgoing interface. >>>>>>>>>>>>>>>> The concern with this approach is that the packet would no >>>>>>>>>>>>> longer be >>>>>>>>>>>>>>>> being forwarded exactly as data because it would be being >>>>>>>>>>>>> modified in >>>>>>>>>>>>>>> flight. >>>>>>>>>>>>>>>> Furthermore, in the case of P2MP, it is not enough to flag >>>>>>>>>>> the >>>>>>>>>>>>> packet >>>>>>>>>>>>>>>> as a local Out-MIP and further identifier-based lookup is >>>>>>>>>>>>> needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some of these issues were raised and discussed as the I-D >>>>>>>>>>>>> progressed, >>>>>>>>>>>>>>>> and some of the alternative solutions were tracked with their >>>>>>>>>>>>> pros >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> cons in Appendix A of the I-D (look at revision -03). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] >>>>>>>>>>> On >>>>>>>>>>>>> Behalf >>>>>>>>>>>>>>>>> Of Adrian Farrel >>>>>>>>>>>>>>>>> Sent: Monday, November 19, 2012 8:45 AM >>>>>>>>>>>>>>>>> To: 't.petch'; 'Loa Andersson'; mpls@ietf.org >>>>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>>>> ; >>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip- >>>>>>>>>>>>>>>>> mep-map@tools.ietf.org >>>>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yeah, it's a boring draft. Did you expect me to co-author >>>>>>>>>>>>> anything >>>>>>>>>>>>>>> else? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The point was that when I started the I-D lots of people >>>>>>>>>>> were >>>>>>>>>>>>> saying >>>>>>>>>>>>>>>>> "it's complex" and "it can't be done" and "it won't be >>>>>>>>>>>>> backward >>>>>>>>>>>>>>> compatible". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So the I-D says "here it is" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A (sorry not to offer you excitement) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>>> From: t.petch [mailto:ietfc@btconnect.com] >>>>>>>>>>>>>>>>>> Sent: 19 November 2012 12:38 >>>>>>>>>>>>>>>>>> To: Loa Andersson; mpls@ietf.org >>>>>>>>>>>>>>>>>> Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org >>>>>>>>>>>>> ; MPLS-TP ad >>>>>>>>>>>>>>>>>> hoc >>>>>>>>>>>>>>>> team; >>>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org >>>>>>>>>>>>>>>>>> Subject: Re: [mpls] working group last call on >>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> After getting to section 6 and its features (requirements!), >>>>>>>>>>>>> I find >>>>>>>>>>>>>>>>>> myself underwhelmed; is that it? Well, I suppose so, it is >>>>>>>>>>>>>>>>>> Informational and not Standards Track. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Meanwhile, I suggest some editorial issues. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Title >>>>>>>>>>>>>>>>>> Handling MPLS-TP OAM Packets Targeted at Internal MIPs >>>>>>>>>>>>> [Handling >>>>>>>>>>>>>>>>>> MPLS-TP OAM Packets Targeted at Interface MIPs seems a more >>>>>>>>>>>>>>>>>> informative statement unless and until you get to the >>>>>>>>>>>>> definition of >>>>>>>>>>>>>>>>>> Internal in s3; and s6, which is the crux of the document >>>>>>>>>>>>> says The >>>>>>>>>>>>>>>>>> preferred solution to per-interface MIP message handling is >>>>>>>>>>>>>>>>>> presented in this section] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> s1 >>>>>>>>>>>>>>>>>> two (or more) MIPs per node on both sides of the forwarding >>>>>>>>>>>>> engine. >>>>>>>>>>>>>>>>>> [two on both sides sounds like four in total to me; suggest >>>>>>>>>>>>> 'one on >>>>>>>>>>>>>>>>>> each side of the forwarding engine'] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> s4 >>>>>>>>>>>>>>>>>> o CV between a MEP and a MIP >>>>>>>>>>>>>>>>>> [expand CV on first use] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> s5 >>>>>>>>>>>>>>>>>> In-band OAM messages are sent using the G-ACh [RFC5586] for >>>>>>>>>>>>> MPLS-TP >>>>>>>>>>>>>>>>>> LSPs and MPLS-TP PWs, respectively. >>>>>>>>>>>>>>>>>> ['respectively' suggests to me that there should be two >>>>>>>>>>>>> precedents, >>>>>>>>>>>>>>>>>> not just RFC5586; the second paragraph specifies RFC5586 >>>>>>>>>>> for >>>>>>>>>>>>> LSPs, >>>>>>>>>>>>>>>>>> RFC6423/RFC4385 for PWs, in which case, strike this >>>>>>>>>>> sentence >>>>>>>>>>>>> as >>>>>>>>>>>>>>>>>> redundant] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> s6 >>>>>>>>>>>>>>>>>> The appendix of this document contains a >>>>>>>>>>>>>>>>>> few solutions that the authors have discarded which have >>>>>>>>>>>>> been >>>>>>>>>>>>>>> left in >>>>>>>>>>>>>>>>>> the document for informational purposes. >>>>>>>>>>>>>>>>>> [not any more they haven't!] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The node itself is addresses >>>>>>>>>>>>>>>>>> [The node itself is addressed] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The identification information indside [The identification >>>>>>>>>>>>>>>>>> information inside ] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> MIP identifiers are not know >>>>>>>>>>>>>>>>>> [MIP identifiers are not known] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> reserved MIP address >>>>>>>>>>>>>>>>>> [reserved MIP addressses or a reserved MIP address] >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Tom Petch >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>>>>> From: "Loa Andersson" >>>>>>>>>>>>>>>>>> To: >>>>>>>>>>>>>>>>>> Cc: ; >>>>>>>>>>>> chairs@tools.ietf.org>; >>>>>>>>>>>>>>>>>> "MPLS-TP ad hoc team" ; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sent: Wednesday, November 14, 2012 3:16 PM >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Working Group, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is to start a 2 week working group last call on >>>>>>>>>>>>>>>>>>> draft-ietf-mpls-tp-mip-mep-map. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please send your comments to the mpls working group >>>>>>>>>>> mailing >>>>>>>>>>>>> list >>>>>>>>>>>>>>>>>>> (mpls@ietf.org). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please send both technical comments, and if you are happy >>>>>>>>>>>>> with the >>>>>>>>>>>>>>>>>>> document as is also indications of support. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This working group last call will end on November 28. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>>>>>> for the wg co-chairs >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>>> >>>>>>>>>>>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>>>>>>>>>> Road, London W3 6BL | Registered in England 2832014 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> mpls mailing list >>>>>>>>>>>>> mpls@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mpls mailing list >>>>>>>>>> mpls@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>>>> _______________________________________________ >>>>>>>> mpls mailing list >>>>>>>> mpls@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From kvivek@broadcom.com Wed Dec 5 20:07:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F71221F8B2A for ; Wed, 5 Dec 2012 20:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ood88vvrTka for ; Wed, 5 Dec 2012 20:07:50 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id F117521F89FF for ; Wed, 5 Dec 2012 20:07:49 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 05 Dec 2012 20:04:46 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 5 Dec 2012 20:07:33 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 5 Dec 2012 20:07:15 -0800 From: "Vivek Kumar" To: "Lucy yong" , "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrwABCZGMA= Date: Thu, 6 Dec 2012 04:07:14 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CDEC6D43R015525548-01-01 Content-Type: multipart/alternative; boundary=_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7SJEXCHMB09corpa_ Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 04:07:51 -0000 --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7SJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks Lucy for your comments. For point 2 ) below I meant that since MPLS label could also have an entrop= y as one of their label , can the proposed approach of UDP encapsulation be= applied to LSR also or it will be restricted for PE only ? Regards, Vivek From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, December 06, 2012 1:52 AM To: Vivek Kumar; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Hi Vivek, I share my opinion. Please see below. From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Vivek Kum= ar Sent: Wednesday, December 05, 2012 5:19 AM To: mpls@ietf.org Subject: [mpls] Some question on draft-xu-mpls-in-udp-04 Hi Authors, I have some question. 1) The draft-xu-mpls-in-udp-04 main purpose seems to be for proving l= oad balancing in IP network for MPLS packets. Is that the only use case of= this new encapsulation method or there can be some more ? [Lucy] This draft proposes mpls-in-udp format to enable better load balanci= ng in IP network for MPLS payload. In fact, as section 4 states, the udp en= capsulation can apply other applications beside MPLS, for example, IP. Howe= ver, potential for other applications are outside scope of this draft. We p= lan to have another draft describe the udp encapsulation in general as ment= ioned in section 4. 2) The draft says that ingress PE router will calculate entropy and e= ncapsulate UDP header with src port containing entropy value . Does this me= an that only PE routers can do UDP encap since PE router can look deep insi= de the packet to calculate entropy ? What if LSR's want to initiate UDP tunnel ? [Lucy] Yes, the solution requires PE to support UDP and proposes to reserve= two UDP port number to indicate the payload type. PE understands the paylo= ad and can get some flow entropy from the payload and insert into UDP src p= ort. Could you elaborate what is the UDP tunnel? Lucy Kindly provide your comments . Regards, Vivek --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7SJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Thanks Lucy for your c= omments.

 

For point 2 ) below I = meant that since MPLS label could also have an entropy as one of their labe= l , can the proposed approach of UDP encapsulation be applied to LSR also o= r it will be restricted for PE only ?

 

Regards,

Vivek

 

 

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Thursday, December 06, 2012 1:52 AM
To: Vivek Kumar; mpls@ietf.org
Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vivek,

 

I share my opinion. Pl= ease see below.

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04<= /span>

 

Hi  Authors,

  

I have some question.

 

1)      The  draft-xu-mpls-in-udp-04 main purpose seem= s to be for proving load balancing in IP network for MPLS packets.  Is= that the only use case of this new encapsulation method or there can be so= me more ?

[Lucy] This draf= t proposes mpls-in-udp format to enable better load balancing in IP network= for MPLS payload. In fact, as section 4 states, the udp encapsulation can = apply other applications beside MPLS, for example, IP. However, potential for other applications are outside sco= pe of this draft. We plan to have another draft describe the udp encapsulat= ion in general as mentioned in section 4.

 

2)      The draft says that ingress PE router will calculat= e entropy and  encapsulate UDP header with src port containing entropy= value . Does this mean that only PE routers can do UDP encap since PE rout= er can look deep inside the packet to calculate entropy ?

        &nbs= p;       What if LSR’s want to initiate= UDP tunnel ?

[Lucy] Yes, the = solution requires PE to support UDP and proposes to reserve two UDP port nu= mber to indicate the payload type. PE understands the payload and can get s= ome flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP tunnel?=

 

Lucy<= /b>

 

Kindly provide your comments .

 

Regards,

Vivek

 

 

--_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7SJEXCHMB09corpa_-- From xuxiaohu@huawei.com Wed Dec 5 23:48:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD121F8D7A for ; Wed, 5 Dec 2012 23:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.694 X-Spam-Level: X-Spam-Status: No, score=-4.694 tagged_above=-999 required=5 tests=[AWL=1.905, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOQxdxihGowB for ; Wed, 5 Dec 2012 23:48:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CDDE621F8D77 for ; Wed, 5 Dec 2012 23:48:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN63024; Thu, 06 Dec 2012 07:48:04 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 07:47:28 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 07:48:00 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 15:47:54 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-in-udp-05.txt Thread-Index: AQHN04J8XY65vHWBoUiXzwIjIPGTjZgLX0jw Date: Thu, 6 Dec 2012 07:47:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07586DB1@szxeml525-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.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 07:48:06 -0000 SGkgYWxsLA0KDQpBbiB1cGRhdGVkIHZlcnNpb24gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAgaXMg c3VibWl0dGVkIG5vdy4gDQoNCk1ham9yIGNoYW5nZXMgb2YgdGhpcyByZXZpc2lvbiBpbmNsdWRl Og0KMSkgRGVsZXRlIHRoZSBzZWN0aW9uIG9mIFNpZ25hbGluZyBmb3IgRW5jYXBzdWxhdGlvbiBp biBVRFA7DQoyKSBBZGQgQ2FybG9zIFBpZ25hdGFybyBhcyBhIG5ldyBjby1hdXRob3I7DQoNCk1p bm9yIGNoYW5nZXMgaW5jbHVkZToNCjEpIEFkZCBtb3JlIHJlZmVyZW5jZXM7IA0KMikgSW1wcm92 ZSB0aGUgcmVhZGFiaWxpdHk7DQozKSBGaXggc2VudGVuY2VzIHRoYXQgYXJlIG92ZXJyZWFjaGlu Zy4NCg0KQW55IGZ1cnRoZXIgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUgKG9uIGJlaGFsZiBvZiBhbGwgY28tYXV0aG9ycykNCg0KPiAtLS0tLemCruS7 tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMuac iDbml6UgMTU6MjMNCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IGNwaWduYXRhQGNp c2NvLmNvbTsgTGl6aGVuYmluOyBuc2hldGhAY29udHJhaWxzeXN0ZW1zLmNvbTsgTHVjeQ0KPiB5 b25nDQo+IOS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1tcGxz LWluLXVkcC0wNS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUt bXBscy1pbi11ZHAtMDUudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg WGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZp bGVuYW1lOgkgZHJhZnQteHUtbXBscy1pbi11ZHANCj4gUmV2aXNpb246CSAwNQ0KPiBUaXRsZToJ CSBFbmNhcHN1bGF0aW5nIE1QTFMgaW4gVURQDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTEyLTA2 DQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDgN Cj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1t cGxzLWluLXVkcC0wNS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LW1wbHMtaW4tdWRwDQo+IEh0bWxpemVkOiAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbXBscy1pbi11ZHAtMDUNCj4gRGlmZjog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC14dS1tcGxz LWluLXVkcC0wNQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEV4aXN0aW5nIHRlY2hub2xvZ2llcyB0 byBlbmNhcHN1bGF0ZSBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcNCj4gICAgKE1QTFMp IG92ZXIgSVAgYXJlIG5vdCBhZGVxdWF0ZSBmb3IgZWZmaWNpZW50IGxvYWQgYmFsYW5jaW5nIG9m IE1QTFMNCj4gICAgYXBwbGljYXRpb24gdHJhZmZpYywgc3VjaCBhcyBNUExTLWJhc2VkIExheWVy MiBWaXJ0dWFsIFByaXZhdGUNCj4gICAgTmV0d29yayAoTDJWUE4pIG9yIExheWVyMyBWaXJ0dWFs IFByaXZhdGUgTmV0d29yayAoTDNWUE4pIHRyYWZmaWMNCj4gICAgYWNyb3NzIElQIG5ldHdvcmtz LiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhZGRpdGlvbmFsIElQLWJhc2VkDQo+ICAgIGVuY2Fw c3VsYXRpb24gdGVjaG5vbG9neSwgcmVmZXJyZWQgdG8gYXMgTVBMUy1pbi1Vc2VyIERhdGFncmFt DQo+ICAgIFByb3RvY29sIChVRFApLCB3aGljaCBjYW4gZmFjaWxpdGF0ZSB0aGUgbG9hZCBiYWxh bmNpbmcgb2YgTVBMUw0KPiAgICBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUCBuZXR3b3Jr cy4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From lucy.yong@huawei.com Thu Dec 6 07:20:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84321F8774 for ; Thu, 6 Dec 2012 07:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfY8AqXGjB3j for ; Thu, 6 Dec 2012 07:19:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2F221F876C for ; Thu, 6 Dec 2012 07:19:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF92596; Thu, 06 Dec 2012 15:19:57 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 15:19:23 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 15:19:56 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 07:19:50 -0800 From: Lucy yong To: Vivek Kumar , "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrwABCZGMAAF3cDYA== Date: Thu, 6 Dec 2012 15:19:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44860A0D@dfweml505-mbx> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.80.100] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44860A0Ddfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:20:01 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44860A0Ddfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vivek, Thank you for the clarification. I think that my answer to your first quest= ion applies to the point 2. In short, it can apply to LSR. But in the cont= ext of MPLS application, it means PE. Lucy From: Vivek Kumar [mailto:kvivek@broadcom.com] Sent: Wednesday, December 05, 2012 10:07 PM To: Lucy yong; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Thanks Lucy for your comments. For point 2 ) below I meant that since MPLS label could also have an entrop= y as one of their label , can the proposed approach of UDP encapsulation be= applied to LSR also or it will be restricted for PE only ? Regards, Vivek From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, December 06, 2012 1:52 AM To: Vivek Kumar; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Hi Vivek, I share my opinion. Please see below. From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Vivek Kum= ar Sent: Wednesday, December 05, 2012 5:19 AM To: mpls@ietf.org Subject: [mpls] Some question on draft-xu-mpls-in-udp-04 Hi Authors, I have some question. 1) The draft-xu-mpls-in-udp-04 main purpose seems to be for proving l= oad balancing in IP network for MPLS packets. Is that the only use case of= this new encapsulation method or there can be some more ? [Lucy] This draft proposes mpls-in-udp format to enable better load balanci= ng in IP network for MPLS payload. In fact, as section 4 states, the udp en= capsulation can apply other applications beside MPLS, for example, IP. Howe= ver, potential for other applications are outside scope of this draft. We p= lan to have another draft describe the udp encapsulation in general as ment= ioned in section 4. 2) The draft says that ingress PE router will calculate entropy and e= ncapsulate UDP header with src port containing entropy value . Does this me= an that only PE routers can do UDP encap since PE router can look deep insi= de the packet to calculate entropy ? What if LSR's want to initiate UDP tunnel ? [Lucy] Yes, the solution requires PE to support UDP and proposes to reserve= two UDP port number to indicate the payload type. PE understands the paylo= ad and can get some flow entropy from the payload and insert into UDP src p= ort. Could you elaborate what is the UDP tunnel? Lucy Kindly provide your comments . Regards, Vivek --_000_2691CE0099834E4A9C5044EEC662BB9D44860A0Ddfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vivek,

 

Thank you for the clar= ification. I think that my answer to your first question applies to the poi= nt 2.  In short, it can apply to LSR. But in the context of MPLS appli= cation, it means PE.

 

Lucy=

 

From: Vivek Ku= mar [mailto:kvivek@broadcom.com]
Sent: Wednesday, December 05, 2012 10:07 PM
To: Lucy yong; mpls@ietf.org
Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Thanks Lucy for your c= omments.

 

For point 2 ) below I = meant that since MPLS label could also have an entropy as one of their labe= l , can the proposed approach of UDP encapsulation be applied to LSR also o= r it will be restricted for PE only ?

 

Regards,

Vivek

 

 

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Thursday, December 06, 2012 1:52 AM
To: Vivek Kumar; mpls@ietf.org
Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vivek,

 

I share my opinion. Pl= ease see below.

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04<= /span>

 

Hi  Authors,

  

I have some question.

 

1)      The  draft-xu-mpls-in-udp-04 main purpose seem= s to be for proving load balancing in IP network for MPLS packets.  Is= that the only use case of this new encapsulation method or there can be so= me more ?

[Lucy] This draf= t proposes mpls-in-udp format to enable better load balancing in IP network= for MPLS payload. In fact, as section 4 states, the udp encapsulation can = apply other applications beside MPLS, for example, IP. However, potential for other applications are outside sco= pe of this draft. We plan to have another draft describe the udp encapsulat= ion in general as mentioned in section 4.

 

2)      The draft says that ingress PE router will calculat= e entropy and  encapsulate UDP header with src port containing entropy= value . Does this mean that only PE routers can do UDP encap since PE rout= er can look deep inside the packet to calculate entropy ?

        &nbs= p;       What if LSR’s want to initiate= UDP tunnel ?

[Lucy] Yes, the = solution requires PE to support UDP and proposes to reserve two UDP port nu= mber to indicate the payload type. PE understands the payload and can get s= ome flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP tunnel?=

 

Lucy<= /b>

 

Kindly provide your comments .

 

Regards,

Vivek

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44860A0Ddfweml505mbx_-- From Rolf.Winter@neclab.eu Thu Dec 6 08:51:56 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B671421F84FC for ; Thu, 6 Dec 2012 08:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOWufu2geuLn for ; Thu, 6 Dec 2012 08:51:54 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8E21F864D for ; Thu, 6 Dec 2012 08:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 245C81028B7; Thu, 6 Dec 2012 17:51:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq1ML9LR+31H; Thu, 6 Dec 2012 17:51:42 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id EB5D71028B6; Thu, 6 Dec 2012 17:51:31 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 17:50:39 +0100 From: Rolf Winter To: Gregory Mirsky , "mpls@ietf.org" Thread-Topic: working group last call on draft-ietf-mpls-tp-mip-mep-map Thread-Index: AQHNwnsJbqSTohVF1kGt9PyzoZIRlZgCOJAAgAT6CLCAAD1PAIAAL8Jw///5M4CAAMon4IAA8bMAgACmioCAAPMgAIABLing Date: Thu, 6 Dec 2012 16:50:39 +0000 Message-ID: <791AD3077F94194BB2BDD13565B6295D5554691F@DAPHNIS.office.hd> References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50B88D2A.30504@pi.nu> <791AD3077F94194BB2BDD13565B6295D555415BF@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E837@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D5554285D@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201E9F9@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D555429FE@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201F537@eusaamb103.ericsson.se> <791AD3077F94194BB2BDD13565B6295D55546019@DAPHNIS.office.hd> <7347100B5761DC41A166AC17F22DF11201FC2B@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11201FC2B@eusaamb103.ericsson.se> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.213] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:51:56 -0000 Hi Greg, I still do not see how the loopback example applies to per-interface MIP ad= dressing alone. There has to be a return path, full stop. Independent of _a= ny_ OAM constructs. I can answer the question you had, which was: "I've realized I'm not sure whether MPLS-TP OAM allows MIP on LER/T-PE node= s, i.e. where MEPs reside.". The OAM framework is quite explicit on this (at the end of section 3.4): "A node hosting a MEP can also support per-interface Up MEPs and per-interf= ace MIPs on either side of the forwarding engine." I think we should focus on the draft mentioned in the subject line instead = of questioning things that the MPLS-TP OAM framework explicitly allows. If = you like to continue that discussion (which is fine by me) we really should= change the subject line. Best, Rolf NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Donnerstag, 6. Dezember 2012 00:42 > To: Rolf Winter; mpls@ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Rolf, > please find my notes in-lined below and tagged by GIM>>. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > ] > Sent: Wednesday, December 05, 2012 12:23 AM > To: Gregory Mirsky; mpls@ietf.org > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep-map >=20 > Hi Greg, >=20 > see inline. >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 >=20 >=20 > > Hi Rolf, > > I'll think that per MEG MIPs, even though they are on the same LSP/PW, > > in MPLS-TP, IMHO, belong in fact to different MEG Levels, hence > > different SPMEs. If such interpretation is acceptable, then we can > > have multiple MIPs but only one MIP per MEG Level (even though no > such > > construct was introduced in MPLS-TP OAM model, unfortunately IMHO). >=20 > Again, I don't see why to force this, what this would actually gain, > why to introduce an artificial constraint and force people to manage > MEG levels as opposed to multiple MIPs per MEG. You can implement it > this way if you wish but I do not see a compelling argument why to > force it (and therefore disallow something that _all_ RFCs have allowed > to date). >=20 > GIM>> Yes, some architectural constrcts, paradigms have to be enforced. > Support of multiple MIPs on a given LSP/PW on particular LSR/(S-)PE > through use of SPME, IMHO, acceptable solution to the requirement. And > as I've been writing previous sentense I've realized I'm not sure > whether MPLS-TP OAM allows MIP on LER/T-PE nodes, i.e. where MEPs > reside. Ethernet OAM, AFAIK, makes such combination optional, but not a > requirement. >=20 > > And I think that distinction, if any, between in-, out- and nodal MIP > > should not be required for unidirectional MPLS-TP constructs as it is > > not practical since Loopback mode can not be exercised as there's no > > return path via data plane. Thus examples with p2mp scenarios are not > > applicable, IMHO, to this discussion. >=20 > A return path will be out of band, yes. But if you proclaim that if > there is no data plane return path and therefore in- and out- MIP > distinction is useless that doesn't compute at my end. I mean, if MIP > functionality is useful in any scenario, the distinction can help > operators to do a better OAM job (and I believe restricting the > discussion to loopback is not helpful here either). >=20 > GIM>> RFC 6435 states in Section 4.1 Operational Prerequisites: > Obviously, for the loopback function to operate, there are several > prerequisites: >=20 > - There must be a return path, so the transport path under test > must > be bidirectional. >=20 > I read it that out of band return path would not suffice the > abovementioned requirement to use MPLS-TP loopback. Perhaps another > packet transport can work, but not MPLS-TP. >=20 > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > > > > ] > > Sent: Tuesday, December 04, 2012 12:00 AM > > To: Gregory Mirsky; mpls@ietf.org > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > map > > > > Hi Greg, > > > > you might not be convinced but there are operators that have asked > for > > this functionality based on operational experience. > > > > Quoting the OAM framework RFC: > > > > " Once a MEG is configured, the operator can enable/disable the MIPs > on > > the nodes within the MEG. All the intermediate nodes and possibly > > the end nodes host MIP(s). Local policy allows them to be enabled > > per function and per MEG. The local policy is controlled by the > > management system, which may delegate it to the control plane. A > > disabled MIP silently discards any received OAM packets." > > > > Clearly having multiple MIPs per LSP is allowed as per the OAM > > framework. I think however the sentence "All the intermediate nodes > > and possibly the end nodes host MIP(s)" should really be ""All the > > intermediate nodes and possibly the end nodes can host MIP(s)" (Is > > this worth filing an errata?). I don't see why one wants to > > arbitrarily restrict the number of MIPs per LSP. BTW, as you mention, > > the support of multiple MIPs in Ethernet is optional. Quoting the OAM > > framework > > again: > > > > "Support of per-interface or per-node MIPs is an implementation > > choice." > > > > So where's the difference? > > > > Best, > > > > Rolf > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL | Registered in England 2832014 > > > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > > > > > > > > ] > > > Sent: Montag, 3. Dezember 2012 21:47 > > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Hi Rolf, > > > I've been thinking about that requirement for some time and am not > > > convinced that such requirement, support multiple MIP per LSP/PW on > > > given LSR/PE, exists. AFAIK, in Ethernet OAM only support of single > > > MIP per MD/MEG Level is required and support of multiple MIPs is > > optional. > > > True, multiple MIPs of different MD/MEG Levels might be enabled on > a > > > node but in MPLS-TP we use SPME to model MD/MEG Levels and thus > such > > > MIPs are on different LSPs. As for p2mp case, I'm not sure how dat- > > > plane loopback can be used on uni-directional construct. > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Rolf Winter [mailto:Rolf.Winter@neclab.eu > > > > > > > > > > > > ] > > > Sent: Monday, December 03, 2012 12:15 PM > > > To: Gregory Mirsky; Loa Andersson; mpls@ietf.org > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > ietf- > > > mpls-tp-mip-mep-map@tools.ietf.org > > > Subject: RE: working group last call on draft-ietf-mpls-tp-mip-mep- > > map > > > > > > Hi Greg, > > > > > > But that's the whole point of the document. There can be multiple > > > in- and out-MIPs per LSP plus in the P2MP case there can be > multiple > > > out- MIPs per node. It cannot be based local configuration. There > > > has to > > be > > > information inside the OAM frame to address the respective MIP. > > > Section > > > 4 of the document has a (I believe) pretty good example of this. > > > > > > Best, > > > > > > Rolf > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > > > London W3 6BL | Registered in England 2832014 > > > > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > ] > > > > Sent: Montag, 3. Dezember 2012 19:20 > > > > To: Rolf Winter; Loa Andersson; mpls@ietf.org > > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > > ietf- > > > > mpls-tp-mip-mep-map@tools.ietf.org > > > > Subject: RE: working group last call on > > > > draft-ietf-mpls-tp-mip-mep- > > > map > > > > > > > > Hi Rolf, > > > > Do you envision that multiple MIPs, both in- and out-, required > to > > be > > > > supported on a given LSP/PW? I think that only single MIP > > > required > > > > per LSP/PW on an LSR/PE node. If that is the case, then there > > > > might > > > be > > > > no apparent need to explicitly address in- and out- MIP as such > > > > distinction becomes part of local configuration. > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org > > > > > > > > > > > > > > > > ] On Behalf Of Rolf Winter > > > > Sent: Monday, December 03, 2012 5:42 AM > > > > To: Loa Andersson; mpls@ietf.org > > > > Cc: mpls-ads@tools.ietf.org; mpls-chairs@tools.ietf.org; draft- > > ietf- > > > > mpls-tp-mip-mep-map@tools.ietf.org > > > > Subject: Re: [mpls] working group last call on draft-ietf-mpls- > tp- > > > mip- > > > > mep-map > > > > > > > > Loa, > > > > > > > > These have been mentioned: > > > > > > > > 1. CV between a MEP and a MIP > > > > 2. traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing > > > MIPs > > > > 3. data-plane loopback configuration at a MIP 4. diagnostic tests > > > > > > > > Best, > > > > > > > > Rolf > > > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > > > > > > -----Original Message----- > > > > > From: Loa Andersson [mailto:loa@pi.nu > > > > > > > > > > > > ] > > > > > Sent: Freitag, 30. November 2012 11:41 > > > > > To: mpls@ietf.org > > > > > Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux; > > > > > draft-ietf-mpls-tp- mip-mep-map@tools.ietf.org; > > > > > mpls-ads@tools.ietf.org > > > > > Subject: Re: working group last call on > > > > > draft-ietf-mpls-tp-mip-mep- > > > > map > > > > > > > > > > Authors, > > > > > > > > > > Can you plese give me an indication of which OAM functions the > > > > > separation of in and out MIPs are intended for? > > > > > > > > > > /Loa > > > > > > > > > > > > > > > > > > > > On 2012-11-14 16:16, Loa Andersson wrote: > > > > > > > > > > > > Working Group, > > > > > > > > > > > > This is to start a 2 week working group last call on > > > > > > draft-ietf-mpls-tp-mip-mep-map. > > > > > > > > > > > > Please send your comments to the mpls working group mailing > > list > > > > > > (mpls@ietf.org). > > > > > > > > > > > > Please send both technical comments, and if you are happy > with > > > the > > > > > > document as is also indications of support. > > > > > > > > > > > > This working group last call will end on November 28. > > > > > > > > > > > > /Loa > > > > > > for the wg co-chairs > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > Loa Andersson email: > > > > loa.andersson@ericsson.com > > > > > Sr Strategy and Standards Manager loa@pi.nu > > > > > Ericsson Inc phone: +46 10 717 52 13 > > > > > +46 767 72 92 13 > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 From internet-drafts@ietf.org Thu Dec 6 12:11:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B261F0C59; Thu, 6 Dec 2012 12:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro2sV9YrjyrO; Thu, 6 Dec 2012 12:11:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0200321F86C6; Thu, 6 Dec 2012 12:11:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206201105.17450.51370.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 12:11:05 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-gach-adv-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 20:11:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS Generic Associated Channel (G-ACh) Advertisement Pr= otocol Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-gach-adv-04.txt Pages : 19 Date : 2012-12-06 Abstract: The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-gach-adv-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Dec 6 12:13:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA05711E80A2; Thu, 6 Dec 2012 12:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s85BhPkQqFsx; Thu, 6 Dec 2012 12:13:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323EB11E8097; Thu, 6 Dec 2012 12:13:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206201348.4418.25638.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 12:13:48 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ethernet-addressing-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 20:13:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Next-Hop Ethernet Addressing Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-tp-ethernet-addressing-03.txt Pages : 7 Date : 2012-12-06 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ethernet-addressing-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ethernet-addressing-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Dec 6 12:38:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9253E21F893E; Thu, 6 Dec 2012 12:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU94LGmSvope; Thu, 6 Dec 2012 12:38:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04121F88D9; Thu, 6 Dec 2012 12:38:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206203815.30385.84133.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 12:38:15 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ethernet-addressing-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 20:38:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Next-Hop Ethernet Addressing Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-tp-ethernet-addressing-04.txt Pages : 7 Date : 2012-12-06 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ethernet-addressing-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ethernet-addressing-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kvivek@broadcom.com Thu Dec 6 20:04:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B321F8812 for ; Thu, 6 Dec 2012 20:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HD-EnADoj73 for ; Thu, 6 Dec 2012 20:04:23 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4821F87DC for ; Thu, 6 Dec 2012 20:04:23 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 06 Dec 2012 20:02:16 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 6 Dec 2012 20:04:12 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 6 Dec 2012 20:04:11 -0800 From: "Vivek Kumar" To: "Lucy yong" , "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrwABCZGMAAF3cDYAAaqS0g Date: Fri, 7 Dec 2012 04:04:11 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44860A0D@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44860A0D@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CDFB5C21QK16683316-01-01 Content-Type: multipart/alternative; boundary=_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56SJEXCHMB09corpa_ Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 04:04:26 -0000 --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56SJEXCHMB09corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Lucy, Thanks for clarification. In Section 3 of draft, the figure says MPLS Pa= cket. Wouldn't it be more consistent to change it to MPLS label stack same = as mentioned in RFC 4023. Regards, Vivek From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, December 06, 2012 8:50 PM To: Vivek Kumar; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Hi Vivek, Thank you for the clarification. I think that my answer to your first quest= ion applies to the point 2. In short, it can apply to LSR. But in the cont= ext of MPLS application, it means PE. Lucy From: Vivek Kumar [mailto:kvivek@broadcom.com] Sent: Wednesday, December 05, 2012 10:07 PM To: Lucy yong; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Thanks Lucy for your comments. For point 2 ) below I meant that since MPLS label could also have an entrop= y as one of their label , can the proposed approach of UDP encapsulation be= applied to LSR also or it will be restricted for PE only ? Regards, Vivek From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Thursday, December 06, 2012 1:52 AM To: Vivek Kumar; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04 Hi Vivek, I share my opinion. Please see below. From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Vivek Kum= ar Sent: Wednesday, December 05, 2012 5:19 AM To: mpls@ietf.org Subject: [mpls] Some question on draft-xu-mpls-in-udp-04 Hi Authors, I have some question. 1) The draft-xu-mpls-in-udp-04 main purpose seems to be for proving l= oad balancing in IP network for MPLS packets. Is that the only use case of= this new encapsulation method or there can be some more ? [Lucy] This draft proposes mpls-in-udp format to enable better load balanci= ng in IP network for MPLS payload. In fact, as section 4 states, the udp en= capsulation can apply other applications beside MPLS, for example, IP. Howe= ver, potential for other applications are outside scope of this draft. We p= lan to have another draft describe the udp encapsulation in general as ment= ioned in section 4. 2) The draft says that ingress PE router will calculate entropy and e= ncapsulate UDP header with src port containing entropy value . Does this me= an that only PE routers can do UDP encap since PE router can look deep insi= de the packet to calculate entropy ? What if LSR's want to initiate UDP tunnel ? [Lucy] Yes, the solution requires PE to support UDP and proposes to reserve= two UDP port number to indicate the payload type. PE understands the paylo= ad and can get some flow entropy from the payload and insert into UDP src p= ort. Could you elaborate what is the UDP tunnel? Lucy Kindly provide your comments . Regards, Vivek --_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56SJEXCHMB09corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Lucy,

  Thanks for clar= ification.  In Section 3 of draft, the figure says MPLS Packet. Wouldn= ’t it be more consistent to change it to MPLS label stack same as men= tioned in RFC 4023.

 

Regards,

Vivek

 

From: Lucy yon= g [mailto:lucy.yong@huawei.com]
Sent: Thursday, December 06, 2012 8:50 PM
To: Vivek Kumar; mpls@ietf.org
Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vivek,

 

Thank you for the clar= ification. I think that my answer to your first question applies to the poi= nt 2.  In short, it can apply to LSR. But in the context of MPLS appli= cation, it means PE.

 

Lucy=

 

From: Vivek Ku= mar [mailto:kvivek@broadcom.com= ]
Sent: Wednesday, December 05, 2012 10:07 PM
To: Lucy yong; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Thanks Lucy for your c= omments.

 

For point 2 ) below I = meant that since MPLS label could also have an entropy as one of their labe= l , can the proposed approach of UDP encapsulation be applied to LSR also o= r it will be restricted for PE only ?

 

Regards,

Vivek

 

 

From: Lucy yon= g [mailto:lucy.yong@huawei.c= om]
Sent: Thursday, December 06, 2012 1:52 AM
To: Vivek Kumar; mpls@ietf.org<= br> Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vivek,

 

I share my opinion. Pl= ease see below.

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04<= /span>

 

Hi  Authors,

  

I have some question.

 

1)      The  draft-xu-mpls-in-udp-04 main purpose seem= s to be for proving load balancing in IP network for MPLS packets.  Is= that the only use case of this new encapsulation method or there can be so= me more ?

[Lucy] This draf= t proposes mpls-in-udp format to enable better load balancing in IP network= for MPLS payload. In fact, as section 4 states, the udp encapsulation can = apply other applications beside MPLS, for example, IP. However, potential for other applications are outside sco= pe of this draft. We plan to have another draft describe the udp encapsulat= ion in general as mentioned in section 4.

 

2)      The draft says that ingress PE router will calculat= e entropy and  encapsulate UDP header with src port containing entropy= value . Does this mean that only PE routers can do UDP encap since PE rout= er can look deep inside the packet to calculate entropy ?

        &nbs= p;       What if LSR’s want to initiate= UDP tunnel ?

[Lucy] Yes, the = solution requires PE to support UDP and proposes to reserve two UDP port nu= mber to indicate the payload type. PE understands the payload and can get s= ome flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP tunnel?=

 

Lucy<= /b>

 

Kindly provide your comments .

 

Regards,

Vivek

 

 

--_000_3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56SJEXCHMB09corpa_-- From xuxiaohu@huawei.com Thu Dec 6 20:11:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFAB21F8568 for ; Thu, 6 Dec 2012 20:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lhc3qDeDMgt for ; Thu, 6 Dec 2012 20:11:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7591D21F84F8 for ; Thu, 6 Dec 2012 20:11:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANO37800; Fri, 07 Dec 2012 04:11:34 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 04:10:58 +0000 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Dec 2012 04:11:32 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 12:11:21 +0800 From: Xuxiaohu To: Vivek Kumar , Lucy yong , "mpls@ietf.org" Thread-Topic: Some question on draft-xu-mpls-in-udp-04 Thread-Index: Ac3S1507YmMa8ZhiTWyW+WmBhYITPAATKWrwABCZGMAAF3cDYAAaqS0gAABe3dA= Date: Fri, 7 Dec 2012 04:11:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587132@szxeml525-mbs.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA97FF@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D4485F82C@dfweml505-mbx> <3C086BA39C55B9418AE8FEA3F3EFDEC41DEA99C7@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D44860A0D@dfweml505-mbx> <3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEAAD56@SJEXCHMB09.corp.ad.broadcom.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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587132szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Some question on draft-xu-mpls-in-udp-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 04:11:37 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587132szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2lsbCBmaXggaXQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KVGhhbmtzLg0KWGlhb2h1DQoNCrei vP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIFZpdmVrIEt1bWFyDQq3osvNyrG85DogMjAxMsTqMTLUwjfI1SAxMjowNA0KytW8/sjL OiBMdWN5IHlvbmc7IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbXBsc10gU29tZSBxdWVzdGlv biBvbiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNA0KDQpIaSBMdWN5LA0KICBUaGFua3MgZm9yIGNs YXJpZmljYXRpb24uICBJbiBTZWN0aW9uIDMgb2YgZHJhZnQsIHRoZSBmaWd1cmUgc2F5cyBNUExT IFBhY2tldC4gV291bGRuoa90IGl0IGJlIG1vcmUgY29uc2lzdGVudCB0byBjaGFuZ2UgaXQgdG8g TVBMUyBsYWJlbCBzdGFjayBzYW1lIGFzIG1lbnRpb25lZCBpbiBSRkMgNDAyMy4NCg0KUmVnYXJk cywNClZpdmVrDQoNCkZyb206IEx1Y3kgeW9uZyBbbWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29t XQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA2LCAyMDEyIDg6NTAgUE0NClRvOiBWaXZlayBL dW1hcjsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFNvbWUgcXVlc3Rpb24gb24gZHJhZnQt eHUtbXBscy1pbi11ZHAtMDQNCg0KSGkgVml2ZWssDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXJp ZmljYXRpb24uIEkgdGhpbmsgdGhhdCBteSBhbnN3ZXIgdG8geW91ciBmaXJzdCBxdWVzdGlvbiBh cHBsaWVzIHRvIHRoZSBwb2ludCAyLiAgSW4gc2hvcnQsIGl0IGNhbiBhcHBseSB0byBMU1IuIEJ1 dCBpbiB0aGUgY29udGV4dCBvZiBNUExTIGFwcGxpY2F0aW9uLCBpdCBtZWFucyBQRS4NCg0KTHVj eQ0KDQpGcm9tOiBWaXZlayBLdW1hciBbbWFpbHRvOmt2aXZla0Bicm9hZGNvbS5jb21dPG1haWx0 bzpbbWFpbHRvOmt2aXZla0Bicm9hZGNvbS5jb21dPg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJl ciAwNSwgMjAxMiAxMDowNyBQTQ0KVG86IEx1Y3kgeW9uZzsgbXBsc0BpZXRmLm9yZzxtYWlsdG86 bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBTb21lIHF1ZXN0aW9uIG9uIGRyYWZ0LXh1LW1w bHMtaW4tdWRwLTA0DQoNClRoYW5rcyBMdWN5IGZvciB5b3VyIGNvbW1lbnRzLg0KDQpGb3IgcG9p bnQgMiApIGJlbG93IEkgbWVhbnQgdGhhdCBzaW5jZSBNUExTIGxhYmVsIGNvdWxkIGFsc28gaGF2 ZSBhbiBlbnRyb3B5IGFzIG9uZSBvZiB0aGVpciBsYWJlbCAsIGNhbiB0aGUgcHJvcG9zZWQgYXBw cm9hY2ggb2YgVURQIGVuY2Fwc3VsYXRpb24gYmUgYXBwbGllZCB0byBMU1IgYWxzbyBvciBpdCB3 aWxsIGJlIHJlc3RyaWN0ZWQgZm9yIFBFIG9ubHkgPw0KDQpSZWdhcmRzLA0KVml2ZWsNCg0KDQpG cm9tOiBMdWN5IHlvbmcgW21haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbV08bWFpbHRvOlttYWls dG86bHVjeS55b25nQGh1YXdlaS5jb21dPg0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA2LCAy MDEyIDE6NTIgQU0NClRvOiBWaXZlayBLdW1hcjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBTb21lIHF1ZXN0aW9uIG9uIGRyYWZ0LXh1LW1wbHMtaW4t dWRwLTA0DQoNCkhpIFZpdmVrLA0KDQpJIHNoYXJlIG15IG9waW5pb24uIFBsZWFzZSBzZWUgYmVs b3cuDQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIFZpdmVrIEt1bWFyDQpTZW50OiBXZWRu ZXNkYXksIERlY2VtYmVyIDA1LCAyMDEyIDU6MTkgQU0NClRvOiBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDogW21wbHNdIFNvbWUgcXVlc3Rpb24gb24gZHJhZnQt eHUtbXBscy1pbi11ZHAtMDQNCg0KSGkgIEF1dGhvcnMsDQoNCkkgaGF2ZSBzb21lIHF1ZXN0aW9u Lg0KDQoNCjEpICAgICAgVGhlICBkcmFmdC14dS1tcGxzLWluLXVkcC0wNCBtYWluIHB1cnBvc2Ug c2VlbXMgdG8gYmUgZm9yIHByb3ZpbmcgbG9hZCBiYWxhbmNpbmcgaW4gSVAgbmV0d29yayBmb3Ig TVBMUyBwYWNrZXRzLiAgSXMgdGhhdCB0aGUgb25seSB1c2UgY2FzZSBvZiB0aGlzIG5ldyBlbmNh cHN1bGF0aW9uIG1ldGhvZCBvciB0aGVyZSBjYW4gYmUgc29tZSBtb3JlID8NCltMdWN5XSBUaGlz IGRyYWZ0IHByb3Bvc2VzIG1wbHMtaW4tdWRwIGZvcm1hdCB0byBlbmFibGUgYmV0dGVyIGxvYWQg YmFsYW5jaW5nIGluIElQIG5ldHdvcmsgZm9yIE1QTFMgcGF5bG9hZC4gSW4gZmFjdCwgYXMgc2Vj dGlvbiA0IHN0YXRlcywgdGhlIHVkcCBlbmNhcHN1bGF0aW9uIGNhbiBhcHBseSBvdGhlciBhcHBs aWNhdGlvbnMgYmVzaWRlIE1QTFMsIGZvciBleGFtcGxlLCBJUC4gSG93ZXZlciwgcG90ZW50aWFs IGZvciBvdGhlciBhcHBsaWNhdGlvbnMgYXJlIG91dHNpZGUgc2NvcGUgb2YgdGhpcyBkcmFmdC4g V2UgcGxhbiB0byBoYXZlIGFub3RoZXIgZHJhZnQgZGVzY3JpYmUgdGhlIHVkcCBlbmNhcHN1bGF0 aW9uIGluIGdlbmVyYWwgYXMgbWVudGlvbmVkIGluIHNlY3Rpb24gNC4NCg0KDQoyKSAgICAgIFRo ZSBkcmFmdCBzYXlzIHRoYXQgaW5ncmVzcyBQRSByb3V0ZXIgd2lsbCBjYWxjdWxhdGUgZW50cm9w eSBhbmQgIGVuY2Fwc3VsYXRlIFVEUCBoZWFkZXIgd2l0aCBzcmMgcG9ydCBjb250YWluaW5nIGVu dHJvcHkgdmFsdWUgLiBEb2VzIHRoaXMgbWVhbiB0aGF0IG9ubHkgUEUgcm91dGVycyBjYW4gZG8g VURQIGVuY2FwIHNpbmNlIFBFIHJvdXRlciBjYW4gbG9vayBkZWVwIGluc2lkZSB0aGUgcGFja2V0 IHRvIGNhbGN1bGF0ZSBlbnRyb3B5ID8NCiAgICAgICAgICAgICAgICBXaGF0IGlmIExTUqGvcyB3 YW50IHRvIGluaXRpYXRlIFVEUCB0dW5uZWwgPw0KW0x1Y3ldIFllcywgdGhlIHNvbHV0aW9uIHJl cXVpcmVzIFBFIHRvIHN1cHBvcnQgVURQIGFuZCBwcm9wb3NlcyB0byByZXNlcnZlIHR3byBVRFAg cG9ydCBudW1iZXIgdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgdHlwZS4gUEUgdW5kZXJzdGFuZHMg dGhlIHBheWxvYWQgYW5kIGNhbiBnZXQgc29tZSBmbG93IGVudHJvcHkgZnJvbSB0aGUgcGF5bG9h ZCBhbmQgaW5zZXJ0IGludG8gVURQIHNyYyBwb3J0LiBDb3VsZCB5b3UgZWxhYm9yYXRlIHdoYXQg aXMgdGhlIFVEUCB0dW5uZWw/DQoNCkx1Y3kNCg0KS2luZGx5IHByb3ZpZGUgeW91ciBjb21tZW50 cyAuDQoNClJlZ2FyZHMsDQpWaXZlaw0KDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587132szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Will fix it in the next version.

 

Thanks.

Xiaohu

 

=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Vivek Kumar
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA12=D4=C2= 7=C8=D5 12:04
=CA=D5=BC=FE=C8=CB: Lucy yong; mpls@ietf.org
=D6=F7=CC=E2: Re: [mpls] Some question on draft-xu-mpls-in-udp-04

 

Hi Lucy= ,

  = Thanks for clarification.  In Section 3 of draft, the figure says MPLS= Packet. Wouldn=A1=AFt it be more consistent to change it to MPLS label sta= ck same as mentioned in RFC 4023.

&n= bsp;

Regards= ,

Vivek

&n= bsp;

From: Lucy yong [mailto:lucy.yong@huawei.com]
Sent: Thursday, December 06, 2012 8:50 PM
To: Vivek Kumar; mpls@ietf.org
Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vive= k,

&n= bsp;

Thank y= ou for the clarification. I think that my answer to your first question app= lies to the point 2.  In short, it can apply to LSR. But in the contex= t of MPLS application, it means PE.

&n= bsp;

Lucy

&n= bsp;

From: Vivek Kumar [mailto:kvivek@broadcom.com= ]
Sent: Wednesday, December 05, 2012 10:07 PM
To: Lucy yong; mpls@ietf.org Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Thanks = Lucy for your comments.

&n= bsp;

For poi= nt 2 ) below I meant that since MPLS label could also have an entropy as on= e of their label , can the proposed approach of UDP encapsulation be applie= d to LSR also or it will be restricted for PE only ?

&n= bsp;

Regards= ,

Vivek

&n= bsp;

&n= bsp;

From: Lucy yong [mailto:lucy.yong@huawei.c= om]
Sent: Thursday, December 06, 2012 1:52 AM
To: Vivek Kumar; mpls@ietf.org<= br> Subject: RE: Some question on draft-xu-mpls-in-udp-04

 

Hi Vive= k,

&n= bsp;

I share= my opinion. Please see below.

&n= bsp;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Vivek Kumar
Sent: Wednesday, December 05, 2012 5:19 AM
To: mpls@ietf.org
Subject: [mpls] Some question on draft-xu-mpls-in-udp-04<= /span>

 

Hi  Authors,

   =

I have some question.

 

1) &nbs= p;    The  draft-xu-mpls= -in-udp-04 main purpose seems to be for proving load balancing in IP networ= k for MPLS packets.  Is that the only use case of this new encapsulati= on method or there can be some more ?

[= Lucy] This draft proposes mpls-in-udp format to enable better load balancin= g in IP network for MPLS payload. In fact, as section 4 states, the udp enc= apsulation can apply other applications beside MPLS, for example, IP. However, potential for other applications ar= e outside scope of this draft. We plan to have another draft describe the u= dp encapsulation in general as mentioned in section 4.

 

2) &nbs= p;    The draft says that ing= ress PE router will calculate entropy and  encapsulate UDP header with= src port containing entropy value . Does this mean that only PE routers ca= n do UDP encap since PE router can look deep inside the packet to calculate entropy ?

     &= nbsp;          What if LSR=A1= =AFs want to initiate UDP tunnel ?

[= Lucy] Yes, the solution requires PE to support UDP and proposes to reserve = two UDP port number to indicate the payload type. PE understands the payloa= d and can get some flow entropy from the payload and insert into UDP src port. Could you elaborate what is the UDP = tunnel?

<= o:p> 

L= ucy<= /span>

 

Kindly provide your comments .<= o:p>

 

Regards,

Vivek

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587132szxeml525mbschi_-- From cpignata@cisco.com Fri Dec 7 06:53:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2021F8A9C for ; Fri, 7 Dec 2012 06:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk3HautQMLSH for ; Fri, 7 Dec 2012 06:53:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7494D21F8A94 for ; Fri, 7 Dec 2012 06:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1354892038; x=1356101638; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eaXvzOYsDb8IH9sN+tvIsLoCmxsuifDJ6TQSGpN/srk=; b=jndqbJDAKj1dcL59zGs8IFu9LnnbXC5ffW06ROM2wXA36owaWode12jk stHMuGB58EMaY7MDf9d6mDKCDJ4/4HOXQNLomK39k65mv0SW1QtSdtVlv 8ykoT+60D+gs1Sull50v5oMh5sTDLfABfGM8e7RJCbCjEFerVt4yHZfk5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKgCwlCtJXG9/2dsb2JhbABEvjYWc4IeAQEBAwEBAQE3NAYFBQkCAgEIIhQQGwwLJQIEDgUIiAMGDMI5BASMOwsQg0dhA6ZNgnOBbTU X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150493586" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 07 Dec 2012 14:53:57 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB7Erv4x026349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 14:53:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 08:53:57 -0600 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] IPR poll on draft-xu-mpls-in-udp Thread-Index: AQHNzNkbUv/5gCBx/EWZkQOnUeNRHZgN4D8A Date: Fri, 7 Dec 2012 14:53:56 +0000 Message-ID: <95067C434CE250468B77282634C96ED32276499B@xmb-aln-x02.cisco.com> References: <50B51A8A.5050108@pi.nu> In-Reply-To: <50B51A8A.5050108@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-xu-mpls-in-udp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:53:59 -0000 Loa, WG, I am aware of IPR that might be related to the subject matter in draft-xu-m= pls-in-udp. I have signaled Cisco legal and an IPR Disclosure should be for= thcoming. Best, -- Carlos. On Nov 27, 2012, at 2:54 PM, Loa Andersson wrote: > Working Group and authors; >=20 > The authors of draft-xu-mpls-in-udp has indicated that the draft is > ready to be adopted as a working group document. >=20 > Before starting the poll to see if there is wg consensus to make the > draft a working group document we will do an IPR poll to check whether > there is IPR on the document that needs to be disclosed. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-xu-mpls-in-udp? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The doc= uments will not advance to the next stage until a response > has been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From jsw@inconcepts.biz Sat Dec 8 22:59:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510821F85B2 for ; Sat, 8 Dec 2012 22:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptr2BPQt-llQ for ; Sat, 8 Dec 2012 22:59:05 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97E21F8532 for ; Sat, 8 Dec 2012 22:59:04 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id c10so5579186ieb.11 for ; Sat, 08 Dec 2012 22:59:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ntX63pLlt0HPwNskf8uTwzVFIKy2bVM0zaY72i+qOQE=; b=VivKZcac0DNYbe/qEJByy+bWRWanPoymDynT1U89eCo2AqDfq8jcxOjJQt90JxSyQ7 tPYMUTWt64Srqq1THFTFttxro1TAYNZDaIKnWNhgeJ9y9OIbNE0RZLYn/JBGocOw8y3/ Ne0i0bKKR95t5l/GpM3u8vvsbnRZdBS45tuoRtD64CCzuO3Z4PaqeGmg+ViQVTtRwbwc Eycz8CVd5RnXdvv3y+y1JROsyrvM0NKRqzSR7L7WyD60g1+bKz37Z6Sk2ecalL/n5TdE 7WUIUfYcEobpHvsW7GNhNIiz7PsOfGq6f1enpkQMFgp/qLeO1eFgSM/bmlYdpV6W1zNN gl0Q== MIME-Version: 1.0 Received: by 10.50.33.173 with SMTP id s13mr3432771igi.23.1355036344411; Sat, 08 Dec 2012 22:59:04 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sat, 8 Dec 2012 22:59:04 -0800 (PST) X-Originating-IP: [74.134.22.105] Date: Sun, 9 Dec 2012 01:59:04 -0500 Message-ID: From: Jeff Wheeler To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkAYsb5TybgurkYh4Qj13sYd5mQVugLzxAzZNMh40JIWpwFIBn0kqjYU5jI96ej2RsL3kwU Subject: [mpls] RFC5036 (LDP) S3.5.3/Pg56, Path Vector Limit in initialization parameters X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 06:59:05 -0000 Upon closely reading RFC5036 (LDP) section 3.5.3's description of the Path Vector Limit communicated in the initialization parameters, I had some initial confusion. Perhaps that's just me, or perhaps the language could be a little more clear. Specifically, it says, "Although knowledge of a peer's Path Vector limit will not change an LSR's behavior, it does enable the LSR to alert an operator to a possible misconfiguration." My understanding is that, if an LSRu is attached to the LDP domain with loop detection and it receives Mappings with excessive path vector length, it would interpret such Mappings as loops, and cause them to be Released. Because 3.5.3 allows LSRd to detect this certainty before sending a Mapping to LSRu, it is saved the effort of transmitting Mappings that are certain to result in Releases. The text, "will not change an LSR's behavior," was the cause of my initial confusion. Although the LDP domain as a whole will react in a similarly poor way if LSRu is attached and his PVLim is too small, the behavior of LSRd is not exactly identical. My understanding would have been better if the sentence read, "Knowledge of a peer's Path Vector Limit allows the LSR to alert an operator to a possible misconfiguration, such as a peer with a PVLim that is too small for the LDP domain." I believe those first few words are incorrect and confusing. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From wwwrun@rfc-editor.org Sat Dec 8 23:09:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4275E21F8BE5 for ; Sat, 8 Dec 2012 23:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L+zUOwX5v-h for ; Sat, 8 Dec 2012 23:09:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BA35121F8BE1 for ; Sat, 8 Dec 2012 23:09:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AB60A72E0D9; Sat, 8 Dec 2012 23:01:14 -0800 (PST) To: loa@pi.se, ina@juniper.net, rhthomas@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20121209070114.AB60A72E0D9@rfc-editor.org> Date: Sat, 8 Dec 2012 23:01:14 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC5036 (3425) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 07:09:44 -0000 The following errata report has been submitted for RFC5036, "LDP Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5036&eid=3425 -------------------------------------- Type: Editorial Reported by: Jeff Wheeler Section: 3.5 Original Text ------------- The specification assigns type values for related messages, such as the Label messages, from of a contiguous block in the 16-bit message type number space. Corrected Text -------------- The specification assigns type values for related messages, such as the Label messages, from a contiguous block in the 16-bit message type number space. Notes ----- "from of a contiguous block" changed to "from a contiguous block" Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5036 (draft-ietf-mpls-rfc3036bis-04) -------------------------------------- Title : LDP Specification Publication Date : October 2007 Author(s) : L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed. Category : DRAFT STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From xuxiaohu@huawei.com Mon Dec 10 01:43:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5534621F8DD2 for ; Mon, 10 Dec 2012 01:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=1.791, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAhShgIRcrio for ; Mon, 10 Dec 2012 01:43:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B621F883A for ; Mon, 10 Dec 2012 01:43:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMI49496; Mon, 10 Dec 2012 09:43:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Dec 2012 09:42:33 +0000 Received: from SZXEML446-HUB.china.huawei.com (10.82.67.184) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Dec 2012 09:43:17 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml446-hub.china.huawei.com ([10.82.67.184]) with mapi id 14.01.0323.003; Mon, 10 Dec 2012 17:42:45 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-in-udp-06.txt Thread-Index: AQHN1rjFzV+bnMkXd0K77ZG4Qrs2e5gRxgpg Date: Mon, 10 Dec 2012 09:42:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07587778@szxeml525-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.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:43:23 -0000 SGkgYWxsLA0KDQpBbiB1cGRhdGVkIHZlcnNpb24gaGFzIGJlZW4gc3VibWl0dGVkLiBUaGlzIHJl dmlzaW9uIGluY29ycG9yYXRlcyB0aGUgZm9sbG93aW5nIHN1Z2dlc3Rpb24gZnJvbSBWaXZlay4N Cg0KKioqKioqKioqKioqKioqKioqKioqKioNCj4gPiBIaSBMdWN5LA0KPiA+ICAgIFRoYW5rcyBm b3IgY2xhcmlmaWNhdGlvbi4gIEluIFNlY3Rpb24gMyBvZiBkcmFmdCwgdGhlIGZpZ3VyZSBzYXlz IA0KPiA+IE1QTFMNCj4gUGFja2V0LiBXb3VsZG7igJl0IGl0IGJlIG1vcmUgY29uc2lzdGVudCB0 byBjaGFuZ2UgaXQgdG8gTVBMUyBsYWJlbCANCj4gc3RhY2sgc2FtZSBhcyBtZW50aW9uZWQgaW4g UkZDIDQwMjMuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFZpdmVrDQoqKioqKioqKioqKioqKioq KioqKioqKioqDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDEy5pyIMTDml6Ug MTc6MjkNCj4g5pS25Lu25Lq6OiBYdXhpYW9odQ0KPiDmioTpgIE6IGNwaWduYXRhQGNpc2NvLmNv bTsgZmFueWJAZ3N0YS5jb207IG5zaGV0aEBjb250cmFpbHN5c3RlbXMuY29tOw0KPiBMdWN5IHlv bmcNCj4g5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LW1wbHMt aW4tdWRwLTA2LnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1t cGxzLWluLXVkcC0wNi50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBY aWFvaHUgWHUgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmls ZW5hbWU6CSBkcmFmdC14dS1tcGxzLWluLXVkcA0KPiBSZXZpc2lvbjoJIDA2DQo+IFRpdGxlOgkJ IEVuY2Fwc3VsYXRpbmcgTVBMUyBpbiBVRFANCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTItMTItMTAN Cj4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogOQ0K PiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LW1w bHMtaW4tdWRwLTA2LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQteHUtbXBscy1pbi11ZHANCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1tcGxzLWluLXVkcC0wNg0KPiBEaWZmOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXh1LW1wbHMt aW4tdWRwLTA2DQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgRXhpc3RpbmcgdGVjaG5vbG9naWVzIHRv IGVuY2Fwc3VsYXRlIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPiAgICAoTVBMUykg b3ZlciBJUCBhcmUgbm90IGFkZXF1YXRlIGZvciBlZmZpY2llbnQgbG9hZCBiYWxhbmNpbmcgb2Yg TVBMUw0KPiAgICBhcHBsaWNhdGlvbiB0cmFmZmljLCBzdWNoIGFzIE1QTFMtYmFzZWQgTGF5ZXIy IFZpcnR1YWwgUHJpdmF0ZQ0KPiAgICBOZXR3b3JrIChMMlZQTikgb3IgTGF5ZXIzIFZpcnR1YWwg UHJpdmF0ZSBOZXR3b3JrIChMM1ZQTikgdHJhZmZpYw0KPiAgICBhY3Jvc3MgSVAgbmV0d29ya3Mu IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGFkZGl0aW9uYWwgSVAtYmFzZWQNCj4gICAgZW5jYXBz dWxhdGlvbiB0ZWNobm9sb2d5LCByZWZlcnJlZCB0byBhcyBNUExTLWluLVVzZXIgRGF0YWdyYW0N Cj4gICAgUHJvdG9jb2wgKFVEUCksIHdoaWNoIGNhbiBmYWNpbGl0YXRlIHRoZSBsb2FkIGJhbGFu Y2luZyBvZiBNUExTDQo+ICAgIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQIG5ldHdvcmtz Lg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From loa@pi.nu Mon Dec 10 02:10:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8690621F8E53 for ; Mon, 10 Dec 2012 02:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdsCxuClUzWY for ; Mon, 10 Dec 2012 02:10:32 -0800 (PST) Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id AC60B21F8E4F for ; Mon, 10 Dec 2012 02:10:32 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id BF52982350; Mon, 10 Dec 2012 11:10:25 +0100 (CET) Message-ID: <50C5B513.7010002@pi.nu> Date: Mon, 10 Dec 2012 11:10:27 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-gach-adv@tools.ietf.org" Subject: [mpls] Implementations of draft-ietf-mpls-gach-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 10:10:33 -0000 Working Group, the working group chairs are preparing the publication request and the shepherd write-up for draft-ietf-mpls-gach-adv. One thing that the IESG sk about in the shepherd write-up is existing or intended implementations of the draft. If you have an implementation of draft-ietf-mpls-gach-adv or intend to implement please let the working group chair know this. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Wed Dec 12 03:54:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D959A21F88BF for ; Wed, 12 Dec 2012 03:54:49 -0800 (PST) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/vnd.openxmlformats-officedocument.wordprocessingml.document, .zip, liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g8131y1382-revision-linear-protection-switching-for-mpls-tp-networks-attachment-1.docx | .dat,word/media/image5.emf X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZW-nguuV5bK for ; Wed, 12 Dec 2012 03:54:49 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1355313289-8043-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 326C221F88BC for ; Wed, 12 Dec 2012 03:54:48 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 51FF98244D; Wed, 12 Dec 2012 12:54:36 +0100 (CET) Message-ID: <50C8707D.8060800@pi.nu> Date: Wed, 12 Dec 2012 12:54:37 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls-ads@tools.ietf.org" , Scott Mansfield , Martin Vigoureux References: In-Reply-To: Subject: [mpls] Linear Protection draft liaison response X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 11:54:50 -0000 This is a multi-part message in MIME format... ------------=_1355313289-8043-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1355313289-8043-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 326C221F88BC for ; Wed, 12 Dec 2012 03:54:48 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 51FF98244D; Wed, 12 Dec 2012 12:54:36 +0100 (CET) Message-ID: <50C8707D.8060800@pi.nu> Date: Wed, 12 Dec 2012 12:54:37 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls-ads@tools.ietf.org" , Scott Mansfield , Martin Vigoureux Subject: Linear Protection draft liaison response References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------000400090309090501010504" This is a multi-part message in MIME format. --------------000400090309090501010504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, We've had a small team that prepared a response to and incoming liaison from ITU-T SG15 on linear protection; both the liaison and the proposed response is included in this mail. In my opinion this team has done a tremendous job in creating the proposed response. This mail is to start soliciting comments on the response. We need to send the response before the end of the year, but will have meeting the 18th to check that everything is OK. Comments will be useful whenever we get, all the way up to when the response is sent; but they will particular if we get them before 10am (Boston time) on December 18. Thanks to the team (Eric O, Scott M and Yaacov W) for all the work they have put into this, thanks also to the support from our ADs, Adrian and Stewart. /Loa for the wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------000400090309090501010504 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="LS435 response v4.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LS435 response v4.docx" UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lE1Pg0AQhu8m/geyVwPbejDGlPag9ahN rPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX0QI8KmtS1k96LAIjbabMLGWv08f4 lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6MHSSW69FoFs/407IDzEDft3r 3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI+cJk31zirUNClZt3sFAO rwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4kNPWVmvNWAiJlrsuk OdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNMvv6CcVfouFXu RFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ou3dgqiq Yxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Y y4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANa Xg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQAfBa+pZwEAAOEF AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANSUwU7DMAyG70i8Q5U7TTvYBmjdLgxpBy4w xDlLnTZam1Sxge3tyTaVdbB1lwqJSyQ7iv3p/x2PJquyCD7AobYmYXEYsQCMtKk2WcJe549X tyxAEiYVhTWQsDUgm4wvL0bPUAjyjzDXFQa+isGE5UTVPecocygFhrYC42+UdaUgH7qMV0Iu RQa8F0UD7po12PigZjBLE+Zmqe8/X1e+8/naVikt4cHK9xIMHWnBlTU0F4sCfFHhMqCEfadC T8r4cYjrLiEQiLy8uGeoM20Iwy4Rcq+oK7RZ7hk28qL3LhUkyHmXwIUaSG1dK7TQaA2Pe1Gf 12+ebOptma4InBEnpeud4C61dBatolDaku+s21g2PJwKjrQuAN805VOlQFJTtp9XbfrFJziO zOj5OdpB1UIkbBe3tR902f4P7ev/U+6bLrk/YfHy69M2km3G33UJQn6vNnbXNuTbM64Z+MFi Hn8BAAD//wMAUEsDBBQABgAIAAAAIQAbSGh3QBEAAHQ7AAARAAAAd29yZC9kb2N1bWVudC54 bWzsW9tu40YSfV9g/6EhA7sewBfdfE2sQGNbiYE4MSwHs4sgWNBkSyJMsZkmZY3ylH/IywbI vu6H5Uv2VHVTYlMULY+Tt32ZkUV2dXVdT1W1Pv/i4zQSz1KnoYovGq2DZkPI2FdBGI8vGt89 DPZPGyLNvDjwIhXLi8ZCpo0ven/9y+fz80D5s6mMMwEScXo+T/yLxiTLkvPDw9SfyKmXHkxD X6tUjbIDX00P1WgU+vJwrnRw2G62mvwp0cqXaYr9Lr342Usbltx0nZpKZIy9RkpPvSw9UHp8 OPX00yzZB/XEy8LHMAqzBWg3j3My6qIx0/G5ZWh/yRAtOTcM2f/yFXrtFBX7mpVXVgK846GW EXhQcToJk9UxPpUajjjJWXquO8TzNMrfmyet7tp+yyNvo4Mr7c2hihXBNXIVwgjMomlk5ED6 XWm1TLHVrDuM1QiRWPKwDQvunjknUy+Ml2Q+TTRF4cIj3mLfX2o1S5bsJOHbqN3ET0ta5Jiv 4Kx5zJ5XPFr6KgJrrjuceIlsiKl/fjOOlfYeI3A0b3UFWWSjh2DxqIIF/Z+I+TmCTXB/0Wg2 Oyeto6tuI//qSo68WZTRk6vmyfHZ+/zJXeErIqLpn6x3L9ME7iZFpsTXw27n6PND+pr+5Td0 TpiWH79vH7cGzAtHrPM08XxwmWiZSv0sGz3x3HUIgEyyxvJxv9k6auWM3RdYthvYPTew3D5z tgCjRR5P3p+cHi1PfX+HUNRs2i/53Hd8LoTrrB+F4xhrn73oopHOEkRwX4dJ1jg05zdvZr1s ssWGLE6KuxVC+UY9CwTrtkOmUjSbtek+2SCaax364tv0UelYit3+LJso/e5P3/VSTSmHpWKk 1VT80/N8nPeDRAz0dCbjP3v/aqG7TPUDHXqxcFiBaWqlRtea7CdbJDDkNJFRNMzANtnA0kkG nkZi2mrxdRxY81m3e1eFRbt3n2xSbhBmkKl4XIihr7JM3HpxOgplFDicVdrV5VmndXld5XJb RYmd1rmzR8nn+medfrtVGxec5ZUsuowUpXN53e32l/Fig3QenB1qGOxNpPBnUChQVyozoUbi 5vphIHIolgotf5yFWorBUPxtnH0mhoP9uwMh7geXR8dHXRHGfjQLZCruD047e2I+Cf0J4bsM X/3+829b8JHHKxOcXpbeA1iWHzOpYy8SvoozraJUeKkI5CiMZVC2aycgFsn3wlh8j3N0u+2T H8Ttd8MH8SgFQl+i4KnBwe8//4fPSc+FH0lPl0/DYa4XLcrf50eiaFvcsdo5cxGnjow/Ewm2 RC5KJfIRzvz10IQU+gwd1e15ctrtD46MCfYGlM140cN3IoBiAg6/+83T/ebxgUOm0hQtsfxM hQS1jaNWH/kmZo58Ol828bJanVmLN8Im8zOGCIMMSekprDPYE5lzkpLJFwVSzdEEtNKJmkUB GYEXBMjiKUSVTQCyxhNmF0BkCptjB7F4FJ7wQEvtI/vt9sfx67juX55cDwzayXpL1sR+ac2L gXvthbH2psXAnuuW7NWR9mOYbrWZDfQVSYS2Wj51XLG4UbVO8jKSopIe+Rxv2FqoMPqIAENW HUgUcQFKzIVQMYUldle4tpbIuAFeUsVwMZ2i9BSJDpVGZbeF+b8qWdiXV9my+mA77XPXRCod b3MOOGt3j86u8gTGOWDLnR8gsdSXsQcBkO8A4j3CyiGukp4dVb0MdftxLD+KdgWhCbCEjsL4 SejzMLho6JvgiDiH12RKL9Ai4DhVtV9uliYzFJjQBozqYbaIJN5izPpVvlEZsX7dajddJA9x L9liXeU7bYnrd7cQVk5yjfmsd/ntrWgdIT3+QkEdZQZ/vN6CqImBLogthbot3Kq8kaEaxkHo c972xMgLoxmSPhyPfAwBJFEUDfEhU74qoz9HeQVL3FAXIWheUjqNFiLMxNR7givHConOll6U 1MN4xmUYvlzL6K+LZwbsmTMOB2XVVdLaELAKlKr9urXXeif2BbC1FSaaNxAg8tsHMQFCIbFC iqT4+UTG9ls438jzM4ggs29AQGUd5eZEFtq5PLrsv69DmOTmvgKs86l/JOacPIDxsH8tZSfj +Fqi/QSM7b0+5TgWUeS39+qUspFUtQ7IZu8Hx52TUyN5MiZ0bUyyGKkoUtSPKsXfkg9ZhnOZ GxcunMLGn0k4nqBqnmR4kUPQAgWTmpfjz/c3sGudFRUykVr+8DYVu3p8ZQJxU8uGImKn49Y5 lXucXB93+xzQuQlTQIfuE97DfsUh1zgkDBVhhgGUgdg5GOY+MBqzHH+u/3F9L0azmK3Zo5as GKkZAgNcxxYiDMQsLS9KFQUUokHmD4twKNhlqWCoAG+FtbRB4Cs1l2iF7ImQwh6YGsEBKAzi oy2DADTB0wp0ws+KcJAqH43afx5mBjIaHzI82LDwHAYzoMgwphIGJReanaMMMSMQQZj6M3Su 8fouTkaRlxDyOwI29Aft9PdU3N4ha6ATiaQ6FhHSKEEc+CoKL4NVYfIUS2eMfabq2dQPvpd4 pp8N4ek5sBGtQ5/zieiMqZdoecFesZA4gtTw/VjOSch0bk9M0chHz53b0iRXnEl+BAtEAi9t gaeuOsf9QWXxDeTWPek3rNcZozztdJoGAWtjMDvdLYzSpVSsnq8Mwfo9GNGnNnZqL0wJas6V SBSURmXtL2J4xRq7He5/WFrexIOkHyXJbgQJ402rxMQzOjIFKtbuiccZVJ6a/ArrmgOMkghJ 5Lk78Nv42hjP8KouXFhAyCLaEBbBC5TFtiPj51CrmNxjjyoXMVFzsoUp6k0y93QGU/JEGmYz VnR5Z6MJnBtSmOMUtgeQuyPH3jScJsjveOqhkEVjdKKiQGpahHoWpsJvDa2QOwetc8j1twdY eSDhGNMwNjZGfoHkCCnAHcEqCR4s0sfRTLOJptkswE54cerh/yQBtCDR4wQy8TQgzbKdge37 UQRnGUHOMcZEdGyQDOOEFALCBV7NhhwIqN8Qk2NSU6AsjjxNUGq21l2nCHEzcmN3Kfm8rEtC YVZwJIe38YPT1xF4mZulmaS1hIqS6TkBNe9zzB6ngINulDTB0bgC/IO0T4HSFC7kMWS6+HYe Qq2PUswIpbLu0Yx/QnRFhKUQV3fE06Oj1tm17Zbs1b1ZPMMGN4M9wSjFzd3dLbPKDucG2WLo Tt2ISWMN9UQzSC7PYVlUMmGEOj+PvSl6sv/6Ur3HwUxDNn8XcHX5punWr7db3cD3Qkg8O+m0 r85MXUamHCGA3QOIw2mCO28s3yPbPHFPOOv1CdYiNZCjowdLqW2I9IcIAlF8sNlllwLlOzRp CvHNZtQ80dfJ/eS42zk9qQO8VEhA7RYM1NF62aAp04EQgYM6QoNmp39c2+dFtKkjUDxVrx8E ZM4UoiGqumVbGGEOlUgFd8PLvLGlfLR6GZtAVHVbFDmrtnMQIDOvI/Iyn+wbdSSKfPRyW+Kp JxKARfLMR1VnziFciV2tBvP4XcCu7hOGIq3BcffocuUTWW9nramw7nabkYj7pHqLatnXSr3A 5obq+3I4yA2CKk4ETQzG0OLk5j+7cabD8ZhwsEUppGktASTh24T5hH0B9o1cBoSoAsn17RTD 1hDhXHiRp6eICEjcz5Ldfklgl0t/YFrTWqAaSgIe5R05YF1CvYjjFFCYMoxYS4nNgUYAjoCr 8okFp228ZzACtkPNS24ULXLWcFbkGscUNjQpN/VDiwLtMe8y2IZedQ+hSG2Dduk0Jk4SHkEZ o+gvK0uDVNJcpCkJnHCjxvTLYEVAVCW+MZ1qzopWWeLDw/2eQC+OWqkGokn/QHQOjtwU9EpP qTDjcvaApxy/CbQTWLxqO4XB+h45pDQg25T7FPtQJREeLGAm+khNLAaRMDRKHBSK9h/uSopF sFzdLfikeF8HBJccK9g6uaJtVcDu8+ID2N9ic4LTknOl1BoJSkuaUrHuDeLANRpAXUUIm50S yDcL/RkcURAIDsLxlA9cXr47/Ob2jlIem9kcxc67wlyFl1jhkFVS2IdDrSYldRIrptpesdlc XlQnJVOAWhyYXxCz6WdTSvij08E2Rl7tzTsnpU5TpXu59IvgrNlu91cXWjhLrJl+9c4PCNqY 4PtUrqOyQ4zHZGthB7SAGbm9kLK9CP0pAGdEDpT4YYqrYsBveICLdlB5JNGgwDPo/8VQuuHS wNJ8VXmICm+suHZQHT1fdkGxq2YZbgMtW9epj4PmyWbp+blguMZca6fXmOMeJxv2AWrowg/m cAnFM0Ou+6kuQxsAVahW1JGhAu3m7pChjq1F0jIurLQJV/OvtYneA3WdUy/cKlcVcx8fvlcu g9a05M71aiRmWvwLkhCncNzkym3JdV+SImQWoGtgYjhs8fef/43PdIfr959/tSaLKhw4BI02 gAGSLgV5xAPvET0vn1XtxYuV6SOojsLxDLGRync7rjUN8Sh8ktgNF3SQFSuM2wn/rXare2Xw 3wZghVExWhtL96HWXSqo4MkU+ESawZQygzvC0XYfdRiMIQjMrPbQ97ONem5t7r3ex4ppqshn T1M/kwyyFHHX1MluW+10DsHDWMWvnj9vlOMfzl91KHzHTmtzFjeHjcrJTkYz7vAaZcGjp9z7 StHrQyMWtgqL6du2aKHrQMZim8AwbDT+ME7+lKSYcs8Dobekn40Sqz4g2T+x5DrUyyXSen1a 58gOj5Uxyy2bijHLfVKdx3o7p2+CiRZuWGeo3qNafg+UK/0/ayreIfU4wiuMn1dTcdww//9U /NOn4tWafVcWvDb5zVwOAXwu6eW1juchDCBlKf9pZUArcLy6RvQcomqGlVUhUyFuKehQNgLm SjH33mlXs119xq2s66TOutbuKPzhFyzq4kp5JL/UwRpbW1+dMEpeA3ab8mS1XNcS8ZIx6vQ7 o/K3TsidHPu2CXmRVPW5XmNbgA88j0S3xpSr3bXVm4Tao2kMUB9DYbR3eA7Dl7WoarUjzTT8 CW+g47HE6ZSUAU/MfRN/4sWASfQCFpgpDd+rXst2WzQxrGRyfgvtPrf+qs4cvZ0zNzuVxjZb yN2ZK9phIsoVBAZgdUy/bPs85fb5PqNSArgAh/R5gctCd4f4kUFMF1NJJFgyAOT8SfIX3CxC FzxvFJhBCNAxg17AUCro6JpNXhSWGvD5xBe/Y6I7clgFjfOdO7raCy74HjA1VsAtyb9wCZdX 8LwTa3iqDsUXOAExJ9BWogdXC0X04Gpug37ynfMGEGqHXDq/0ngC0upTi2VVDXBPTUGc/+Uz JYSWacDL9UNBCWb+aG7fPtJNfpHhzhKpgUULsVINLZAFUJgs4SAM1jYwdyGtlfjxMwvU2xhW 4oIpZilmcoLbpihyDFDNJjNQhCZNV4gaOXkBS7UOnOPFO1hOcHqTa1SIvmDpnE3rpkPrStl4 JdxE+wLxrLetQzi2Bb804Z+9wuq96FNGnbjlEaNjiqgULC05WlBjlQpn1j635fjKL/qr9FPD vHCd27FW7pB7YhZHUCcUzsUqmRn9PgEmwLcj0EgxAL28kC9V4KUfaWwGV+duODUrzfVUy4cJ BdYvySyQ8XHFAK0GY4If6NpBFMJ6c+fEO8sZED7DZHDrBAdFAwgmhFqa75pTDLnFVRJjiNSW QOdwaasEbehuNRfZaEmySDgoLU3c3PbHjZAR0oTxj8GQzgGqoIOIDVEuL1XzTYrA2Lvp521f tuAEmNaXpqV5FKFu6Z2TnAtWlIyHPyHkz3HRtN3u8ih1gs9Hp/jMI8xkfIseKX70ohJ83zWv YAIywe/G8j8f8QsTNV39TR2x1V8TQECJn1adtJn8SGE8v/pzPMv4T7sdGs+475H/LoqWMBf4 wcWX6AngCTWs72iAetHoHPNTnNMcsUeGbn74hg9Ywj+X7f1PAAAAAP//AwBQSwMEFAAGAAgA AAAhADDdQymoBgAApBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0 b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Q r7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgq nASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI 6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i 1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sF fQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlslii BmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iY s+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk7 5Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/H H6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvk CO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4 EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx 9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sH dTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXm lgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobo d/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+Hi CjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8 KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHCh wGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81 CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFoh sPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz64HiK1UrcWprs G3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6GxzgFr0vdR2IW wmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3ITzHpRClRU o7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqg X+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/ z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdp mLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtq kpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kR PTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI 96G2Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/Paeyi OXPZObl4kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEH Jg8g+S1Hs3TjLwAAAP//AwBQSwMEFAAGAAgAAAAhAGGr0C9/BAAAjAwAABEAAAB3b3JkL3Nl dHRpbmdzLnhtbLRX247bNhB9L9B/MPRcr3WXLMQbyJLVJthtimrzAZRE20R4ESjKXufrO9Rl HXeZRdCgT6bmzJwZzgzJ8bv3z4wuTlh2RPCN5dzZ1gLzWjSEHzbW56diGVuLTiHeICo43lgX 3Fnv73/95d056bBSoNYtgIJ3Cas31lGpNlmtuvqIGeruRIs5gHshGVLwKQ8rhuSXvl3WgrVI kYpQoi4r17ZDa6IRG6uXPJkolozUUnRir7RJIvZ7UuPpZ7aQP+J3tMxF3TPM1eBxJTGFGATv jqTtZjb2X9lgi8eZ5PTWJk6Mznpnx35Lc9ruWcjmxeJHwtMGrRQ17jooEKPjdhki/IXG8V8R vaT6DlK9Gn2vNBWYO/awukbe0Vf2hmqPVXwglURyLDM0gI6C1cmHAxcSVRSa6uz41j101Fch 2OKctFjWUKSNtQ6tlZbDXsS+VEhhQLsWUzq0Z00xAq5zcpCIQWNtrFEy2DR4j3qqnlBVKtGC 0glByJFrj5T1EUlUKyzLFtXAlgmupKCzXiP+FCqDJpWQw8liaFkdzti85dj+YMERg02M0qml H0WDdWS9JK/y9N08a4MhSkjHsAezIwHHVZIGw9YoLtWF4gKCL8lXnPLmY98pAodkaOyfiOCt ADDXnj/B4X66tLjASPWQpv/J2VCJgpL2kUgp5AfeQGv8rLPVXERdTrj7mm5e/C2Emstg21vX C/J8zIVWuyK266b5VKZ/IYEX76Yuu0Uc1/HzzMTmFKEfGBEvcgKzHy8LsnRrYvN2gVMY2fxd WBSpySYI7CIIjEjue6FrQsLIjvPIiKS2EzhGZOuGTmFCotD3YiNbFPtpYYwt2jrbyJjraBvF gTE70S70UyNbHATOemeKLQ5DLzJGHWe2fryG43pb7bXrB2tj76wjz83XJpt07aWuMW9pFu0K Y79tbd+Pzch3u3cbBLu1MQdbyFtkrHbm+35k7J0sjHaRMeps7TmZMaPZzvdTs80uKEJj3nI7 CtfGmuZemBZGP3nsebYxO5CAXWi0KWwvDY2xFaltp8bsFFno5QMCd4tuBLhRWKJngr/kvNLX 9IKNV3yGWCUJWjzqqQG6hyWV/LIlfMYrDFMT/hYp+2oGl8sR6BiitIB3bAaGo8CShnRtjvcD LX1E8nDlnTSkUQpv5scXLv0EY/m7FH07ejtL1I7X7+zO8f2Jj3D1QNgs7/qqnK04vPzfQD1v Pp2kJlxd03NOFAyMwzP2gPhhvmUxX34utSrc1lSWeqjEj6ht4bkGlergbCxKDkfl6KdHwVcD w+XwUR3cCXMHDL40NnygWu8MtKeFVhiXoDUtrjJvlnlXGYxOo55/lQWzLLjKwlkGw+05OcJb KWFw+QIDwbzU8r2gVJxx88cs3FivRGMSuiNqMdRVzzXQXiIZBNOg0y1OCX6GoQk3RMHM3pKG oWcY6W13uJ4mbYouolc3uppJK7c30kWDFALzoVQ3xlA6mMJuYzknDa4JtGN5YdV1jLobA6ek UyVuYeJSQsKWhyHnt4H5+jfi/h8AAAD//wMAUEsDBBQABgAIAAAAIQDzDYbz1gEAABgLAAAU AAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVs1u2zAMvg/YOxi6N/6R7ThGnQJB0WHAMAxr9wCK LCdCJdGQlHjp04+x2y5dd4iBFujBJ1MU+ZnkJ0q8vPqtVbAX1kkwFYlnEQmE4VBLs6nIr7ub i4IEzjNTMwVGVOQgHLlafv502ZWdWN8K79HSBYhiXKl5Rbbet2UYOr4VmrkZtMLgZgNWM49L uwk1s/e79oKDbpmXa6mkP4RJFOXkEcaegwJNI7m4Br7TwvjeP7RCISIYt5Wte0LrzkHrwNat BS6cw3y0GvA0k+YZJk5fAWnJLTho/AyTCYeIwiMUusdRL2lFAs3LrxsDlq0VVrCLU7LE8tVy 7x6/QVfKuiLzaE7pIk367TXUh2u5x609U8gMCY/GWLtvovFP2uhZ+1Nutv9R30H72nYF3oP+ R4/hrGp7/If/62OQc4KG7qEieDJQaBnHHHqZgwKkiu08DGGok8jGea5fRDTO155mPsY17Dno kx7El2ykcZIvFkk00THqELwbHXlUZLRYxFN3jOnJ96JjUcxzSrOUTnR8BDriOMsozdNiao8P cVslUZZQOqfJ8NZPj/mZI8RbXlfDo97PWNB6qeWDuAG7stA5YftpiikF3Y/vX3CBxifz7PIP AAAA//8DAFBLAwQUAAYACAAAACEA3xUsB6oIAACPQQAAGgAAAHdvcmQvc3R5bGVzV2l0aEVm ZmVjdHMueG1szFxbc9u2En4/M+c/cPju6GJXajxVOrFdN55J2zSyp88QBVkckwQPL3acX9/F goQoUiR3TWbmPMkEgf12sbvfQgo2v/z6LQycZ5mkvopW7uzd1HVk5KmtHz2u3If727OfXSfN RLQVgYrkyn2Vqfvrh//+55eXyzR7DWTqgIAovXyJvZW7z7L4cjJJvb0MRfou9L1EpWqXvfNU OFG7ne/JyYtKtpP5dDbFv+JEeTJNAe1aRM8idQtxYVOaimUEWDuVhCJL36nkcRKK5CmPz0B6 LDJ/4wd+9gqyp4tSjFq5eRJdFgqdWYX0kkujUPFRrkgaVpzANStvlJeHMsoQcZLIAHRQUbr3 44MZb5UGJu5LlZ67jHgOg3LeSzy7aOBZkyk+uEnEC7jiILAh7sRmbM2iMDD7oP178Gpd4mza ZUzhES3C6kBR4Riz1CQUfmTFvG1rqpsL+TAkvn9PVB5bdWJ/mLS76MnK0mnJ0Gy6wMyrmpay BDRSd70XsXSd0Lu8e4xUIjYBaPQyu3B0RLofgCq2yruRO5EHWaofky9J8Vg84cetirLUebkU qef790AhICX0QeCnj1Hqu/BGijT7mPri5Mu9nnXyjZdmFWlX/tZ3Jxox/Q4yn0WwcufzcuRa a3A0FojosRyT0dnDuqrJyrVDG5C7ckVytv6ohU3QzPKzYm58ZDw8oSqx8CDzAEfsMgkkBCym cQJfe3e+BEYzD19zvbkiz1QBggIArCoWHms7DtwETLU2jA1v5e6z8p7kdp3Bi5WLWDD4cPcl 8VUCNLpy37/XmDC4lqH/yd9upS4QxdhDtPe38p+9jB5SuT2M/32L9FxI9FQeZaD+YolREKTb 3755MtY0CaIjoT38p14AHAbuqOCgQrl/0MYM1FBx8H8l5Mz48CTKXgpd0hzUvxMIrc4HA821 RVUDUC5L1/PhIi6Gi/hpuAgM3mF7sRyuBRxkhnrExEYlKulOzZRngq+6D+fvO0JWr2hEUe+K RtD0rmjESO+KRkj0rmhEQO+KhsN7VzT827ui4c7OFZ5A4qpH0TnuBimx7/0sgDrZw3SzgVRX lBrni0jEYyLivaMLa13tLrJc55uMpirS6dvJcp0lSh83e3YEqrNO3Tdz8m9hvBepD6fyPqCB W3+vjz7O74kPx9ceqJ9M8DVswoPJyRL2JRCe3KtgKxPnXn4zHmWs/1M5a3PK6FVuoFs/+4/7 zIFToS65vWCLlk1v3wkj/7Of4h50VvNFiyl9wkk+XLTEZbvwP+TWz8NyawinkYXhc4abaxCo YvcWXWgXNbOr1wrtAIoJplzwTUD5BP1NceHL1z6m6G9K0RvlE/Q3heuN8jE+uv3LZpob+FnF IaXXkp271ypQyS4PyhzopYclO4MtBM0EdhJb+SSSWLIz+Ig+nY+eB9/cKHHK9sWBRxkobHcY FEw2ui1sp9Rob8awiO2gGtacgTWMaxlAbNL9Kp99/SMwtxggS9uzZm86n7fsAJQg0hn671xl /WfoeQvnUVHuIvi5JJUODe28JfOoaEU8mXrH8PGwwscAGlYBGUDDSiEDqCU+2s88tibSQYYX RwYWm5ZtFcOwIzPzks3MFohXAkaqm4TzV0v2tsdCs24SUNgOatZNAgrbO7VaZusmAWu0uknA aqka7T6qcirHKHbdrALZkwDBonHImwA0DnkTgMYhbwLQcPLuBxmPvAlYbG6wnFolbwIQTuF8 1bdAVfImALG5wbBd8ZtRWfdQSveX2xHIm4DCdlCTvAkobO+0kTcBC6dwIqGGZamOgDUOeROA xiFvAtA45E0AGoe8CUDjkDcBaDh594OMR94ELDY3WE6tkjcBiE0PFqhK3gQgnMLhhpPkjVn/ w8mbgMJ2UJO8CShs79QI1R5SCVhsB9WwLHkTsHAKJxgKLAxujlHjkDfBonHImwA0DnkTgMYh bwLQcPLuBxmPvAlYbG6wnFolbwIQmx4sUJW8CUBsbjhJ3piMP5y8CShsBzXJm4DC9k6NUC3P EbDYDqphWfImYGG8DCZvAhBOeSsQx6JxyJtg0TjkTQAah7wJQMPJux9kPPImYLG5wXJqlbwJ QGx6sEBV8iYAsbnhJHljjvxw8iagsB3UJG8CCts7NUK15E3AYjuohmWpjoA1DnkTgDAwB5M3 AQinvAEIs4jjpnHIm2DROORNABpO3v0g45E3AYvNDZZTq+RNAGLTgwWqkjcBiM0N+p4t3Bcl X0+dtQQB9Z5BeauBDDhvcRIVsDDwq9zJBLoKZf/tkIGApYUMxJbwoJp4pdSTQ7vYfd4SIGQo fxP4Cq90v+ItnUojwvmyo5Pg/q9r55NpgGmsw5A6vnkD3UPVdiFsT9KNQ6Bn9hpDy05c3izX 0qBBSPd1FS1A2BN6Bw1BRVuPXqz7fGAiNlUVw/jvtgUq/A2IuLAJ5e0By4OOqA6o4sK7vYOE 193rwC234lGRQ0tGqWZxO/5whjLzju5oduqd6ZvgHTrjTfHOPXJwivFqU0FozkKV+jQEl20C 02IGf9xFW7DwpejOMs7cfhNGFLy/lkHwh8CGtEzF7VMDucvM29kUK2BN1EZlmQrb1yd4QRw1 OSUAwqGqjHnURrTHSZSHG5kU181bQ1JXDuxEOw5Jc9e1JRSoO92u21G62AS5EkGgVIQ3+evB Wrwz1/xRr42ANru/dNdcI42gRfCpHK8IvYbMGR490BeuQwZBp9Ob6XLx/spIbWtcxH+QLdoW L+zD6bbFokUSPo56P1fuvdirUOj8wa7O6oAHzarFa5MBtolztihy4vuhidOMgW+g5bQrfo54 xstTCF9slqzTWn2DuzznHFxQc99JxkJrWpzJdGS713Ab/t/22+bEJygvid6CRpIe3pxKh/b9 bGfO468hKPV42xZX88Xs1ux8sW2evrx+SIfp9PZWxyh2F+OpEfqorQkoMi9n6//iACoCDDaD saSO9MO/AAAA//8DAFBLAwQUAAYACAAAACEArpL2Y4QBAADvAgAAEQAIAWRvY1Byb3BzL2Nv cmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA hJLBTsMwDIbvSLxDlXuXpkMIqq1IgDgxCWlDIG5ZYkagTaLE0O3tcdutrAiJW2z//mL/yexq W1fJF4RonJ0zMclYAlY5bexmzh5Xd+kFSyJKq2XlLMzZDiK7Kk9PZsoXygV4CM5DQAMxIZKN hfJz9oboC86jeoNaxgkpLBVfXaglUhg23Ev1ITfA8yw75zWg1BIlb4GpH4hsj9RqQPrPUHUA rThUUIPFyMVE8B8tQqjjnw1d5UhZG9x52mk/7jFbq744qLfRDMKmaSbNtBuD5hf8eXG/7FZN jW29UsDKmVYFGqygnPGfI53i5/odFPbpIaCCCiDRhRJcXLtgoes7JFu7P2DXuKAjtY4i6tUQ VTAe6RF78ChB6kpGXNCrvhrQ17tyqRxispA2UqLSHfCXpL0xwJdpP0aZZ51kiGm7zsx+aNAJ 2VP0Zh4qT9Ob29Udo1aRpyJLp2IlzgqRFVn20q426m/t6hP1fsh/iSLNL1ciL8TlmHgA9C6N v2j5DQAA//8DAFBLAwQUAAYACAAAACEAB+2OKCEIAACePgAADwAAAHdvcmQvc3R5bGVzLnht bMxb23KbSBB936r9B4p3Rxc70toVJeVLvHFVLk5k1z6PYGRRBkYLKLbz9dvTg0YIBHQbUrVP FgPTp6+nkTz97sNzFDo/ZZIGKp65ozdD15Gxp/wgfpi593fXR3+5TpqJ2BehiuXMfZGp++H9 n3+8ezpLs5dQpg4IiNOzyJu5qyxbnw0GqbeSkUjfqLWM4eZSJZHI4DJ5GEQiedysjzwVrUUW LIIwyF4G4+Fw4uZiEooUtVwGnrxS3iaScYb7B4kMQaKK01WwTrfSnijSnlTirxPlyTQFo6PQ yItEEFsxo5OKoCjwEpWqZfYGjBkYjQZaFGwfDfFTFLpO5J3dPMQqEYsQnPc0OnHfg+d85V3J pdiEWaovk9skv8yv8M+1irPUeToTqRcEd+BSEBAFIOvTeZwGLtyRIs3O00AcvLnSTx2846VZ QdpF4AfuQCOmv0DmTxHO3PF4u3KpNdhbC0X8sF2T8dH9vKjJzLVLC5A7c0VyND/XwgZo5vZv wdz1nvFwhaqshQfBAByxzCQkBeSIxgkDnYPjKeSLufix0X4Vm0zlICgAwIpi4bLkccgVyJy5 SWC4K5eflfco/XkGN2YuYsHi/c1tEqgEknTmnp5qTFicyyj4FPi+1PWSr93Hq8CX/6xkfJ9K f7f+/RqTP5foqU2cgfqTKWZBmPofnz251mkLomOhI/xVb4DEgXAUcFChTbDTxiyUUHHx3y3k yMTwIMpKCl3hDurfCIRWbzoDjbVFRQNQLkvX4+4iTrqLeNtdBCZvN19Mu2sBvN41IiY3CllJ D2qmPJN8RT8cnzakrN5RyaLWHZWkad1RyZHWHZWUaN1RyYDWHZWAt+6oxLd1RyWcjTs8gcRV zqJj9AapsO+CLJR6fyMBjTpSXd5qnFuRiIdErFeObqxltZvIcr5ZZDRVkU5fT5bzLFHxQ6tH oDvr0n01J3+M1iuRBvCW1OL6cUfX3+m3HufvJPBbod6a5KvYhC8mB1vYbSg8uVKhLxPnTj6b iDL2f1XO3LxltCrXMayfg4dV5sxX2HJbwSY1Tq/3hJH/OUjRB43FNKkxpU04KYaTmrysF/5F +sEm2rqG8DYyMXzOCHMJAlVsdtGJDlG1ulqt0AGgmGDaBd8ElE/Q3zQXvnwdY4r+phW9Uj5B f9O4Xikf86M5vmymuYIvrQ6pvKbs2r1UoUqWm3BbA630MGVXsIWgmcAuYiufRBJTdgXv0adz 7nnwzY2Sp+xY7HiUgcIOh0HBYqPbwg5KifZGDIvYASphjRlY3biWAcQm3R/yZ6B/E+M2A2Rp +67ZWs7HNR6AFkR6h/6+UVn7O/S4hvOoKDcx/FySSoeGdlxTeVS0PJ9Mv2PEuFvjYwB164AM oG6tkAFUkx/17zy2J9JBujdHBhablm0Xw7QjM/OUzcwWiNcCeuqbhPevmuqtz4Vq3ySgsANU 7ZsEFHZ0Sr3M9k0CVm99k4BV0zXqY1TkVI5R7L5ZBLJvAgSL+iFvAlA/5E0A6oe8CUDdybsd pD/yJmCxucFyapG8CUD4COervgUqkjcBiM0Nhu3y34y2fQ+lNH+57YG8CSjsAFXJm4DCjk4d eROw8BFOJpSwLNURsPohbwJQP+RNAOqHvAlA/ZA3Aagf8iYAdSfvdpD+yJuAxeYGy6lF8iYA senBAhXJmwCEj3C44SB5Y9X/dvImoLADVCVvAgo7OiVCtS+pBCx2gEpYlrwJWPgIJxlyLExu jlH9kDfBon7ImwDUD3kTgPohbwJQd/JuB+mPvAlYbG6wnFokbwIQmx4sUJG8CUBsbjhI3liM v528CSjsAFXJm4DCjk6JUC3PEbDYASphWfImYGG+dCZvAhA+8logjkX9kDfBon7ImwDUD3kT gLqTdztIf+RNwGJzg+XUInkTgNj0YIGK5E0AYnPDQfLGGvnt5E1AYQeoSt4EFHZ0SoRqyZuA xQ5QCctSHQGrH/ImAGFidiZvAhA+8gogrCJOmPohb4JF/ZA3Aag7ebeD9EfeBCw2N1hOLZI3 AYhNDxaoSN4EIDY36HO2cF6UfDx1VJME1HMG21MNZMBxTZCogLmBP+RSJjBkJdtPh3QE3FrI QKxJD6qJF0o9OrSD3cc1CUKGChZhoPBI9wue0ikMIhxPGyYJ7r5dOp/MAExlH6bU/skbmB4q jgvheJIeHAI9s5c1jOystyfLtTQYENJzXfkIEI7I3cBAUD7WozfrOR94EIeq8mX8v22OCp8B ETdWobwVYHkwEdUAlR94t2eQ8Lh7GbjmVDwqshvJ2KqZn47fvUOZ5/bOaDbqnemT4A0640nx Rh85+IiJalVBGM5Cldo0hJAtQjNiBh9uYh8shCFB/K+ZCab/LIwouH8pw/CLwIG0TK3rHw3l MjN3R0PsgCVRC5VlKqrfn+ABcdTkkABIh6Iy5lIbUZ8n8SZayAQmvBp8/lXpzoGTaPspac66 1qQC1dP1uu2Viy2QCxGGSsV4kr+crPk9c8wf9VoIGLP7pqfmKmUEI4KP2/WC0EuonO7ZA2Oy OmUQdDi8Gk4npxdGat3gIqZWPrZ4Yi8Ojy3mI5LwZ2/2c+beiZWKhI4lTnUWF7zUXpkKsEOc o0leE792Q5xmDWIDI6dN+bPHM94mhfTFYckyrZUd3BQ5ZxeCUvgOMhZaUxNMZiDro4Zu+L/5 29bEJ2gviXZBpUh3dw6VQ70/65lz/2sISt132+RiPBldG8/nbvP04fVdOQyH19c6R3G6GN8a YWramoAiN9un9ag1dARYrCbjljrS9/8BAAD//wMAUEsDBBQABgAIAAAAIQDQuFjG8gEAALsF AAASAAAAd29yZC9mb250VGFibGUueG1snJPfbtowFMbvJ/UdIt+XOCHtWtRQdWxIu9nFxB7A GIdY9Z/Ix5Dx9ju2Q3qB0EhBiuA79qdzfvnOy+tfrbKjcCCtqUkxoyQThtudNPua/Nms759I Bp6ZHVPWiJqcBJDX5d2Xl37RWOMhw/sGFprXpPW+W+Q58FZoBjPbCYPFxjrNPP51+1wz937o 7rnVHfNyK5X0p7yk9JEMNu4WF9s0kovvlh+0MD7ez51Q6GgNtLKDs1t/i1tv3a5zlgsAnFmr 5KeZNKNNUV0YacmdBdv4GQ6Tp47yYIXXCxp/aUUyzRc/98Y6tlXIri8qshzAZf3CMI3iiim5 dTIWOmYsiAJrR6ZqQku6pg/4DN+KzsOT5MGBt8yB8ONBmuSGaalOZxV6CZAKnfS8PetH5mRo KJVA7rFwgC2tyY+CUlqu1yQpRU0qFN5Wo1JiU+nzPJyZjwomBxuLPvFI8Rx9UEGf4VbsM0/R uSCxkVpA9kv02W+rmblCpKSPSOIBeQQy80lEXPSNBG8lgo2Xb+P8OMkKla9PVTHMP4lI8plA hLXY8RUQ3xBECEVAUX0+Gsb6jTuIzakTU8AML3T+EZXxFafwfICJwcCAXY8KpRHn7WBWTOPO XCMTopG4hKhMW5rPReRyaWg1hmYKif8vzbA9sPwHAAD//wMAUEsDBBQABgAIAAAAIQDGltBN 9gEAAPYDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CDonpuy6iWHQDAIHRQq0jQEpyZml VjZRiiTIjRH367uUYllOe6pOsw8Nh7NLfvPammwPIWpnV/l0UuQZWOVqbber/LH6crnIs4jS 1tI4C6v8ADG/ER8/8E1wHgJqiBlR2LjKd4h+yVhUO2hlnFDZUqVxoZVIYdgy1zRawZ1TLy1Y ZLOiuGLwimBrqC/9QJj3jMs9/i9p7VTSF5+qgyfBglfQeiMRxI8kx0xqhy1nQ5ZXDqWpdAti WlwtqDLEfCO3EMUnznrAn12oo7heUKaHfL2TQSokE8V8nv4eJfit90YrieSv+K5VcNE1mD10 TmSJgLNxCyd3SlAvQeNBFJyNQ/5N2yTlmrMekbYgt0H6XSTdSeEQ8lJJA2syQTTSRODslOD3 INOAN1KTZL7H5R4UupBF/ZtGPMuznzJCsm6V72XQ0iJZmNr6oMPGRwyi0miIm2p93MFx2xjr uZh2DQTOGxNBr4EK5+q6E+JDQ3fDf4idjsV2GnqpIzkjOJzxjnXtWi/tQax1VC4rDxGhjRfZ V6smNM23YrL/V3z0lbtLm/Rm63lytAvPGnell4om9nk2p4uftmJU4iUtD9Q05iPhKcHvaQTB pFPpX7uF+tjzdyHt2VP/jMV0Pino6xbrmKPlGN6X+AMAAP//AwBQSwECLQAUAAYACAAAACEA CSSHgoEBAACOBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAALoDAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQAfBa+pZwEAAOEFAAAcAAAAAAAAAAAAAAAAAN4GAAB3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABtIaHdAEQAAdDsAABEAAAAAAAAA AAAAAAAAhwkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsA ABUAAAAAAAAAAAAAAAAA9hoAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAA IQBhq9AvfwQAAIwMAAARAAAAAAAAAAAAAAAAANEhAAB3b3JkL3NldHRpbmdzLnhtbFBLAQIt ABQABgAIAAAAIQDzDYbz1gEAABgLAAAUAAAAAAAAAAAAAAAAAH8mAAB3b3JkL3dlYlNldHRp bmdzLnhtbFBLAQItABQABgAIAAAAIQDfFSwHqggAAI9BAAAaAAAAAAAAAAAAAAAAAIcoAAB3 b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQCukvZjhAEAAO8CAAAR AAAAAAAAAAAAAAAAAGkxAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAH7Y4o IQgAAJ4+AAAPAAAAAAAAAAAAAAAAACQ0AAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAA ACEA0LhYxvIBAAC7BQAAEgAAAAAAAAAAAAAAAAByPAAAd29yZC9mb250VGFibGUueG1sUEsB Ai0AFAAGAAgAAAAhAMaW0E32AQAA9gMAABAAAAAAAAAAAAAAAAAAlD4AAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAAAwADAAJAwAAwEEAAAAA --------------000400090309090501010504 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g8131y1382-revision-linear-protection-switching-for-mpls-tp-networks-attachment-1.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g81"; filename*1="31y1382-revision-linear-protection-switching-for-mpls-tp-net"; filename*2="works-attachment-1.docx" UEsDBBQABgAIAAAAIQCubbwv3QEAAH4JAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0Vjtv2zAQ3gv0PwhaC4lOhqIoLGdokrEN UBedafJkERUfIM+J/e97tGzBCZRQia1FgHT8HvcQjvObrW6zR/BBWVPlV+Usz8AIK5VZV/mf 5X3xLc8CciN5aw1U+Q5CfrP4/Gm+3DkIGaFNqPIG0X1nLIgGNA+ldWAoUluvOdKrXzPHxT++ BnY9m31lwhoEgwVGjnwxv4Wab1rM7rb0uXPizDrPfnTnolSVKx3x8TsbRICuBxHbIkaGMR7a 8ALEnWuV4Ej1YI9GvsilOORREnJ/JjTKhS+U7CsKMfI8j1OBA+4XNcArCdkD9/iTa8qWPVkv mbRio6lS5ds0Az5tXSsBPT6yOW8FhECd1W3ZRzRX5uj/VR9mo1fgCXl5Iz110kTAXQvh8g46 3pHyfxU2d3UNguY63RQdilj5spM4wabVAJHqPUbk+d9WpDofDsxJC0+w+j2ZixPypJHaWjQW p+h9T500AUZO5OHInLTQAJfgr0bM3TtHoiNO6sdiTaLfEY/Uv758/qP1DS75qoUpHByok0VA WrHA9s/zJ2FP85YkrYkHb12gle0/kPZxW0Z0QfvHgUcF/b4c2je9Iu3Js+sM8UIhQb5XW2wC Wn22fEczIM72t6fFfwAAAP//AwBQSwMEFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsACAJfcmVs cy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsks9Kw0AQxu+C77DM vZm0iog06UWE3kTiAwy70ySY/cPuVNu3dy2IBmrSg8ed+eab33zsenOwg3rnmHrvKlgWJSh2 2pvetRW8Nk+Le1BJyBkavOMKjpxgU19frV94IMlDqetDUtnFpQo6kfCAmHTHllLhA7vc2flo SfIzthhIv1HLuCrLO4y/PaAeeaqtqSBuzQ2o5hjy5nlvv9v1mh+93lt2cmYF8kHYGTaLEDNb lD5foxqKLUsFxuvnXE5IIRQZG/A80epyor+vRctChoRQ+8jTPF+KKaDl5UDzEY0VP+l8+Ggw R3TKdorm9j9p9D6JtzPxnDTfSDj6mPUnAAAA//8DAFBLAwQUAAYACAAAACEAX4X/eRQCAACN CwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8VtFumzAUfZ+0f0B+x8akTbOqpJu2rMrD XrpMezZwAavYRrazNH8/JywJaYOnVdZekHwR9x7OOT723f2zaKNfoA1XMkMUJygCWaiSyzpD P1Zf4xmKjGWyZK2SkKEtGHQ/f//u7hFaZt1HpuGdiVwXaTLUWNvdEmKKBgQzWHUg3ZtKacGs W+qadKx4YjWQNEmmRA97oPlZz2hZZkgvSzd/te3c5L/3VlXFC/iiirUAaS+MIFy42a4h0zXY DAkoOeuLFHeyRuQyBjr5PyAmGEQ1CiIoE5VSFvSJin6dYifXGIAxEgQvtDKqsrhQgvQi7Mi/ OdeXGLttwfzktllUFRTWnKa/euXDcRNSDJCldEwMsBwqPgg0DYlh3JWp1xBBibhsCOpjISgJ vQVeWsI3nk5DitAAK4cbol/7/9+FZbhssi4zB9m0X5L90wuChsQg1yIH7bL/pMOx5JMiqBI7 J77Yk8eSDwQNSkXjDh3dcvl0ouLPCbTZbDC3a8zdGaOhIKv4cfE5fsCzZELjNKE0mcZLAvLw 4TdVuuNr8ezyVrLRdL0OqeMG8u9grRNyEGyDopfGoEjGs+3am21Bt9ZbtJzhvZhJkr5BTPoh pJqVknbF8naQDseST8mrkCDMKz8dKj4IQXm4IKNgvLXq9qFhkuNPec7MR5dfhTFK7m4j/7YF aVDCxp1/dXA+ObtEz38DAAD//wMAUEsDBBQABgAIAAAAIQBGr6fyEzwAAMF3AQARAAAAd29y ZC9kb2N1bWVudC54bWzsXdty40hyfXeE/wHBp+6wLrxJlBRurimK7NGuupsW1W6vXxwgCUkY gQANgFKrn+Yf9sV+87f4U+ZLfDKrCtcCCVIkpZkde3eb4qVQlZV58lpZ//yn71PHeLT8wPbc D5XaQbViWO7Ym9ju3YfK15v+/knFCELTnZiO51ofKs9WUPlT+x//4Z+fzibeeD613NDAEG5w 9jQbf6jch+Hs7PAwGN9bUzM4mNpj3wu82/Bg7E0Pvdtbe2wdPnn+5LBerVX51cz3xlYQ4Hld 0300g4ocbpofzZtZLp516/lTMwwOPP/ucGr6D/PZPkafmaE9sh07fMbY1WM1jPehMvfdMzmh /WhC9JMzMSH5j/qFn1uF5rnilxeSAvzEQ99yMAfPDe7tWbyMdUfDEu/VlB4XLeJx6qjvPc1q zdzzoiWX2YML33zCVsQD5obTEGMifjR1BB1of+NdzY5Yqy5ajNwRGiKaQ5kppJ+pZjI1bTca Zj3SJIkLiXgJf3/0vfksms7Mftlol+5DNBYJ5gozqx6z5CWXFqw0QE50h/fmzKoY0/HZ5Z3r +ebIwYyeak2DOLLSBliMvMkz/RuOHPnPwJcvvhlPZ08fKqen9UYFL8PnGX48+W5WDuUXrsxn bx5GH93a361J9GHXcpxPJo/lWLf0LYx11NKM5Nt398WfH/LcEqNhplee94ABH03nQ6WK/6NB b20/CK89PIT/dMzkX/xh13PmU4Bp9HnqDdf76RxwKj92vX9Tf2G1Yg4RYT769oRIcId/MYZY Wq1Za4nFp94G5mnePTrWfrd12tB8uXmiHeKoqfmufuBGo3lEXxbrUNMPfcwcCmZyTVTsVeu1 xilRkt8aAG6jN3m/fbH+semGwxnwXI4n3w7H/KWxJNJYMg9TBWNmmOfxk+XfWXift9C3oMn8 UM1QjjFTU0lMRL2Vmp1688K6NedOmP/6IPEWzXIE9iEFNaSn4td2tOvmFCx+6QaWH155d54g sO7rNSKUy1+fuPMp/TX2nD7x4IdKXf55BR6kv1hedKPwF+UoIQmnOU9/uedOovnxKD7+1O+P 3IcRf831Br7n3fLr4Ad+w3RuHIvRHdO9U+9Z7v7XIc3XwmQ7gW1+qPy43+9+pm+CXeSoUpOA eLMz23Vs1zImdhDegLAVfnUevbqKXhFbYWQgzZnpju89/5LoXGu2jrqNrvzAmtghvV0/7XSq nS5j0uzM+h6S/TL+/qHSatWO6kcVY/z8oXLSOFHihO/c3lrjsCe+CRyonVaP8DgQHP8L5j3l n43oTyLDjMyigW/QXmPzBNEH9jic+5aBNyZWMMav7HC+7zkCxWZn48+PH31zdm+P+z72mnjb hNTH71x544dAGkagXAbrl6tkoQhdr3uPLbE6wQxLovkx8Rc//6VPTSzlwgxNY+7nFd/yBcwE BaFK8OoM/5XTwqs1yJEezX0c2IwFeJu2Qu4etrfE7qnfiBFMmprYrDyxjegt3/ee7i1zAq0r 9iA9yiH9mZrVyLFnfduB6jTP6LXhn1nTkQUeA7Of0DaaZ4E/vsa2itehb4Xje3r7Fj+T7x/i S+oDfkY8LD0xmGHlo6dP3gTgZM5DD9Q2z77f+lP6F5aZATkBVSAhzOsmyc8C4cHj1I9nwKuP ljc16AUmjXny4ObjVcAAD8LJr9CzXI8WyytxXINsAxKyzCdTO7R8w7GnEFhSznJORFfAGf84 NG1HvMZcHBdIo9YpX+JPvIpkjRg0+TdeR0BEr88ifCLI4ndm/L9KK2l101HtmGE8o5tIfQ9n JtYnUJNBkzTn1vUS9pkmKjE3xu06k1ChMf5VX8QUFyqDoiGwmPbl55ve9efOzeWXz50r46Z3 1et++fTp6+fLLr9n4NWXz2wxMCVLU5VtDUwsRdXtka/bqDegTYhukio/j9XOsWHJ6K9oOgL7 PZ0lyMIyqqFsYh8W/wYLJciDkJpjiOcMtozlP1qVNqhp1I6MX3/5m5GiIuZJqrnnkyoXRALs Ow4bI3Kyqzy9fTUsNT7kbY3R9WvLroiWwowIBKomdiRlkxRRnZix2TjKLCIpCWvuANO+lxqX ZCcCBmJKfszLDWEa6SdL+jHC1jqKLG5JBYVFq1jIYNftiY60+InZdMYpO33SOJ2YIdzI0jZu bLZKUyZBdZBK7yo0q00oMXyc9jOzcCy9ntf1IBQAi70U/DnqBll0UaqDOYB4TwK8EpeUG5MT +mUDglTtHG6n2B1SualHjXxeXNge3nQ+X3SuLy7/Q+iJYa978+U69VghZViuejjBwiL/Un2v tAenCCnoGUxNx+masxz9t6A39YA4vPl68Vdj0Lu+/HKRA8fExiYwMDU32kq4Nqf7CL/WNbRk EKBximSneYzI6lLZ4ejCTgCltC4WTI45pWREcJBcNf2zNZxuieAKP0MhsyC0+qtMJEPIxvgc 4VGE7On3Iy8MYVdLG5LC6A4jaPADvgX7/dJiYMxD7MCD98nGvcL8aDAmg5jN9iRKpwGaxFJS A3g+RQ3ojZJxjlgHKK6LNW8xH6+hA377tE+j2WraBMxRhq4r4ANtTsR7G2VkCEPHse8iz2qM II/lVxTDL2fxVfXDcldAo2NLuwTLfgtCtnuQezu4NzzXedbg+g505OvT4Av8MNs1nTNDUkND CMY4YexuDeobyD5IXltikh8jlL9cm3JgdyfgXAwQeHxKcepNecRPIyCfWlbImcTSSJ4Mk7OV IVXCyJlbM5vSXcmhOKQCHSGC32z/x5OKlYI04338dmEII4mGarEkWP86R9IASd13wfuzYn4q VDSNxnEZZ2N3W1xMiLB9elhLu8cgRBnQP22WMQp5J3bJxhpEogUR/KcWRnN6fTAoSH9m3VKl NXYWJYypGKtRCQaQNzaK9LZ1LI1JwWbAk4Id2qEwVmNTT1mpQqrZd4nHiaWaYx66D2TmqZjL JSLrJk7ifnXZuRx++WzA+7zpfep9vimW+bfBNogt/750COqNIh0SeHN/nAkIlcR9mfdemxGG /Oh1IP+kQdVHYKbF8SUVs9m+IBfTANH5m6/7N8YwnE+eDa5PQSz598TypJi342SQ+O8qU0Mu PGwpMJV5C0+GPHsV1pEmm86t5iKLJNQq0ZHlA+rPJRYUaxwg/roW1A2h/LYF6e9ln4t3oSA9 hNSvN0WVJiLrsGINIe8pCU9sLcVPj5r1816HACxhL8s3OWDV/nhwUmvUDv96UEOdRImh+Ff6 eGYuhpl+bCJzELZ969GmKlVOt1yhNMT0kU72QuSS6d3gyUbGm6QE9aHGp8HVcP9mYLhWiNLA hyA1Tb31p0QotjIyFTXxB6fk34Hlot3gfNT5cbfFoawE4U771YtOX1HzBqKL6Gut3u3XK2IE EYxIFjvRuNkcT0mHchUbMiMxoUcxP04pbSWI2F1OnetE2CX9dS6sSpBNgt5S0xQbnfFaox0T KRG5PbQVCcNQ/Qwk2oBBmF7KderBkt23zRf12gkz5hKTRAVQtXqtxDJW3sAEzWHMc15L0Z5k VMhGqS3L/py2rg8cMAU4hN46CqjVEoWKS8gWJWB15oCWbJkcVYLv058U8P1sGD47UVXj1RAL 7fA6BSwpqip5Vl5UN8i8I+vz4oq8n839Pw9okPwurFZMkHkQtjbzzvJH0w5e9m76KeQGU/i6 ogZAs1x7UpQzz1xzFitqrkJVkFBmcof8vueGRBmoLVRFqX0QKxltc/akHrO6V0/ZZLkIZhRX X+jw/HWW2P72cRUmIWSR5Q6FgWCt1O5Wl//9YrYwWEPjdw/aXbbMw5VQO4/MGf2Yl8FlSKKG JMTdT0nSH6KStN7foHlju+IwHDlAv3txucRif9uykrbufrOuQIllJGUl/fUCm1YZrQsTChmo 03tvOlegM4N1A+f2tbyANAnkxmfeXOwFdPqtVuecgwYZKshhOJygt1U7d75lTQAQ65t8uQrC sG2GKV2x3DRX5mN+LP20M2FpQ2aUjXcfLdd6NPeMWnW/XjOG1iykwxC+QUVt71OT+h0qMGjp HUe0tcZwC5ntVq+i9jTBvOmvb1Dc5SOTHp4GLciKucAZEDo8tm1xfyN7sRKQ5MNo2XCCot5K uvbpbLlLT9KojekkIGyHrnG7UUuBBbxbxc45iFLqCV/gGOkLYipgmgK8K5rNGwspQLzGMeCm Jv26eFuvRjUmcr8KyphXSZpnZPy3GCdXzKtBy0KRLG9bdRHEQph1HaxtNk7LxKV5V9/CPvRP Go3+GkpPVBe1P+L0rW10RiNTl48COCr4KRT4dScgYTfOI48sOI44R5ZJI2cAUD6OTct2z7fH QeC5GoF/61P/+hfNpMH6Ch54gTJ6H6qWAg1oSrJvlkT/ZZIwZZS9CkisyxuL9vzGyrhM0JEJ +yun8k1/f9ghuwHEVRBcoOz+qdk0cOi+ajRa+O9xS7NDr8dW0ezlClnn3/r73Z+SiysEz4Tc SCosHAc8pidSD+f2Uc6cIg2yBSgs8mHePuAUOLUZwBFwLvW4R6cEz8fp7FraTSQ0yZiIwr7p dludkwvxZWmXpTJLP6kHCUuw1G4LkDtgkPsXS0IGdR5KLQKUi1bB/JREvrw1WOrJehKmiUc7 9nqx/9L2yd9ZHr9ALUVCGJ9mq6nyVxYrJX+6XcV7stXQIq262G2VniwxqPJbhJjk+HFB4jQD r3kndmEWMIkbmhYquecWQskNbI8HA32UuDwmvLcM35o5z+ifYNpQ6mkxAeWVQAqkyM96jYm1 f/3lv1MogMew5tVL7jXPD0Er1CwZV3KaSEci2ENNW3zrzvSpTV1U6yNrgjKPyKU10Vdlmsxq 8hTag6iSKPP7pL4rs1Uqi/uhotuc9rvM8NrpadPZL3+4ns6UZGcaXg1brf3e+wPjm2Xcm4/c emc8DwIKHTK/BDM0t7MCw3aJkaj3huCdeCuu+93jRutkCTfVT1qdfjWpd/LcVMaGAD9xIvvG N13MDT2WsIvod2IZ72T91/slM2kd1+unPZ4JSn24piyzPxlB2NTUaaaycu3XX/4n+0xWiVIj L6oRWI5DhXjAu2w6gSe22p5ApuxbG3ttTtArCQkl0zHsIMDxlz0DDgs+oBwT+ADTvnftMT4e meOHOzS1Q/Mo73YJpWu9487RqaC0ng8pYJcu6TMDtEu6xdsTYrkMkSL7IbaCanx6oMgMEkhW bRzXT4+TvOcX2zxQIsqKparH6slBOmKEz6Np8J6lUTPxrAIDL7uoDLctJxpEgKLhsLP0tZD7 QE4ma+jDlDTQeC77yBwA5bqEpBeVnFM7mI9khWVmd/SjxrhWPKaeORKrg7zo1hFtRIIfuMJ5 i/yQCSDukh1ImfYgjj7oDyDOik5UDfta6JLiBxAGZvdid24XptgOcPUG7BYpRkjBI5A1MG6R fyO0JAzNqE6hVJmjcYI3zMMvQNcMBUqPLMtFZzkF1QfGDfAYbQGR/AqMOWH0yHK8J4HUiXmM PR/9gqC9OQkY3nuBJb4OWBWqPWkKEki41lM0sInOdVAKpBoC/kCohYMskvhEXlF2OfbcR8u1 0UnYSjGCtPgkqG7LojHMOzR+3dM9uQiHBd2eyCq+RSYRVidMGYNtGSx6MOzyBkkdcEj/NmpE js5geKB7zrZX+JP3ZKFr817BHpjuM1TnWNTL32fCjTvaBNfLJogFgxQAPPO2b5noHB2ZGqK4 hYwL4lJIkzSZEsX+U/SONu+sdEB1RyuEWIYk7jIxreODsP0q7JGaShn0FcbRUavWQwdXpZx3 AcnqWakJJHD6BSYu3Bjf+i86vy0glJxfOkQCaEvRZ9Pc0iZmvfUcIDG5pwIts0/c4roZqqTq 2fJKTSNAs2M+fwPIJOEVy80x/TaXi312qFEz0CJL5c0w0hMCDaQS6CQRH8Ozw3sOpSx43Mt1 WxtPRNx05lghnC6wVPooV5rEZWR86+L8JiaxcWmukZkFlMd/aEcc07dvnyFjgtMNHDtjZvCB LWRF4TtCWdmej8sISHn1hyySw/7+gMZCMZYEBYFLrizOGlkkTY/C2yWTg4MwGZuPPGEcAZ0G NPDUdu2p/YN4krpB4nIFw8ZFCGNcjpBizW1sDMxOEaGwnUdqTZ4si8Bnl9RQmt+rqZPO0S+k cbQc2mneMgySkOSXi5beBOmEBvdv34sEPUVEzCV79kQXStyY5dfGjRb3rxkubH8bvCfGzVBB nZNMdnUQkRdx1vg/P3rncHVEzkh9GZ4/+IGbYsvSGTYGN0Ys/Y4mTUam5oBWBHcGdxSglx/7 T+6e0ffQZWB5YGS7uz3k86uvud96GvaH70kNTckrZBRESHDCSYQMXyQ3dLlok6dIXcnRgB1N 21/FS5TxzG8DRmcCbQTJ6IoaY+o9ktPuo7EePgWiDwDcxrd7eN9D9BVD6LNP0TRvPJ7D8cY4 g8FehMA4ywvXB9pgjFFwAlHSjVqQ+XOUqk6kPhl7cweeDo3B5LS+m6Tsyas08esAVwwQxpvj MXv8aD35bMzd/Zkzv0Obqzt8aTDImnc5hMoF8zaKo+1bG6GHDB/o5xCH/jY7gz8UnbpOQZNu ckxcTmK5E8u3JgN4yefwrx+4CgxnK9mpBhZCqGHMWN8RfGJDQjD4LTO4Cy7Dfiq3mzDUeEd2 TLrMeueqcS+vlnJsR3C9Ja7TIyXZeXmkHMFWlCJssGWoQAawAXB5QqN7xhsFM2xrCvHnTJvp ZuQrkyOo9o67552KTqriVOQn07mbu8ZHD/GKMfn3uhOnOdB+8Pb/cp0seCnMJmVxKKkLXm6u tUlNMHjSOSdgojJ2GaGfsCThjjEtCXupvynuz6IkFUBTIjHSWNbYRJSUw3nBPcMvfZvNbBEw h2ZL6oG0Bkjtwx8mdTpD2+6AlEhHJL2iBX4QmxJRIJucmo7rWt+NGm0vB9Vkcnn7+P5GvZFL 3BhE8XaALzElxxotAzel+NzJBTbIk/kcGODjJ6D0CLaGISSB7FuCIYgKkXUA5xPvwBR5JucQ WXJcrMReZJQ1TzF22n/OYYJGy4RtfQ5wwyCwhk8rU75H1ZP+xU6jmjo0LgW5OvLqtU1/7rO8 mTBHnwMocew3chbNZr0FxHu0TCfBN1LN0xVKY4QpYHE/Aw3DJ8onkZRSsoMM1USCo1kDF8Ey 912yCuhLfHWRPeNoH6T0xVyjKQeCZko0z8FFS7RxCWKWY0fhz710fnqyy9TDPtv2iDhKV1K5 DttOt7YPDAADdjuBC9g0bFZi+1jgKZkIDgCEcEqLUnG5JEmG3G/CkgBmSTZesIEbsClWVywS TQSVFOnWDKpGCyiy0dhKz7F7ziLbVoSsXYeX+uQJbQ4HgQBEo67rOXVtGJfoxTVHvMB/3iPY gL0lMiA0iO6QyGbLAqIg49KwpColjX7xVg2BgpIBpi72hawEk+LS9lTYCY5HxVkBKiXnHLUO 5rOZw5VdsIzhbYQ2kqb57L3i6BSbJ7B3KctigFI6LsfEhW5F377ja/PIXNkqGuixXpikdbax EPwnGyw7izdINLIKhFefm61uN0ttmc4saY9RFajnOPKquOZkHLL/RVYn4l4p4r2uA/VbEf4O yXYcDGTPyMb93KjnGVOMkShL9hk5xSzweyKYI0KJ7CojAw7dT9+AVUj9pt4BMITboBGrN8jQ EgXqr4sCiIIjTCa3AoSbw12lazRhYyUiZFHd3SLZy6l1rXiNLAQmbNRZp8Qm7Z5FmLy+FINh qMwWfgFiuVxoS7a+hL7ti+wbVbqNA6NDrXbJgsGmc9EIJAh9RBBOtb8b5yRPsFOpQmzPsIWv nrCQuAJNgCO4ZsEOluMF67vlo5rrddIkKuTAMRuFPcB1sisY2EkwVYmc0D6BZSFDbSJBHcwp /AxsAtkETqm1xLGMdDRCtWxdnfdSlosCsl0Y6Jzn1hzPyVk665vrRY/QQscNmNYb/UydcREW IuQv4B9FpBTldFZCkZuCARZAT9Gkc3QptAAXiU4Z8CuagY5seiPwXe/fe9fvk8waLJpU8CPu dVlvpg5OrjIXKv4JqXLNFrWPFMajoN6cTl5wBIYiPkIyIVaRsbUAaRaSa0PT1pMQAImwPSED VVZMAmOEP3JE3BYvrrG08vxJ+wL1j9gKqr69O+SOYZ05c8a6N7kXZCVaxhSVejgzwEGj7DTf +D60QfLslHWIpYOlNVihPFAYYxyxdC2UBbhJi5BypqgoQpWYNw+jzFV2BW+d6AgcU/EC8m/Z mb8N2lP0U9EYNRyk+QCLVAafMM6j5Em+bD5N/9NGrX/U58Bz2J67Dkk3GYKJsZDFlWcO6TQG 6vyAx+QVrG+jbZU5udTJuJ273Cca4SGqjLZ9cZQWU193V6X5upJqSzkbtdpBrUkmijhTcWAM valKc3koroGKs72JzOS+s74fQLzgzZoGchc4TuOrP5HuCu/fQ77ACIiGyYIlYgscKMDBG9o+ UfUlizLpjZxWXd3mXNO8XJVuynDcRtQk7YKV3ko1pdU90tKPoCKxyyxrpkV14+UPRZMrbxMs 9PcWWmGrcgXRh/lY55b+5ujGAW2jJ10VZd1SGjsZoCCRxokDx/6BEr3sGssqozUIrTdtifpX 3viBdDtAbBDXSr27+gKvwVfFpaK803hH5ZTZWb8hjkapDYHnCPdoqjzvl86nhOLA0XBKHkTn z3BkbpI3Cl68omT6axWJxLHY3Gn6F08GA+isySVMVB4w6HwStfPZOF+sTUXKdWx8NtsmY45+ r4IGAa5JxBGRXK/dTNlep9G86DaTtQ2RZth+rKV9O3fQJ8PJbrGOYDuYzZK6hFcllR72hTcw 92d0khq4T2qgDDHXgBGdA9qmmFSsINNWK+yxNOK9Rfp9QvdBKqEROl+FJ+Ml5aj54iWtjYWR u5Ld4BdPaeuACGUucxQocqV4/AzVhHBXyf+zA7hPtwha0XVfqnxJHD4I4hJwSr9P7bt7WDd8 UGEy9/nr4Pf8puVrCnSAsikZuKTSNaTkKQ29Z1x9YWNryAtF8HSEIkg6WMJVcB7VPaAvAokp JSrIj/dw6SzVXOM19Wigf+FrxifL00JVxu8SQfTz7tHx8abOUBeZPjlQ2JEzNlSnfSXVJvmM mGiaMPGsYFGoaIntlFsfeToa026b/EXBOgslNZ4RwBYOcOYzGTM54aAFpOvo+Ki5Lq9IZFZA 8ruLJcS2Q25DEwyrlr+lJFQ8ifIWeVPEy2QBLNfW6lR8eubH9eOjbqpcdalJl1RKi+fZntgI a/q6jiovngUGWADKi+dVYB9Bs8xgBPMJaFVoLOrSyH9H3BGKCErHvrtDcjirWHVSHc9i62dZ qNjRtxzkSfjUP2281IgTC4eKoCveDS8SGcE9qNUgsEdIiX8aQtMEHooHcK0bfoaT3nyGJKoU wGCiOMulo+TU70yYF7KqGmmyKNsOEg4v9kiryUQ7qWs8AICkGhHweSwZ68wr3zRfbDxQFu+I Tq7aX3W7WtB+h0oEllh8u57+dK71jhBvs+mQJh2PI9sICCG65VGIimtDqMhBFNUH1HxEll4R E8nf5Nj9VfdJL79sltPyULwyorYEUUxeNAaEEB+CMeNWgLLEV7fnMrwcYeECqClt7hTWC0zm gBXRgSE7lzSZj09bJzWR4lkz/k0mSQzKJJybRbwN0SnfgChNiI0LVtEm6lBCz31LoGANPYsl LyDnYiTTzxHeB0oZqECMurTAp3LBeZRvvNWcy8my4usqOMIilteklstOMc0kb4LkNO+NT/MP C4wsMBQo4CABn4h17AeG0AcXDnOW3Lti3DY3SZzBS8zO4A3yJbuIohYSFlt2wrsimR6muMIn bzRmJ/mqVM1oqPKhluZ5rVlrrX2wMzr4s/So0Kk8BB/9ImvTxBoEtP6EErB7eVOljHPEny9y hHWsUkpt5QYttI8EK2S3P/Hg5RMmu0c6IAvGKWPuLaBK4QIM9nkomgnFS6ZpVIQs/jZHsM7x Ep2xKM4Jn8x0EM40ECjkqsMAsT6u1OHTKzDaXM/dp/OyOEeBWtm4fn/qTax14zrSplJStWZc JyJhTKe071tSd6lQS3nBuqi1utXG2oKVNqjj2efYVM1s9RKSBYPSTXSFbU/0KHl0YHxGmA/H OdACHSWc1PacA8nZ5mtol35r+tw7Pa5rF2HorCyozZdR4eNa9Vhe31n2DgkStC7HCJJNh5Z2 iMq2/EGo1rvt+ZQUElcZZftYbWamw/44Q4Lcg3lmPXciqqJzH6cbtmxmVtk+NZvtSaDnJqoD FLEu1X5UVAZHiST6QkAliggUNA7QX3AZ4bI7lsDrCCTWVhRtOxuRWLIzG316AQm5mTVgXIYI OXPz7eY6SbnmQQP/f0SON8JrnHbA4Xgq1ES9UCydlK6S5fF/StG5DByuidzLlahCvpdP4qhZ P++J/j+qV2JZgFGT2DD8FgT5jrE7Ll3msn9jDD/WjnDwLMv4SelcTkPCx2t0WZviPpgJlyul 9nc3q+LWbfn++1mUjlLydBmX3LI0wiX2sbT+JAqgbrbWqB3+9aDWOKlnCZB+xMZDPbEW1gV3 2ny0EBFE2dkuO7kd4Mh79Ku3cOAESKJ7OgJ4fL8Iw0vqMG1RrHYHcxaRRJGg1k66ADJhm4h8 uDgcTNYsOsGSjskq5qSYbUB/UNhglYnCag/NByvn2u+AtiKtN0FHZUEZSkZRWMlEV98pwmEz nGck+qvtp9f0eV7AoSNFCQFli+i8u7QexRFaFBmgkl3ZkypZgMGin/FWySZkIIh4NP0YZ7PF 7+LDuMpWoFp51neiVp59+4QpcXxQP2jRjOljQltuFCNtEJHLEkOjSTHWpOV3+rluL1eCJLHI BcNsgumc1Z2zN6HNhT9w2q3WG+cb8rCKIu678rcKFH4rZ9hGWjBFhITcS6VfekFQgHo0PKcT hnS8gySczyZzAZAwyxGvv6XOIlGJsynvOiHuD9BRG2iAOAP6RwIocAZFwqob+lQyBNFJJWnp DeJ4CSkBzptMLXIoqcUw4g/4HEWCieEIMQLc2kPmLX4b4DEGVoyLCihKwU30YdAkoOeBV6F9 jpwK/ZSiGqjumlCD2QEVNQXAfrJ+cQgbzRDRI/GdxI1ff/mbMbTGOUFPWwun/Ua/efJaFaq1 9E1buaJGKUAv4532QfM9cBB1FWwi8G7Y4VzwxROl6jMmDNLxODUpd8cktfBAiK0YCiBLLcF0 4SSlaVSTxOxvEIbS/W51kEuJltrRlyFfaXFMOBTqyanpvHC3PilGlq0xqNlkonUFSL9A52wM WhhWEmoXWplrwYRwLZhBGa1XmtSFyEdAIC4fCVbvtpXaLbWFqzJPFCVfFlevq9vHo1+kzYzS xNgy35379uTOMm5wHfLZ//2vITonG4l3k8KsgXDVrhbcSpaiAn1ygPuyjgSKB5gtLMp3/S9o U8+sTbdNrNM46Y99NPf/PCjVuvjc3r/AQVh1LhaJALri9Kubfps2R3wndx13xqip1ev1Vj2p NtdAHj6GRe21wBdKfefuM1Pymdrsl0Gs3pgSHCsvGBG2j8ihFFPJEOfd2Px4QSLlhWZyhCu/ EyTSb891lL2SzPsZKa34zT9YV+FvknV19NkQ077N7N+WLOgBElTAqWRgIeqLFplpQDGt9/L6 xhLsOJoZd8ZLgm12ZlvAWrTy/UZRmLF35+IwM+YB04EKhbPPTkD6pk3INtqXZR+3haXqcYsz rKQc57iaQtnxpDFgJFEeVrhh8JJx9wy+wbe+B8/oaiwuv1JOl/gaNUV00QYbHvAYJ5SNEQ5k o6Zp4ongHAqxqThPhtbk0EVsiYMmGEC034OPQf1s4T2PbX88n1InM3T7Wdcva9Wr3fNNxX3i 8HthpKdMfknYD28WtVZk/wVEKfSZTiguDIMb/0EoCPdD2mAy2U5/sXjsOKWiFyR2FRINHEXz xkY+/LYDUvIlSVmarf1cXVpJT4MQzaopLuPC2sQuIsQmtT23tNzYhHKCVshTC5ObZXA8ZmQd FdpxkIkqlV5hgQSMpDuTByrVuQEWpLg/MH2N50shSWByqbOB8fp1RN/AacDFDyhgMz57Y5iz GY6L+jbOCDloc45QoZuLpu6A6XET07fNPVdHZj0VsL18eAnxTtgsG+M9LZ+nBRvRedyLZrqW Nw+c5409ufzSowwiAjcCZ6JWyhJ2ReAeJFI32JCZl66tVnVBsG34xk/IEb4vys7YDMRfC9Ym AwqL+bfN81owymoYVJ5ChAtKA6UeX94WqV00Wrg2VFmiqwYg01HEBWRKxA3XltbyhMnf6IPm nikK5Xy0brfRTedgyu09lUpRm//Fo5+cV2vVajJUFfFETLR0ySm2pFShmVaUc+F5tcHCAl1z sXqIIltO1ADTMU5cwibPnErRyxJmB9tPujGScnH5IxL/4sbfREMl9JLGt7iDPoK/8IMwfalp cVMkDgCHdJcTK1L4L/JgKSf7+SIInD6lH+NHDCSZdUJrLa4F3Sgd2uBvA6xYZhI9VRa62eKU AuYg2XhrJ07FWcsMrXZCDfi0dD8DSUn28WkJfRPezgYN6/LYnUaPZf1D3wSdACTZ3dyodBeI lkA2cdGiCSSirs9s2aRDJjlV9yZoVopi29CNemLmDEe+qpK8KXENvYqRwamCC8KkVprfj85u x8JNN4lw4wWpBHFnMQW2kDA2CaYNXAsUINDGPQewc5n4QRnzbeuW2puYRI53Gyetaq+RNKRK mWn6TT/N0D33tItuo1ld4yxJ5ZPpzulmKL5pPL7BjkLQMCmejavh4DCYmW6F640qfd+yflgV 0QaHDBK4K7BYcImkw8FYYZhwqWMHVYtxjwDq2yttFdQ/oZSf4gRTacXYaNmrelxgMrBIqHk6 5ROz5YoUD6fgguioDlOJmDVuYSw7UUqrmtpuJA0f/rL1HfVbdF237JEhHDYOFOPoNtlIvCK6 29wMPbog0+WzBNTTZw/CErdIPmnk4GsXYJoC8DK8Lyzp+kWzddEt6T/1qvVa45SZVx4g+HkM tc/FF+hlCAqK8zrSqxrxqbPgh/pKoy4+TravVu8tlwK9B7b8d09nI8q7iwNNM4CWyvXzriir hYrtE8uTK4icHJ0ns9nlLTyLhitzcYdQaotzsi53siyvbXr2BdWVRro4b0uM2T0/7rZEi8wX nGxRvJCSjLL0LMOIBTSK7q5bdYNf8Ey0oLHHuOErPnNBwahVJ7BQPl4wu7hbzOIZ7dgSxPk3 HPfMnoHLVPWsKIcvoBLpINJ6uSMHaQW0M5krXUODk/hQDZhX9It14nDbF9dlHeXzW11qN9uu LPnmi/hgRJOZThmpmYe6bGqw6QZTe0lX5fyzXy6M7ZVZu9R69car8Tkb7Xk9QVqMMnlSl1p2 +101M+7SmNoyli733L1Sz43DaJt56nvlFGYWvYNd3RLfrt1tRDKMouuqrm6EistqEX8zOMqp fnNVxijF7QXgIo7viOvdZbHeK1g3belNcoqBbAec1XG58MA4X1KkuyboFJCDah1wE+Wdt+oe bECprG4wvWTjoUE92VNhICuxUSeWW/b/CwAAAP//7F3ddtpIEn6VPuyNfY5N+IvtsGtObCfs Znc2w4HMyeWcNjSgWEiMJIw9V/MOe7v7cvMk+1V1t5BAYCkY27GdC8cWQt1dXf1V1VfVrXkz CJ1BtxOcliqV2ofG8YeLUutvuNoJ+L+270WhmDfHjhedlpQMo7PQkaU39KErvRE+shdPS9/k 4T879Nmb+AFR64z+ivQ1fiS+srHNfI8dTBzPCaNARs61EmEkI1W0oWDrwYmbidsMp7KvTkvT QIUquFalltjrnDXbzZ/2i3Yo18jXtCm9gbhUI8cr2uj2UmiFRdvcZqCYci+cOGHo+J7wh0J6 ot0r2oHtB71mGop2JJckWnvVg+q+mKgwlKNHUPMdTXCrnJIWYGJKADG1AEGQdHF+dHHcKNlL KZyyFz+ooZy5gKfl2zuJS/xkDWrebKJ/cdxrFw+5li5u1JiGzz4N7LXqsQGz+BsGFu+eNRqM gVDbzVTfGQn1DXc/jPDzTARq4kdKtP2grwaiN3ei/tjqhOjLWfh8NGPN4vL8gRJnIvLFyBcw SL6VSSeAZPqRA3uUUilYmrukvz0SvFALtyToaeD7w48ByTu6ncIejgI56UUyiPTCeoiJgNHt 5unWR2/wcJ3aP1jq0p2SyAUIa5YIuQFF29t+CWR3xizXot3JNfzWS/J1Ika2z8u6faci7Wpi C2tYvindq7x6OauRkTVgL8HLycaRr2PlFVa5Xem+AbWBIocjLNytfCtBipnnDJyAfBrfk67o OSP6ry0dVyDsicZKwOCyz4M/pzIaF0XZ7eXTelDDpuX+8KPMVklxpdQ0FKHyBuR0fu6KFHgh EmeHXPTahx3hhALT5wfw2mfeQAU8fcxYCCYKCuN6PiV6ja44yNoRycOgJIXr97EuL1wlA9H3 JxPyv2i+w3CG6cbaZL09PzD/iz7dGbIG6K+mwznziAMEOGpX4MKB02c/mKDjT4s3izmsXQ3d cEcPjyItS1cVbTrXUl+DUS/AYVwS59ZBaC5xtw4qedrNH2Xma/X5EYDZeltOO1UvlRa8Bwft fElN7wwY8yniLNLW7Ayso+f5EVi4vkIWpmhr248wW4FEp3dhidGifcolgTXNWqcPSQlt2zc4 8Q4cxz5yV5TDyPTny+Lc+JCeL8BQO4PksMjHMFIfHAj/Gk6lFFMVOD6cjiH8UlyBee8je+d4 M/xmcgfwTLwIWSrphgfaCUFGzzzePs/eS+SqdLxQyOnURWcv3aczw+QpUBC0k+ltmRjPSE8R 4Ww8h4jSTS/AriaIGGhMImCBcumY5ZGii2998CGcsOkr0mTD4+bNpNi0zL0YlXqtXr8oGX5m Ta7pnvqLREbBjJGLhd1FeKoQdnaQNTwPlLzitP3U6SMdf90Mx3KqiKsXzuC09OtNBf9+jY7f lgAbfjAInd/B4teqR5XKAf8sCR+5bqTZ6Ba/OQ3UUAWBcjkDf1qKSsxDnJYm7xvv37r4Ua2+ f6d/vL1RJTF0XFehpWEJYUfgX+nfuSf8p/jmA22iWxfNThwzt9fNISKVGUZDNw6F+s07LTkA WMdTHwI5B/nh3Cj3J/z51RlEY8F5vPjOcDYR7yuimnG5IirifZX0J74b7uNAvK/h9lrG9bpg MegGubG7bvqHckZjzn/ETZgOoUsZXz5a0/Lx5pb5mSfmnvT49YhS31/XqWol+YQ36HFC8MQw Yc7VTRTMKPHuX/E8IsczcLAOWZXoGpTAbwI3PTBXOg0Eq8IS8JuwiVfimp6BQpKBg1tlOMWn VMLh01epcCShlrGOJvXTqVZqUD/97L8kldZozpy0oFk/bpSr0+ivY56B5tvKcfndNEJly3XT mWA1DGQkRdAkxQ8+Dao16nbkRKR6yW6gQ8jj8nrBL1iC94IbqZT2znHD8sdbpZ+zPZ62M5oF Ckr75x//KWyKt/f+Wh93Yv6zx3ojJ1NXkXNVtNHtB5rdI7C/Yw9+mVu4R7mc3NZADZ0+Vnf/ NteIjZ59UFRMUTmuNM4uzrHgsGzyGmdkjrNHuqMBPkat1JoBdi56bNLAIi54/ZTYfzTkebD+ 5lYv6lHOkpztl2zrsz/nCAv4qG5QqIgwKjWfOUpTci3TNQqFArmJpAKhSxXNFfJnFC1dBs5g pN6EyoXZ9aFqfuhQCBo+DqzZOGtvJ4Jp2ZCt6NPvYfIpX1+02W1m+2UEpUsSfSiyt5qn3Xsn e5cavZO6uwetffB65UcYo07HiVfIIc/sFXLMfoY1WxeQ038EFa0UbTPXNLYKr+4niyhLdeM5 PKnth7LGzfpEyY8QxedErAt/Fh36w0PaBuL04fddw++aU/ESnC/4geDsPeXQ7yLU9TxDU88z 94MrqiNhmgWVItjR8FhZsCfqTn+B+0rZCF3oTv4qObRwAZCVmCDfoSYoqvCpBEOJYeBP+OOh 7Ef4RdIPhO7Ij0hye22dxljCKRdjcHSYkSlyJ4ET3dL9HtftHNDcYdpMQ5Hf9+M8igA5lv1Q J4J7PbSZsUtsTSLv2+R4fDwrEGBlv5c9P67Xj44/Ws65u7km8GOlVq2/4xjcBD552Ggm15V3 +EuPmtmwuWttPGU6uRr75370vHlJDo9m+abg65iUYwZu29V+yRx4+Dsez92pM9U7b4a/X9A+ t9S1PMC6nmdfQ2acgRy9WWE0EsLaCFb33f2oVUuZmzxh+2atMzt2aEA23M5LACU0KiGPPLOw RtY/e8zY0QoeOEOkK8Bmoa4qGROfdXrI6enkKlEvtMqpfotXd6h06bWBmz//+G9X/TZTYfSG C6f+/ON/yGooFyVfixxuEibK4pP+gFqxTz8QyF9oUDGQYx6vk8aBboG64PpzwAUDEqOYuc9s BLI3xnlbxj0phjI4BMRwjp4pCN2FladT5h4FjABHpDchoeT3TMfRh74MlU4V3zl6GqTJM1Pv pTuXt6FJ+whsVxojc3ogPnzuCoBnt1sWX8a4je6kRHUIkoR6c6nG8trxZwHkVFZldA13AJ29 vkMELN1O+WhU10Ho0ruFLY1mnEn/DpP5FFW59Q9MO/L3GL+eOSpnWCgPTdViKlZUMFH7ANdk SExPstzQKk3KN1kYv91pIlvMkMwz5hrZH6KdyrSZDfQYU+u8LCQ8pIT6CltmLWGRyYhKkXKV 9lBf+3UfdtohzYhIOYzMIKHOYlPYWXq3MPbn7pPgdA3uYMYZfuSDsjbY7bV7+7HHYMo6jUOR XDB6iaQ7H4sfPoHoz5ArhXrbCTBdX3S3q9f9YkLNXCQnlIAKnQ5oSn1avNgH2BZ7uRiKXmIv VlF0bR3kamJBghRuYD8bhRZLQUNmWsDL2kGLBPpORTXsSZOMO/tQCSCL5MIY0herIvISdTML 7aN1tfR4qsHV9U28jqBh2fPIbTCGZi3MNfO4poIcPqk2DyZg8HUNuR6q+g7H8UlCnEZ+LwH7 A2SbPIaFhHOvfW5UmRm3fx32ZYiYgwEvopABpsPH4kMs4HiU1NZlVxB0OPZRQIA74kQmLbBE QIeGUcOFOhPUUWDlxYbm6blMz8tvW3GP4Znzzije0K3rbgpCTKrqZbmi4OjuioLG25Py0aKi oNaolGtvN5QU1O+zpKDoGs4T5+WL7ApKOWrZpfS6RFInoWwR2sQi3ZOwZdqZI688QU8kPUTD c8B0kSkx2HXAMY6dm73L+EEwmcSgABL77OqTU46YyXNvExFTKmCK5qBZ0Dx77gTIqBVDlAIU hRuGhCObWMJRMr5CwoxZ2yXgN8HBo038uLtzllIRRIt37SAvrIvF94MXbWINLagdy731Huga z7O3X5wYKooN30PwFRVL69PCpkJr2bU3RbXWZ2PtSDruOowlFrTdeyYuLQfkOuMEEcD94F2A egXHi0IvE6yXbIewLM6GqIUkFiBKylEOdBAlXVqqZjcqrT0diSQf/1UMrCeLCISepQN+Qg14 YCi+dEE1jIAAl6bknJZ1TIjCuaLnEvRkEBLUfY0uZoIzhrHzhb778KQsfnKu1NyxZAhLhDfz Mc0PYHNDf0XOEOOKkDcIi8QeSoTIhkU50BtLn4P4UmP4QZ3VDVRv62dN1WiCHxkE7MpIxBUw uMm1m1yu4McCbMHYgIRUi59CElKTNJtnyQTaFMKhqmbH6MZ8EWlKKbMYBuoEYEODWVFMAkBQ V5KY1CGsARukwZBzMJBCelTkRDBgMdtBT1hZTGURMwSrLRAbZPZdW2AzGKV5omfvgaRmNY3L JC1LSZFUY8RhPgmzDcDDkXpEQi7gn/FOkWpHC6iLAmc0glEhKhb5NiJfaOIyrQG1ygC32mQK IHbhDD6EjWBaY6JwQB3baysEqNs88L0RLHWgpn7Ax7mwBYnGgT8bjddyR8AQq/eWWZduNLbf iTkiSiRTKTaET/cnSdLn4VFmO9pfMNbMSscs1MuSJRSV5IW9MeQCUS215WfTpBMxi5zYAQbq PDLFMIZWcm9BZOtS+BpzSpTRCLE/SSKnLKRx37DeKGhb4ZxgG55i4qKojX7Sm6E2kj/Hd5M/ tVqN2R67n6TeeFc+2cT+4MTC+9tQUjTCe3z25wnmlIvqc55NOg8RSmcD3yc+9zSuaJlLOqUX 2ETcNeIHwjSCLJMM0fexZWYwsuGcsefEy7C53rkNzkX5fH8WKVtWB2KMmndIBNA7o1w9nc0C hL5IHdpiZXBOYgT49xWOW+rZzJ+mxdQN7VeDbx3nqMnJ5wQ1YzvsPOfpLxEGsERDfY4Ln7gC k/SLJ69hqGkn9Ur6keLoeCLO2IWiWUQxGJ3Tglr2IXbj2LoxM5JLjImPAUWX0Gu6P2X50zT6 j7oCFvlwGmDSaY2tcsxvWNsM6tNOFpcyWPPM7uzy1FM0oM/riZUgPq+Hz+Hh+UuemEPUKnJD xK4GE+xlhKesk8llnNQF1TELUFEdA8VkXDOC//mYhEEimjsTczzqeeRws1cfAl8dNKaXQoIa pUPNyHfd67Q3ZOUZs3BL82uzi2dSiLEUp6KuRB/ChaWgo4+n6FfZIra8NVFUpb1uJ3fU+oIV wePeOXTvPnwSxDBSun2gXJwmQselxTO5xEzGlo3T/AlyJPENqu6ksAg583QoyweyLZu+M01R YCXyJ4bUu4N9SAa6Wcr4w0/KmiX9PNYVztTuI4LjA/yM9SRawhoVrRAxZj+bVWZ5BLJ6hh3j GnWbmcNlT5gydX3UB5XraeC1Rm6Z54gdHpzOTch8znk/qk+KT0d8rmvBMmeoKsW5SPrIHEvD JFxwAqrvWDZ60/75+VH9CCGlKYIoGg+mw5TcRdjkL5r9ssXzf1yLR/6adcNYL2wdzsJ/Zn/Z MDMBVT3y6zwmlCNG3ikOXPRiXHaGtT8PLziD9qLsOJNh8CzYrrAxWMORGSC33r712Dik0h62 9a+XpnTnWp1m71aK341mJOZnY/V4rlLqle01GPPq0e4mSts+qHi4XQoJKRlB5F4LrxsS1r0E 6P43JNRTiyqPgmmUrFTr7Xb7nlAyX3WUReRUBxJqtv1izPbAflKRQGApEbUy24O4lcpyYG85 8sEnQD0TC4Pw8ABoKWglG023pCS9Ai5GoInx5MMPgvyADg65cxf8agu7khj4nsvUidqbduDp dOp3m+sXpIhf2cimVE/HT2T6OWQPHZzeFUlPgQmh/BediGVzIvpNTnqLzZIqZtqcXqKEffdL r9VrL28Tz+zVgq/cfZ+y4SD5dqjwQCiJMjxmQOwRGKH4+qWbPqGcIMCEt8b9wi3Wv/+gt0TQ JGLI2ICnS6YRmMvbxfZKs19Ct6TpR51DoyvaY3ud1VzvyEtOYHzUJBHNTG3QNCRl/W2GUolL hVJ2TTRqIptXG23riYi+BrwH9GI8XVdCT1hMDfnDmPPFfKdm6dXgZrzSj3EuJaYcJQq7h4On CFGtlDJD1bQmompkSQvDyMcrFOgiaWLkTKjaZIFYn9OApSnfBWLF27W0laH3P9KGbapARpsD 2k2C9QMO0HLGGttI8bvti6P68Uk6tHrhat9iDY+thGU1SJbx/MllugycJxIfPGV6544VuxXy SWNl1ifyKvUVMG8xEBmOgM8sxk1mhxtpiM36GPIKRi6e6iU9CV+nFapsKJ8126I/m7PJFgtP EFt+SScV6NQnWPOkH7FkMHieqJ6MtyASxfcEoRF6kadXD+m9tZIvuAp1TpkjM36XKYRs8hWp fr90YPqC5R9SBpXyqki10nsF7RZBST7QBEYBtQ1A+7jmii0AFf3gIrDI7nv5UaDhXqY8T0FW mhnOx3kUpAM2ll6d3F161ai/paN7beVV7bi+8SRfPpr6fk/y3TKcv7dqrMzgs0hIXJz0XGM/ zHpKwVQO9igPt1OAkY1a1fSCXuOS3y/CF+lgdrQuukTGMeQT3uPwTQ91PQuWxGSge+30a7Xz g8Kjp4vSgc/x0VHjYz15FHCsCAvE+bd0RzNP/B2VU06fONxcL5y/8g//1bVnA+lcFWoiNutl /W3jpKFPRcoNf2tPJoZtQl1X9uxRiddyVxLguVMhZGseTGGeDuUS/Td5+M/UDlfIqMWlcHzA 0XI7j6oS2dJYkUW6j9+pJy1b/o8AhnbKcpEhykqYmUEwBeaGqgNB1WPh9xHX8Mk4mBkKc1bJ NnOyAR5g8/ZMCcHdYbbf1C3gidiBgWei2C2xNYO6ws/N6oluHIev9CPwspRBIEeLdp/ReRlU AJlG1zz4UzQzncc2MuAOg8N2l2BhgRgrCkgdNPnq9Ew2Go2jDxdJAEpaQv1oevfAImxq/br8 L6XPVhQhqkE7mMDE2QSpsuEePqcTCxIpzjEOIlFBl16dwQ6tPeQMkTO9w76UeCnBEQHbHK9h QLVTvm/w6+rXf4N3miVbONEtTEc9Og5tflqqVt9VUA4P9MXvRycNfpkExDr6Nw4mR1f9Ka43 qnwLM/n0lTpXJkCrI3+y+NhVQ4zdfqqHjVeH1Cr0eD2m+M/RLMIQISndHz6BCyeyTWUf72Og r7Ag2KvrjPj3gd//Ow6zxqPoRSAdByddn5bqNRYZZkdPDE/ppT+45V/wFSTLvKj1fwEAAAD/ /wMAUEsDBBQABgAIAAAAIQC+Ne2AugIAAPYIAAAQAAAAd29yZC9oZWFkZXIxLnhtbKRWy27b MBC8F+g/EDwWsCU5TpoIkQI3VtIADWLE7q0XRqIsIRRJkLQV3/oP/cN+SUm9Ylmym8QXS1hx Z2dnZwlfXr1kBKyxkCmjHnSGNgSYhixK6dKDPxc3g3MIpEI0QoRR7MENlvDK//zpMneTSACd TaWb89CDiVLctSwZJjhDcpiloWCSxWoYssxicZyG2MqZiKyR7djFGxcsxFLqUteIrpGEFVzW RWMcU10rZiJDSg6ZWFoZEs8rPtDoHKn0KSWp2mhs+6yGYR5cCepWhAYNIZPiloSqR50hOl30 1C0zpyxcZZiqoqIlMNEcGJVJyl/b+CiabjGpKa0PNbHOSH0u5864U69p+S0zmAqU61G8Anbg esSIyqSMlDqY+b5OdRfRsQ81U03EQDQc3kKhXbNmkqGUNjAfk2ZbXL0Mx/j7VrAVb+jw9Di0 O/rcYJmdfAcz+6zYvO3W5LsAOqs7TxDHEGShe7ekTKAnohnlzhgYR0Jf3xMc5K6+X6JHD9r2 5Nw5+aZXtArN9MrZdmCPnJOLJjjFMVoR1f0y2woVyDNRPOZqQ7CGXCPiwe8YRVhAy7+0dO3y hOitZ3KVuXNcyVGoaXOBJRZrDP0BMNmqwChq7EeISXSdIPO9eltsuMZ6wkvtwJLFfxBSKpVY 4Jc9XMBschsA8OsLuA8eb4Obh8f7yaLg1yQewVNijgRSuJeq0fvi63gytYtJilJNymaCsbjq rYwpf3SsYphGvSRaHjkwMzBoMTDTL9xRz37LPHWoBV0HD9tvS47KXHyP/fLCVvpK1cAoVlhb fTS2jzTm9cM9cE7B399/dh2q710WB8IYURUOlBwTMldIKFNTL1zdYKvrQlD/x7ylnZauFy0o R3QQq3+hdtk2ZHYspvzxyekOl+Zsl/ieYkaeoIVSukH/6n8t/j8AAAD//wMAUEsDBBQABgAI AAAAIQCHOb/HwgEAAJQFAAARAAAAd29yZC9lbmRub3Rlcy54bWyklG1PwyAQx9+b+B0a3m9Q Mx/SrDPGReNbHz4AUroSyx0BurpvL+3abtplUfeGUuB+9z+Ou/ntpy6jtbROIaQknjISSRCY KVil5O31YXJDIuc5ZLxEkCnZSEduF+dn8zqRkAF66aKAAJfURqSk8N4klDpRSM3dVCth0WHu pwI1xTxXQtIabUYvWMzambEopHPB3z2HNXekw+kxDY2E4CtHq7l3U7Qrqrn9qMwk0A336l2V ym8Cm131GExJZSHpBE0GQY1JshXUfXoLO4rigN+t5RJFpSX41iO1sgwaEFyhzC6M/9JCiEUv aX0siLUu+3O1iWcjf0PIv8nB0vI6pGIHHOEOXEa2NdLl9h6a/O6y+pMYs2PBdBlpEIOG30j4 7rNXormCAfO/q9m/3FARp7zvR4uVGeQYdRrtCT4GVlOYf1DGrtrK2w/N/QkwKt2XghtJIi2S pxWg5e9lUFTHs6h5kWSxaxZRnfiNCZtOGm65R0vCkspSMonbcyb8hmaUPaeEsftZfHl33Zxo l5Yy51Xp93Yasm2GAUcXc9quhdG0865NHRIhELyCqq3al5+C2Cl6DpKPaAtq+3a6+AIAAP// AwBQSwMEFAAGAAgAAAAhAGFqFW7CAQAAmgUAABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWyklMlu gzAQQO+V+g/I98SmShehkKpq1KrXLh/gGhOs4BnLNqH5+xoSSFqiqE0uLMZ+88bDeHr/pcto Ja1TCCmJx4xEEgRmChYp+Xh/Gt2RyHkOGS8RZErW0pH72eXFtE5yRA/opYsCA1xSG5GSwnuT UOpEITV3Y62ERYe5HwvUFPNcCUlrtBm9YjFrn4xFIZ0LAR85rLgjW5we0tBICLFytJp7N0a7 oJrbZWVGgW64V5+qVH4d2Oymw2BKKgvJVmjUCzVLko3Q9tatsIMsDsTdrJyjqLQE30akVpbB AcEVyuzSOJUWUiw6pdWxJFa67ObVJp4M4vUp/6UGc8vrUIodcIA7sBnZZpEuN/vQ1HdX1d/E mB1LZluRBtE7/EXhZ8zORHMFPea0rdnf3NAS5/zfzxYr0+sYdR7tBZY9q+nMf5ixm7bz9lNz /wIMWvet4EaSSIvkZQFo+WcZjOp4EjV/JJntnRZRnfi1CV+dNNxyj5aEIZWlZBS3E014DcdR 9poSxh4n8fXDbTOjHZrLnFel3/vSoG1z6XF0NqXtWLia9rk7qA5qCASvoGob9+23EjvH6CD5 mF0Q7lTd7BsAAP//AwBQSwMEFAAGAAgAAAAhAFy1fCj8AQAAJgYAABAAAAB3b3JkL2Zvb3Rl cjEueG1spJTfb5swEMffJ+1/QH4HTJt2KyqpqtBukTY1WtK3vLhgAqp/yTaw/Pez+ZVkpFXS vmDk833ue3c+3979pcSpsFQFZxEIPAgczBKeFmwTgefVo/sdOEojliLCGY7AFitwN/365bYO My0d481UWIskArnWIvR9leSYIuXRIpFc8Ux7Cac+z7IiwX7NZepfwAA2f0LyBCtlQs0Qq5AC HY6OaVxgZmJlXFKklcflxqdIvpbCNXSBdPFSkEJvDRte9xgegVKysBPkDoKsS9gK6pbeQ46y OBK39Yx5UlLMdBPRl5gYDZypvBC7ND5KMynmvaTqvSQqSvpztQgmo3hDyqf0IJaoNq3YAUe4 I8VIWydK2jrY/u66+j8xgO8l03XEIgYNp0g4jNkroahgA+ZjpdkvrhmGz9zvH5KXYpAjis/R 5ux1YNmZPEMZvG4mbz81dRZgNLrLHAkMHJqE8w3jEr0Qo6gOJo69kWBq3gnh1KF5X9I/EYDw AV4Elzeg31qYkRttxjhDJdFjy2JvqyEvZLMs9ZZgg6wQicAj5xpL4FuLbA8QxDa9OZPu7Ke1 +p3ZrKI9Jo+qOpVTh3o6t1Tdshu/nmiF33yb3MewKckpuixo9eyu1rOn3+03uFr/Wq4nl1dv RTmo5jm6H7z4aXZAtVVp8jCv/PQfAAAA//8DAFBLAwQUAAYACAAAACEA8WzePcsDAAD0CwAA EAAAAHdvcmQvZm9vdGVyMi54bWzMVtty2zYQfe9M/wHD51oXx01jTqRMY7epZ9oZT5w0zyAI iohJLAYARctfnwPwYslyFEd5iR5EXHbPXs5igddv7uqKraV1ivQimU9mCZNaUK70apF8/PD3 yauEOc91zivScpFspEveLH/95XWbFt4yaGuXtkYsktJ7k06nTpSy5m5SK2HJUeEnguopFYUS ctqSzaens/ksjowlIZ2DqQuu19wlPVy9j0ZGatgqyNbcuwnZ1bTm9rYxJ0A33KtMVcpvgD17 OcDQImmsTnuHTkaHgkraOdR/Bg27F8UTdjvNSxJNLbWPFqdWVvCBtCuVeQjjWDSEWA4urQ8F sa6rQa4187M9e2PIz+Hg0vIWVDwA7sE9kYy8U6qrLg+B3wdWHyPOZ4eC6RkJEKMPz3Fh1+bg Sc2VHmGOS812cnEYfqS+31lqzOiOUT+GdqVvR6xwJr/Ds9nLePK2Q3PfBbB3dG9KbmTCapFe rTRZnlXwqJ2fsVCRyRJ9wmdV/7m2/eATa9N2kZyfn75IMPQbA6X8jifTIPBZYG3Nq0UicMKk 7VYB8y/fUONHhULdyfxhk+h20JvhF4ALZZ1/TzAVpxXfnsXNC6qaGp1v3N9Z0PTPW/S+flvT /8MMfk5jZGNI76zKg/MrfIEB40OAo+wggr7Zpui4+XsAz/6anc5fnAdv49I1mtC4GNNlOxuC a39j0OW+mqPgUS/sRVQVvXvicMK9eItTh0sgKpGBLzH9oTVXILdN3f0iOYsDwwW4iukSVBG8 5Y2njoVKFoGdo3Qz8p7qY7WtWpVHmg5Z24lf/MdjnfbRgMbf/wihP6rSweTT+xE1AsVRx0NI 7LN4H+QuZcGbym9VRL9zvbUUSDOdAQd2wBmEMom7MhIVy6UvC3ePrUjP/FWgDL7FHXx7BDuY 3qvDHiKLeNmFi9+vASJbyz+9x/HFrZjGs9JZC85+08YB1PBESEOYiM1Y6aRdy2TJbqiWjCzj VcWoYL6UDLeotIpXjHvP8SjJmSdsKMcqxZUjHd41XoZLHLIblknmmuyzFD4IXn34yASZTWR5 wq4g3YiScSa4kx1Mq2AMWkrnSgApxyhaDgtrlTewnffPhAnbyUHId6RtyPYWncPSDgHD4k9Y EAfIWt70ORsSiXxIxzR5Bu7WIfOBqQYZfUwaqpcp75BSFFGO3JrGGnLyN5bhBlAjgIsIVuLV kTciVFuAimVgmeHWhynEQQ0HRlYFqoJUq3wZLpPgADpYSVbddztQAPuTJwiLR7nr/OgQYdZd bT/9ue7qDf94sy+/AAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA 0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX 7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLX cduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0 NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmv Z4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t 3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq 4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf 46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/ RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJn Js6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGa SwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJ wmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+ VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkv I7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHa l1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4 kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCH Qb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNh Ux8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZ fDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA 2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp 2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQW AizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETs Y3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6V shvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4Vp CCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QO CRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9E rNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/ sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vw PWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+f MCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEAbybbhi48AAAYFQEA FQAAAHdvcmQvbWVkaWEvaW1hZ2U1LmVtZtSdD3wcZZ3/J2lTNtmkXZqmSaBq0FYDRC+FVAOE MrBXiBhxxRYWr/4ISnHRKFEaXTXq+qOVqBXDn8IqVQMnmINyrkC4KDldlUrQykV/VnNade+w GrRqFHvmvL7k9/7M7ITpsNkZ0iT0ntfr0+/M8+fzfOY7z/eZZ2Zn0hLDMLrAcrAInFXKvjLz KRwzDPM0w2jY8NrzDaPEqKspMR46zjAWOxUcW0G9JYZxPSQtcLjTo49WGft3hQwIjCbQAKA7 tcQsMVaxHQGlkexP1W1nHqqbBQ8C1W02S616dr+pc15kLjYqKVN6oVk2vf0C0zBWkBcCkvF2 SEOmUWqy3QLUD8Z4XP+QPvXNnnNUzw3lO/XYfDpklixazUZdPt86PNMwhowa8LYSo6RtTQ3H EqHc1mcYJ7EtDW8G0qljE4dgGKmzLePZFu/loBWovqySY5W7zM561r9ryHH6cbbL6OhS8tXn A6Aa/AvQ+VVfsXCsJBYeWOnU57SmnG2KUy6957KfT6npbXE0AqdfnbNtIAl0zubL7+mSGiNd UtjvLs0L7uNb8at8/Bms4+NUfawkVT+3Pu6nD/nZ8XEH2yZwxuzj9K8049i2i01O8TlOG7Jm HOd3Gtcb95Zcz/B79jg/an8vt+PGlnTkv85Y1OG8DNQBjTl3cuooX77XWNT2WSAETgQR0MD8 lCDjlfn95vx+nP0W4KSn82kJGesqEqHWii7QDXpC6yqSoWbgcIgzCWcxjlXUr6NtHRx1cK2C swFocNJ0Wl/Mo68zgL4t8CTgTMCdoI8t9NXp0idOP30d1G+nbTsc7XB1wBkroC/l0dcfQN9O eNJwpuFO08dO+up36ROnn75e6idpm4QjCVcvnKkC+jIefdkA+vbAMwrnKNyj9LGHvrIufeL0 07eb+oO0HYRjEK7dcGYK6Mt59E0G0HcInik4p+Ceoo9D9DXp0idOP337qT9O23E4xuHaD2eu gL5I+Mj4aMjvFxvba8KJUGO4C3SDntCacDLUAJz4EKefvkrqh2gbgiMEVyWcEeCND9OjLxZA 3yZ44nDG4Y7Txyb6irn0idNPXxv1W2nbCkcrXG1wmgX0dXv0pQLo2w5PH5x9cPfRx3b6Srn0 idNPXxf1E7RNwJGAqwvO7gL6Bjz6MgH0DcEzDOcw3MP0MURfGZc+cfrp20X9NG3TcKTh2gXn QAF9Yx59uQD6DsAzAecE3BP0cYC+ci594vTTt5f6o7QdhWMUrr1wjhXQpwtLggl7emzn94vF R01lIlRX2QW6QU+opjIZigCHQ5x++g6jbwp9U+ibQt9htBnweuOj2aPPDKBvAzzt6GtHXzv6 NqDNdOkTp5++Juo30rYRjka4muBsLqCv06OvO4C+HniScCbhTtJHD311u/SJ00/fZurHaRuH Iw7XZjg7C+jr9+gbCKDvLngG4RyEe5A+7qKvAZc+cfrp20H9Ptr2wdEH1w44+wvoy3r0jQXQ tw+ecTjH4R6nj330NebSJ04/fSPUH6btMBzDcI3AmS2gb9Kjz6iy46VYfJRVJUKhqi7QDXpC ZVWoAU58iNNP30H0TaBvAn0T6DuItskC+hryehzu5gD61qGvFX2t6GtF3zq0Nbv0idNP3yrq 19G2Do46uFbB2QDO9q7/PPo6A+jbAk8CzgTcCfrYQl+dLn2xAPo6qN9O23Y42uHqgDNWQF/K o68/gL6d8KThTMOdpo+d9NXv0idOP//1Uj9J2yQcSbh64UwV0Jfx6MsG0LcHnlE4R+EepY89 9JV16ROnn77d1B+k7SAcg3DthjNTQF/Oo28ygL5D8EzBOQX3FH0coq9Jlz5x+unbT/1x2o7D MQ7XfjhzBfRFlh55fWvI7xeL3zVLWf8tZf23lLl/Keu/paz/gBNj4vTTV0n9EG1DcITgqoQz As72xIfp0RcLoG8TPHE443DH6WMTfcVc+sTpp6+N+q20bYWjFa42OM0C+ro9+lIB9G2Hpw/O Prj76GM7faVc+sTpp6+L+gnaJuBIwNUFZ3cBfQMefZkA+obgGYZzGO5h+hiir4xLnzj99O2i fpq2aTjScO2Cc6CAvjGPvlwAfQfgmYBzAu4J+jhAXzmXPnH66dtL/VHajsIxCtdeOMcK6NOD t4R7/ZffLxYfNctY/y1j/beMuX8Z679lrP+AEx/i9NN3GH1T6JtC3xT6DqPNgNcbH80efWYA fRvgaUdfO/ra0bcBbaZLnzj99DVRv5G2jXA0wtUEZ3MBfZ0efd0B9PXAk4QzCXeSPnroq9ul T5x++jZTP07bOBxxuDbD2VlAX79H30AAfXfBMwjnINyD9HEXfQ249InTT98O6vfRtg+OPrh2 wNlfQF/Wo28sgL598IzDOQ73OH3so68xlz5x+ukbof4wbYfhGIZrBM5sAX2THn166JYgXorF R1mE9V+kCzD3R1j/RVADnPgQp5++g+ibQN8E+ibQdxBtkwX0NeT1ONzNAfStQ18r+lrR14q+ dWhrdukTp5++VdSvo20dHHVwrYKzAXjjN+bR1xlA3xZ4EnAm4E7Qxxb66nTpE6efvg7qt9O2 HY52uDrgjBXQl/Lo6w+gbyc8aTjTcKfpYyd99bv0idNPXy/1k7RNwpGEqxfOVAF9GY++bAB9 e+AZhXMU7lH62ENfWZc+cfrp2039QdoOwjEI1244MwX05Tz6JgPoOwTPFJxTcE/RxyH6mnTp E6efvv3UH6ftOBzjcO2HM1dAX+T4I69vDfn9YvG75njWf8ez/jueuf941n/Hs/4DToyJ009f JfVDtA3BEYKrEs4I8MaH6dEXC6BvEzxxOONwx+ljE33FXPrE6aevjfqttG2FoxWuNjjNAvq6 PfpSAfRth6cPzj64++hjO32lXPrE6aevi/oJ2ibgSMDVBWd3AX0DHn2ZAPqG4BmGcxjuYfoY oq+MS584/fTton6atmk40nDtgnOggL4xj75cAH0H4JmAcwLuCfo4QF85lz5x+unbS/1R2o7C MQrXXjjHCujTD+QJrmfTYzu/Xyw+apaz/lvO+m85c/9y1n/Lk6EIcDjE6afvMPqm0DeFvin0 HUabAa83Ppo9+swA+jbA046+dvS1o28D2kyXPnH66WuifiNtG+FohKsJzuYC+jo9+roD6OuB JwlnEu4kffTQV7dLnzj99G2mfpy2cTjicG2Gs7OAvn6PvoEA+u6CZxDOQbgH6eMu+hpw6ROn n74d1O+jbR8cfXDtgLO/gL6sR99YAH374BmHcxzucfrYR19jLn3i9NM3Qv1h2g7DMQzXCJzZ AvomPfr0Y2yCeCkWH2XVrP+qWf9VM/dXs/6rRg1w4kOcfvoOom8CfRPom0DfQbRNFtDXkNfj cDcH0LcOfa3oa0VfK/rWoa3ZpU+cfvpWUb+OtnVw1MG1Cs4G4I3fmEdfZwB9W+BJwJmAO0Ef W+ir06VPnH76OqjfTtt2ONrh6oAzVkBfyqOvP4C+nfCk4UzDnaaPnfTV79InTj99vdRP0jYJ RxKuXjhTBfRlPPqyAfTtgWcUzlG4R+ljD31lXfrE6advN/UHaTsIxyBcu+HMFNCX8+ibDKDv EDxTcE7BPUUfh+hr0qVPnH769lN/nLbjcIzDtR/OXAF9kRVHXt8a8vvF4nfNCtZ/K1j/rWDu X8H6bwXrP+DEmDj99FVSP0TbEBwhuCrhjABvfJgefbEA+jbBE4czDnecPjbRV8ylT5x++tqo 30rbVjha4WqD0yygr9ujLxVA33Z4+uDsg7uPPrbTV8qlT5x++rqon6BtAo4EXF1wdhfQN+DR lwmgbwieYTiH4R6mjyH6yrj0idNP3y7qp2mbhiMN1y44BwroG/PoywXQdwCeCTgn4J6gjwP0 lXPpE6efvr3UH6XtKByjcO2Fc6yAPl71O3L9l98vFh81Naz/alj/1TD317D+q2H9B5z4EKef vsPom0LfFPqm0HcYbQa83vho9ugzA+jbAE87+trR146+DWgzXfrE6aevifqNtG2EoxGuJjib C+jr9OjrDqCvB54knEm4k/TRQ1/dLn3i9NO3mfpx2sbhiMO1Gc7OAvr6PfoGAui7C55BOAfh HqSPu+hrwKVPnH76dlC/j7Z9cPTBtQPO/gL6sh59YwH07YNnHM5xuMfpYx99jbn0idNP3wj1 h2k7DMcwXCNwZgvom/ToM1YGWP+tZP23kvXfSub+laz/VqIGOPEhTj99B9E3gb4J9E2g7yDa Jgvoa8jrcbibA+hbh75W9LWirxV969DW7NInTj99q6hfR9s6OOrgWgVnA/DGb8yjrzOAvi3w JOBMwJ2gjy301enSJ04/fR3Ub6dtOxztcHXAGSugL+XR1x9A30540nCm4U7Tx0766nfpE6ef vl7qJ2mbhCMJVy+cqQL6Mh592QD69sAzCuco3KP0sYe+si594vTTt5v6g7QdhGMQrt1wZgro y3n0TQbQdwieKTin4J6ij0P0NenSJ04/ffupP07bcTjG4doPZ66Avkjtkde3hvx+sevbmlrW f7Ws/2qZ+2tZ/9Wy/gOvNOx3bsXpp6+S+iHahuAIwVUJZwR448P06IsF0LcJnjiccbjj9LGJ vmIufeL009dG/VbatsLRClcbnGYBfd0efakA+rbD0wdnH9x99LGdvlIufeL009dF/QRtE3Ak 4OqCs7uAvgGPvkwAfUPwDMM5DPcwfQzRV8alT5x++nZRP03bNBxpuHbBOVBA35hHXy6AvgPw TMA5AfcEfRygr5xLnzj99O2l/ihtR+EYhWsvnGMF9Onl80TI9fwvv18sPmrqWP/Vsf6rY+6v Y/1Xx/oPOPEhTj99h9E3hb4p9E2h7zDaDHi98dGc1+NwmwH0bYCnHX3t6GtH3wa0mS594vTT 10T9Rto2wtEIVxOczQX0dXr0dQfQ1wNPEs4k3En66KGvbpc+cfrp20z9OG3jcMTh2gxnZwF9 /R59AwH03QXPIJyDcA/Sx130NeDSJ04/fTuo30fbPjj64NoBZ38BfVmPvrEA+vbBMw7nONzj 9LGPvsZc+sTpp2+E+sO0HYZjGK4ROLMF9E169Bn1AdZ/9az/6ln/1TP317P+q0cNcMawOP30 HUTfBPom0DeBvoNomyygryGvx+FuDqBvHfpa0deKvlb0rUNbs0ufOP30raJ+HW3r4KiDaxWc DcAbvzGPvs4A+rbAk4AzAXeCPrbQV6dLnzj99HVQv5227XC0w9UBZ6yAvpRHX38AfTvhScOZ hjtNHzvpq9+lT5x++nqpn6RtEo4kXL1wpgroy3j0ZQPo2wPPKJyjcI/Sxx76yrr0idNP327q D9J2EI5BuHbDmSmgL+fRNxlA3yF4puCcgnuKPg7R16RLnzj99O2n/jhtx+EYh2s/nLkC+iIn HHl9a8jvx1nLtQAnub+PWnMC678TWP+dwNx/Auu/E1j/ASfGxOmnr5L6IdqG4AjBVQlnBHjj w/ToiwXQtwmeOJxxuOP0sYm+Yi594vTT10b9Vtq2wtEKVxucZgF93R59qQD6tsPTB2cf3H30 sZ2+Ui594vTT10X9BG0TcCTg6oKzu4C+AY++TAB9Q/AMwzkM9zB9DNFXxqVPnH76dlE/Tds0 HGm4dsE54NLXxsAKgXMA070xALaD+0oM42NYHnEbvAZufQ+7Jr+Nmf5O9bhj+DvVIb6OvbHk 8vn5bvIovwV+KU68GR9fgS0FsXCqNFI/Web4WH51tuXv1fwjsHmuZTzb4mgEzrk6n+0U2Ars 71RLFnWyvRHom1OdczvtjRrGN88zjEex3z7v/NMfjb6/7tvnvat5NPrC93/jvLtuHo3+Lvrw eaFzRqOJjUPUG6XeQ9h8u5KSRYsWlXxkhVmSikC42CZ9ejVWQIWmknx6Zlt6nePTtnucncW+ 9J0IIiDFPBtZYhiXsW1zskFy5kK1z9U1L/l13dolcbblByc5dRaRcVx95ZLq+p+WhervLSvG ZdRnylL1kSXOHOjEyHo46sANnLc3YtPYK7Fu7c4xkR3onOk8bQNJ4HxPbLLdApxvgx9nW2nG 74nz39RTZcZviNMljcbD+rqd8+X9Vl4+FYqdK1rOy3fxX4FXsaBvtq/A6lym6lOlmfDzEQvr GNuKhTbsQ+dVb2mzxvz4w2dZMWD+3zYrJm7rXW/FiGGsp963qZ9vtwCxEOObOr9YyIYzZY+G 7y0rFgsj4Z+WPRauXDIRXrukWCzkws1LYuGZY2GI86VY+Dq4EhxtLDQzDlYDxcIppj0uFXP8 NQr87KTseW/5yRujVRc1nBsyS5c0k63xa8XLGUsVptOpjK1zjYuNV/NvB9uvNEtTe7FZQHqa rqxr2zLsG5gtr+AvRnQZW4wG9s7n32utvK3kGEsH1hs9y9anev/NtuufsO2WsnOUnz213rLG 8pMsa4632PYr6y2b6r7Eto1dti1/j2U7J66zbG68z7LGyE12+e7b7H3+SoCk2sm9vZwsZ76X j7SttBJoW3kXg24OUsf5FJMhZjr1K5N0nLEY77zbuJqj77KzZvFvZLFR8ke523ikzPhGyxKu FOw/YkQWdz4dWdxwikqooymd/IFfLDdWb7n6va0l5GFfMPrZraqhOiHxbFtsbETfCnIepO7+ 0yfLVmPFV/fiyGI+LbDqxmhf9/K/32gY5WYT5X1/OPm9DZT8me0cUIc6zEVgB/sR7IdLDWOM beETkye/N0SeUprtD/PMKsK2mT8W9RV7yWTZF258+dZTLjzpLTueiiyW0P3WkVrXKcuLV77H umRNX9OUiShjEPw3qAAXk1mPtRrUVTGeq85TGV0aGn8dwJ2ca5fOic/YNMqpo2Nl3WBBx6tt 5alMx+iUuy3Z05qrDCN1PvuPgGGgGDzVfGZcncL2avLrgDceb/vzBdGXvWr82fF4wxOu679h FIrHjbC1W5zPxKP02xFojC5ZbxwE915s2VTNDnv/qOKiEX7FiM6FO0YOzWuMfHbrYfhv0Zi3 Y4HetV55hXWOfviiSWtUZX++3Dg517b1ZP5aj87dkWmV0W2ePJ31EuL29eyN7DhQFvrxb8pa P3WgrO7sk63jSlCvkjGebLr6vXabikvUUPkbyf/2e27tMay/AMR4ZvtJ8+C3XnphxSWqa964 v8cdIw3UZxRfsvfJ5caaFemeNz2ZeOhvHIva3bvu33vUZvie3y9WjMir2la89fzu33vEJcwU I50w7wMvAE8ATRXuGFGZzpfGxEwxojGUHy/TMUDWs8Z2irytYDZjW9cOk7YtgDR97ZDWtUbq idvnYFyugcsZlzom4QCQb34NvL5RmXwjDTP5JkbZWqDk8DuxniJvPvzRxJ+ienie/PFbNMsf B4HXHyoL4g/0WWmh/IH/N313nvzxe45E/pgEXn+oLIg/Zhoft9C+DzyXeLnlhXdb1wLFi8Zv OyBNx8t8z+3OOVVMqP9OcBk78tFbsV4fqUw+er7mF7e/THS0ANK0v3Qc8zm/XJ33jf5Wm9c3 Kjua8ZNC+1Yw2/Fj0raQP+Zzfrkm74/uAv5QWRB/zOX8Emx8zN/88u68P7YW8IfKgvhjLedR yYlN5/rzCHnD4LmMj4Fru897zcBfztP8so22SUCajpcQO1HrLu4KVkf2nVz2n48/R6vI1Bkv taz5iSbLGm9qs2z2FR22/eIm297wJsumru+2LEvjgndhWhVVAtxgrYu1rbQSaLsOOMesOhtB L7gWfBDcDj4OVGbk7wlU1gd0HB3AnZx7gs1keo9R9UvBkjwWYzWn6T5AydFxNL4//k37os/V 90b/W862VvDLwvYV8JLVtv3sW2z77htte+UXbHvag5ZNveQn9v4c+z6Ds+X7cazX9ypbCN/v pf8seC7j/hO/XxH9QvcLzNk889B4iQHSdJxofFzKkw094zDub7GfZrz3s5Y1Fu+x92+asPeP 4hw00k8l0Bi/GHSzoe35fh4x8L4/ltGNkSk17h+hw8T77ecRer6QOl4l3IeRr3oD3Ku4n0eo VPdGuq8ZpHwFe7rXkn49jzicfx5R5F7rUjH43GtdWuRe69L5uNe6Ek13A80L3wKav3DB9Nyj sgjQ2OgA7uTMPRvJdMYNc0nR+61dlPeD5zLOwz952Brnmt9nGrcbeFZljds3t9vj9PM32+O0 ibsOPaX76s+Petw686X8o2OW7z7Ojnz3j1iv71QWoczPd4523dtrbp5pfm6Drxk8F9+98p6/ O/fkH1RGnzVHBHgOsxctWUCaniP0XOoC4xqjgTlC/16KJy7Gup6LnnHyOUZs+9nGZedYNnvK 62x7/KW2nfo/lk195522/TLPPanfsIfnnbI9N9r5X73dssY/f97e/87d9v7X7rFs7u77Ldv5 mYfs/BlmJPu8VKIb1814TZ5pTprf5z+RxYMftOek00uNtaPMTrEPPTMnpRVMzEkp/lW9YnNS RjyRRdac9Abqa05ynpEWmZPiVPWbk+JF5qT4fMxJg2i6EPSBNNgJdO6c9ZDKbgZ+z0h9xqm1 nloCj+JXcLYr2FYMhvL5umi4y9l91topRd5WMJvYLPYcqckwr/vaHIxv79yl+eszQD7WmtPr Y5XJx/J7B3AnZ96PkdmUL3D4j2Yt6cxVxdbx17I+eSczrzPzZG/50DlG82vW5676qGWzr7vB sgOtt1o2ddLnLGvU3GnZzo98ybZrh+38GWYNzeV+c4ZzzPKR/NkL3gbkS/nvTuAetyobABpX M/l0M2XeYywjT2PTgcZiBZjpOtFP2TbgHYsh0yg1yW8Bc/lb8pDxYd6reIiDLSk5mt+SdVyt QMmx8qDivFBy/K92zja+OuJvrGtdfzMnYRhbCmLhyeMi9Z1hpz4+TDnbFKdW84/A5rmW8WyL oxFobKjf80EKbAXyt/42fSfbG8Gz36tojdrvVZwZ1XsVdX89I6r3Kn57z6uieq/iB59qieq9 ikh6LfX0XsVpQO9V0G4BfkvWexWpsN97FQPhX9cNhOMcn/zgJGdOWETGcfUfCFfXvzocqj8h fBn7tj/tmk49+dGobwin6lPhs9kMgba81Q+2dUDvVXwZq/cqvoqtBvI7u9Pnm81A50znaRtI Avs8GaUm2y1gLmMhXfJh3quwYuGo3quQH1uBkmOPJha+Ao9iQe9VDGPl/1T95HGZ8PMRC3o/ QrGg9ypOi+q9Co15vVehGNB7FYoJvVehGLHfqzgTm2+3ALGg9yr8YiEbbgg/Gj6haCyMhF8d fiz8gfBEeKBoLOQoj4VnjoUhzpdi4etgLmKhD55eoFg4xSz+O+5HnnziPF2TNae1A9L0/cAi dubzd1lnblbMq/9OsA9sBU+AjwCVOWtDlX0YSFcHcCdn7hHPfP426PjLpJ8WW8C0v6R17Tz/ Nijf/Bp4fXOAPPlGGmbyTYyytUDJ8b2zpkuRJ27vuiLo+DFpW8gfTfP826A0HwRef/yWvCD+ QJ+VFsof+H9efxuUPyaB1x/6bTCIP2YaH7fQXvPKcxkf+i3DiZeNtD0W5hf9/icf6bdBr49U 9nzOL25/mWhsAaQFm1/0+598o98Gvb5R2dGMnxS84p7t+DFpW8gf8zm/XJP3R3cBf6gsiD/m cn4JNj7mb37R7386h1sL+ENlQfyxlvZK3vn2EfKGwXMZH/p95Lcfa4oWe6bgfk4U0x3dKS+w n7hceLplsydGbVv6Gts+ebFlUw+/2bZ3vs2y5u0ftCwrx3Ok307PbC8noxLghhmfQzrHrDob QS/Q/dEg2AKGgMqc9Y7KHgAh0AHcyVnvbCbTe4yqvwRonSQ42zM9U0hRR+d1tr43adsCSEfM VWcaAx+8vqjXgj2/9fpNvksA+U3W6zflyW/y5Ux+i1F2JlBy+I9mLeQeiyachfxxqdHwrk/M kz/eRp/yh86j1x9vJy+IPy6lntJC+eNMI/Wz9Dz5o4fjkD9kvf5QXhB/zDQ+RmifAbONl17a dgPSdLwoNj2/tXx/l+WbzpVftGyu/F57/6X32/v19m8j2VL7GbL5X9+w8meaoWYXa0l0CfJl Gnh9qTL5UvpnirXNlHmOzZrTFpFfBmSdOYrNBRt/TUbDLx6bB59pfvoMkM9uB16fqSzI+Gui ntIaUAmc+UkT25/Zn+34y9L2QUCaHn9L2dHvfNcwMp3n7w3sX228g2vTu/kBuWG9nsUbX7zM ttH32XbDLsumJvgtlvLUQ9+18x807GfwK5ZbNvu5l9p2+yts2/VKy6a+xjs5tDO7N1rWOO9K 287hdXaAY9P1WefhH8A3gfs6q7IskA9mGsMJyor5xz2OnbFcQRvFRQhojAulQL8Fq46S99z2 kdcLZntu22nbBkjT51Z9MtYN4+F32L69s2fOfRynj81APr4ceH2ssiyQlg7gTs5aJkamdMpP Sl7fPELeMJitb7bRNglI074JsfPMbzIXWfOU8THWehrr/7HdsrnHPmnZ7P07LTtw+2ct2/Cp Oyyb+iEzM/VzmpHVbg7Hbi/63gzk1x3A61eVZYGOYya/bqbMe4xl5GkMOpDPxSEoeX2fIm8r mK3vTdq2ANK07xWDzUZn1VeLem12162NcN8A5LebgNdvKssCaZjJbzHKmoHSQvmD34R1HS8y imbvj1s4DvljJ/D6Q2VZ4OePJuooLZQ/1hrZJ/fMkz9u4zjkj08Drz9UlgV+/lhLHSWvP/rJ 2wa88RIyjVKT/BYwl79NDTHa9xm3IvjY+512B8f6Y5DWMYNYOMf/e9ZZ7viMa2TK2aY40G9+ jVSsBJq3zlcjsBXI3zP/TvsPUW6uwevBCdF01+ujb9pXH/3DVW+INn+0NnrpyzdGa9++Irpq 2xuim649njobgWy+3QL8NpXRIo8FwmUcy2rgJOcaKf9FqgbKa6s+Vx5nW35wklNnERmvqnpf ebTqgvIzqurKi3GZVZHyTFWqXM8aQqAtb7mIWc8xvo+9EfwUaN1aDeR3xcVzPWc6T9tAEtjn ySg12W4BcxsLNxELqOV8HWvvLPRzrIqFXTpmEAs3lMc4n44vFzYWVjG2FQsvtGLh4K4XWLHw 9deeaMXC3afVWbHwyzNrqKNYkFUs0G6BYiHrGws5YuEnPrEwRCxsIxY2+sRCjFjIFo2FnZwz xcLnQDU49mPhVmIBtcdgLNyC/xQLA8COhU5iIfc8xcKLGNeKhZOsWPjAlSdZsXBRzYusWFj3 1xOtWLi2tJ46igVZxQLtFigWJn1jIVJRW1VbUfy68CdiIUss3OgTC/3EwmTRWPg0502xcCeo BkcTC/2017VB14VTzJnfWbj9v+LRkprl1jP/zdSPAdL0PcVidpz3lqe/Rbkg/w3Ko1fb35j8 N9896CvzObxPu5J+fwY0pv8C7gC6RjrP8n/O5ueB9HUAd3Ku2xvJdLS7nx2ornN9cJ4Bpcjb Crzry6C+M2nbAkjTvpPeZl5iu6+od2Z///FX+G8BfwNe/6hM/pGGmfwTo6wZKC2UP5qM1Nu+ N0/+eJrjkD900F5/qCyIP5rUnrRQ/uD9ltafzZM/SvGD/LG4gD9UFsQfay1vPNsf/eRvA954 CZlGqUl+C5jLNWi65AYjWXLs3Y+9Bz/u4Fj1rmBaxwxS9Tn+FvLzcT/2Fa6f3I+l/hV7QnTD w/9q3Y+d8LUR637sV28cse7HrvvSiH0/lhqhnu7H8u0W4LrbUOt/P5apHSgfri1+P5aufV/5 jtoLym+tLX4/1l8bKW+onfl+7N2ctxs5Z73Yz2CrQSVgd3oOYDPQPfRC3Y+lS24iFlB7jK1B FQv9OEuxsAtrx0JDeYrz6cynC3c/pjHNfZUVCy+0YkH3Y4oF3Y8pFnQ/pliw7sesWND9WL7d AsWC3/1YpjZHLBS/H0vXDhEL24iF4vdj/bUxYmHm+zHFwk7Om2KBO5z/JbFwK7GA2mMwFnTt VSwMYO1Y6CQWno/7MY1p7qusWDjJigXdjykWdD+mWND9mGLBuh+zYqE+HwsLcz+m64Lf/Vim NlIxXFv8fixd+ydiIUssFL8f66/tJxZmvh9TLOh+TLGwkPdj7/nU54Lfjy3+tv23AbZcZK0g U3/6mL2SDD1QdEW5nONyrnF1+W1M0b+7cCXlG/CFxvTl2DuwmOn7sfPZ0XpyMehQvist1P2Y 23cm/bfYGrz3Yz/6ZlHvzP5+7M34QP65CnsHFjPtH5UFWW83qw3JuV4ezf1pEH9wP/a+/5wn fyQ4ZvlD77regcVM+0NlQfzRpDakhfIH92MX/Gme/KH3gOWPd2DvwGKm/aGyIP5YqzYkrz8q RQa892PFnl/o75H8cWip9exnL82zgDQdL8vYcb8L6TxLcX2/rr9Oou/Xrzx+vWXvjdn2gm7L pv54vb2/84u2fcu/2PkrfmdZ8zfH2e8L9ayy7ebVtt15mm17z7Rs9rUX2rblYjt/hidNs4vd QY4zg+8+jv0b9jas3Ok8a1LZTnblj5nmti7KfHxlhKizBCzKw9muYJ91sVWusjJPObvPOt8p 8raC2Z5vk7YtgDR9vnXMzAdL3jwPPt6Y70g+1mLI62OJkI+lYSYfxyhrAkre8f8IecNgtv7Y RtskIE37Q+frmfc87NFvPQPV2wT9/G1O2WVr7fezLmHEs596/Dbb7mLEq/winu7IHpd/f2uG kTuba3Iv+jQ25csc9gtY+c89brV20XHM5NPNlHmPUeNPY9OBxqQzRtl8lu/7yZP/vL4PmUap SX4LmMtnQT81vsZ3o3s42GPrt/mvcJwjQM+tH9Uxg0xVLpwJxyqd8Uqcp5xtigM9V2ikYiXQ eThfjcBWIH/P/Nv8uigzEtDf2X619X3oT6pfbX0vet8j51vfj97yT1Hre9IffNmkThs4F+Tb LcD9r74b7ebALuNYVgMnOetF+S8X7q+cCN9UGWdbfnCSU2cRGY+F31E5Ej6r8tFwZWUxrmw4 UhkLd1eeTRvFRFversfWgSGQBV8H3wHVQH5XTD3Xc6bztA0kgX2ejFKT7RYwt7HwDWLhMcXC MfXbvGJBflQsfFfHDDJVkcoM59Px5cLGwmsY24qF11qxcPVPO6xYaNtxoRULL3nXBVYsXPG+ v6eOYkFWsUC7BYqFjG8sjBELj/vEwj8RC0liod0nFkxiIVM0Fh7hnOkcfg9Ug2M/FvYQC6g9 BmPhW/hPsfBvwI6FGLEw9jzFwusY14qF11uxMHVnzIqF777hIisW7m99jRULk2Y7dRQLsooF 2i1QLEz6xkKkaiIcrorjz0bgpCOvC78iFh4kFrb7xEKKWJgsGgujdKBY+D6oBkcTC/2017VB 14VTzOK/zadzrzpmf5v/KsfwF6C1jnvd+XP294DFoAO4k3N+NpLp3E86a8tQvqJzfahiqeNd 75xq2r5X1aC+o0nBe53mef5tXv75G/D656/kyT/y2Uz+iVHWDJQWyh/z/du8/KGD9vrjabKD +KNJ7UkL5Q+eBc3rb/Pyh36b9/qjlLwg/lhreePZ/pjNs6CPfvz+c0+9p+MongWlnuDLJJ4F pRbZf9PQ3Ndq7Zsjpm3/sd1+rtATt+3mTstmWz5g2c4LP2rvf6rfsuZ1t9j7n7/d3r/Z/tuG Db3293sD19jf7zFJnJN3BMa9vZx9Z56uy2+r5sr8tvKcsYTLDc1Jg+C1YBTcDvYBlTn31Cr7 f2AZmCl2uyhbyGdBj9DfMPDef59iznxtcZ/vbbRNAtIRzz7eMP334/Lf8ezj226eZWS/d4ll U5+/yrLmu95j7590nWWNGr5Spl7nG2+0bFZnUM9Ajjg7z5yp2ZynXsR2Ap2fHeA/gfs8dbKf AyEw03naTJn3GI8jb4kLi9gWh6DkjJejuTa5fW/C2SJil+91HM2GqfFexGuze9apMX4DkN9u Al6/qSwHpGEmv8UoawZKC+WPJsOK+3nxxy0ch/yxE3j9obIc8PNHE3WUFsofaw1r/psXf9zG ccgfnwZef6gsB/z8sZY6Sl5/9JO3DXjnqpBplJrkt4C5fD4yZPycY/kVgo+tZ4UPcJz7wY/B hI4ZxMK5Kr7jWer47DgmTGeb4nl8Vqj3rt8K9L721db72ie2XG29r/37X15lva+977G3WO9r V/+gkzp6X/sKkG+3APeE+o6ne2nxZ4WRqv6ltVW3LI3jrEbgJOeeYxEZr6q6Zmm06uylZ1Qt XXoZ+6udSlinns4F3/EszVR1Lz2bbc39bXnLRWz6O54c23pf+zegGlQCxcVzPWe6x1FMJMF8 PiscMv6DWHhSsXBMPSt8gOP+BVAs/BbYsRBZGuN8Or5c2Fh4O2NbsfAOKxbu+Z8uKxY+uPtt VixceeNbrVi489NXUkexsAUoFmi3QLGQ8Y2FMWJhzCcW7iUW3k8sXOgTCzFiIVM0Fn7JeVMs /A5Ug2M/Fg4QC6g9BmPhCfynWPgDsGMhRiyMPU+xcA3jWrHwLisWzvhWtxULlVvfacXCU/G3 W7Gw9ooEdRQLsooF2i1QLEz6xkJkWW1V1bLi14UJYuEhYuF6n1hIEQuTRWNhgvOmWPgjqAZH Ewt9tO8FQZ4Vfv3aK6z7943Ubwek6fu5Rezk7+K8/6PMmW+ah/ddOunv5+AJ8HswCXRtdO6j VaZ86eoA7uRch3Ucec1zfg+m754cf5n002ILmPaXtDYbxo9658E3Oi6NDfnmEJgEbt+oTL5R 3ky+iVHWDJScayRLpKN6XurnD54PLv3cPPnjLxyH/DEFJoHbHyoL4o8m6iktlD94Prj/vnny x185DvnjMJgEbn+oLIg/1lJPyeuPRshWgfm4BxuhvwzQPdxyrNKlP3xZtOGM06JxbM2+lugP /3hy9KY/vTL62Cebojdjv37y31n7Z12wNrqS8jbsSdTnr+sCxy638nN1y6Oq95veZVa7d15e Ff0OPO/A7oNX++pH5er3F9TnbgA4Fr5FVuKO0NngS2yzZPr/n5Hm1XkQUroFyKdntnVdvhy0 gkV5izmqvz9+Fu1D4EQQAR+qQEfYMOJs5+cntp65T9Fzqg9VXBQeqOgOPwaeAjXhi8Bq6+9n N1q17X+cOVVaI/wtblBeE36x9Z33TNw14anQUxU/Cj0GBsCHKqbAi4t+55qq4HuPioZwG/3o WExQB+4GnwAPgK8AZ0zOxbo+A98XgH3vVLKon+1tQGOQOdFKZzNmsqdWR2X/5y/LolnGnMaM M3Y0JrWvMaNyWdWX3X75SmvMVk/VWfVl1V5WfCp3+PNjyxpY1/HvCrMkFUHBYql42nha56QS aPyszqPYGHsZdeQ/1bfS07Zx/Kf8aiBOzRHOGNrEdgw4yTn/8kdN+HTOvVF+5Lk1yj9UcTq4 qnygor/8MfAUqAlfBU4vd87netpLzxfBJ8H9QM+J3BocbWSnXMd4Lvv5lJreln7d/3aCjWAu 7n+PhVh2/O8e97dzfLP1v+PTuYiXbehIzpGv9f6ZzrE1Rok3a5ya+h3lZuM+/a84zLHHwvm4 FI3SqfNxI/gS2AmkN1XRXD4G/rf5+B6e5B+LPh7EpzuA28cDFbnQXPtYa5gImIs5Q+N4BM0Z 4F67PPW971lrlz9jtXa5f//j1lrlvlPGrLXLF5Pft/a3XP8Da+1yFdZau6R+ELXWLpZdHlW+ 1i6qp7WJ2mmtshseXXfEq331o3L1a69dHodnOfj/7J0PcBTVHcc3ISGJF0Ig3CSXthopVKCx cxFsqaAupiIiaqChIuIUq1Bo/RMxwdShMzctMzJTR8P4L61KM3aqFrCNFWmKTL0qilC1WK1V SzX+QYJKDVM7I7bVfr5vd4/jyN4dl9wldPomv/x239u39/b7ft/3fm/f7lvpU44Z32VLKLXv siV0QWB3qCkwvLopEEbmVl+AJPddGqprAkjJ3Orkvsvc6o+Kw9UvFQ9HdodeKt4S+ghJ7rtE QzUlyBG+i97hk+9yP3owfBfZjHwRafkmsh3ZjGc7D2E72pfNKF1ax0vLN1G6fBUdL6380jqf 0r3zp/Jd1H5KkvkrXhuqdrUCORq/ZG71ZOrVKjm83qySLaHJyNKS3aG2kuHVbaS3cdxS5Ei/ 5C7qSH7Jfej/+yXO2MSrk0Iqbj7YNCDxNu35JZng7537WPFL7s671epAhppfovpYS73ci74d Lf5EQ+ESq/rY80vWsVbHUMT4brCVXxKPcTdrdRyLGLfnvcZ77+8MOTvWGhC7wVj23OPaMeuh jGA9lEGYv9B778xrm/fel5v33jWvrffeNa+t9941r6333s28tnnvXfPabj6f+YsJXJf6NXE0 nT7xJI4z4yN0fPDaTr++8jMcXI7o3fhUc9+dlW1lXZXJ577bK68pu6ny9LI7KpPPfbNmSllN pf/c9wrqtptyrUIfK3Pf7XlvwJd98GVozX2LL6+DpfjyHlq2EAmVl0WoT88+BqJvjXDeZsS7 R7aY7UZEY51itBNk98xhG75cZfiiuW/xRXPf4ovmvsUXM/dt+LLE5Utu5r7FhVRz352Vu+BC 8rnv9soNcOEGuJB87ps1U+CC/9y3uPA24IkL+9EViOfzevVHVNr3wVZzcCsyUGPacZzLtD1x 92ba8/bABUo7BLnwFuUVFz5AO1xogAuDMfctLjCHbbhwreGC5r7FBc19iwua+xYXzNy34YLm vt18Pn2H6kPSnzFUfL+Qau6bNVNGdlUmn/tur+yBC5vhQvK577bKCFzwn/sWF3q4MnHhALq/ XFijcyHiwiTbwU22jGd8llHutta58OYuG4mb5STG5nKHse/OI2+ZYebr0l0pJbNnbBfzexeC wVvob6J70SiIOIJyjzhLaZq/U7nmKD4uePfpdR3ZmvuOx8vmd6Y4vx/DS2UNM/edzXVShM3S PrD5louNyuCHTQNpYUTBa2O5r57x3Hc6eGR7nRThoXVSetG6ds9WtE5KOnO9tcpDyBUedVle J0V4aJ2UXnQ8HlonJR086sinkIhHG3GrEbUpX7Sdvppdq9i28m20uCCfCGU9p3+EWx5vOVN9 Ubwo3juOzU/95kFW5P2O770/qb52SH3vvQkct1Jwfe99u64FqansDpSHBmOtgmfqnbUKtqPP Nd97n191rvne+4QdM8333kf+st587/38zVqr4GlkBuLmy0Ffq++9N5Umf/64u6qtdG9V8rUK ikJXlVaEppUWh5KvVWCFyksjIf+1CvS99yh11o7eia5AKJ7himfz7A4pv3NF3u/hwg5xYUjN CYoLjwGWuPAHtMOF8tLy0GCsVSCbPg8RF843XHj79TmGC79pm224sK7lHMOF3d//GseIC9Ju vhxxoTMlF3bBheRrFRSF1sOFVriQfK0CK2TDBf+1CsSFbdSbuPAsugIZ+lx4Ei5Q2iHIhSfA T1z4I9rhQgNcGIy1CmTTrDlguDDXcOG6+xsMF2YuuMBw4eTTzzNc+O7ZszhOXJB28+WIC70p uVA+Ym9V8rUKikLvwIVNcCH5WgVWKAIX/NcqEBeept7EhefRFUh/uNBGfs9fSjUGS3utgkFY t3IL16GxmHwdVMy/nskO3plVgMxRfFyIH4tlc60CjT887Gx+Xz4oIafjMeGj8VgiPhqPCR9h 5odPA2lhRMHzPfo7HkuFR7bHY8JD47FEPDQeSwePWoNG7vDI9nhMeGg8loiHxmPp4FHng4f6 7S4kcTyWrK3RupVH/Z3yTFeqbGT9Pq1wOcDvrneC2wNc98voR9CoWJuktIfZLUb8OLeItPg1 BvQtdh0/HBnmirddxL7CQHAzHnubc/bVVp1m2cdZZs0GP9Qyu6/WyO/91cVNOhE3xQk3lC9u DaSdhijkCo+LLPtAUZbw+JuLx94+8HgtTTwucuDIGR7gv3NslvDocfGQTrQPxfXHPraCUyeS aVu1irxNCCHWt4ub86wa1uBsti5DlljWQ5MMNtFpZzp67DmOvmS+o8+61OjImKsc/a9moweW a62U6z0XywCDgEQslSYsVf5kbVTCtZk2Su1TISLttVFs5sz+aq2OpT/IAmZqn0aAldr1sj4w U1o69lcrMAjjkVLE86XUsH3Ifqb2FyXvJoQQs78ydpJ9h/uI9W610rNWndBKz9IHb3T09juN jrQ+6+ipvU78/aXOKiY3j3G0VnomX/QpWgB0pJUVntH2bFZ41vkGsJ/t4NrUl8p2D6IfR6MO 62ej7AoDPxteRloyfOLt2LPl48gjXqg/lo1LqHqrBNExCol1u4a4VUimdTuLvNMRQqxu9Zu1 Vo1lP/F1B+P1lww4xgv4jY9djP/TB8ZKi3KMyuKHcQNpKqdwUkjEZhtxXUim2KwmbytCiGFT zM6hdY+dmTZ77eUOTjuvdXB6jjWKsMnuzWuMjv60zUm/lZWpiO94eZ3R1vG/cPQA2q5sQaDJ diehH0cDZcx2lRZlV9fhh+si0hKvUfYqG/REmOscEoVE7CPENSOZYm+TdwpCiGGv6whbkVEP JkUtcx/xZBe3uj5wU1qU31cZ/HBrIC2MKOQKj1pr8cebsoTHKS4ek/vAQ2lRrjMVHrUCg5Ar POqs7v1dWcLjVBePr/SBh9KiXGcqPOoEBiERj1JlRI6WL/1be8/00v8z32F4Ggg/AcM/O1DG 2rxO4l4gbiTix90rSYsfF3v37eL8a9PWqf1T2yfxthP77cKEdHaPqO8IcZm0j1592+Tvq33k /lZWv8MgjNWHJGKsRloYo3wxbiDNrz3YRloXkqn9ryZvK0KI9RfF7CT2Y0f4pam+w/DrXY5f uv2g45cOcF8t2xSWr6LfRAs/7xkOpXWzq+vws9tFpCVeo+xPtumJbFXnkCiMR0oRb3wQYTsb thi2ojsLstQW6/6FcHujD9yU1k0ayhe3BtLCiEKu8ICbd7ujGR8rytx3edPF460+8FBaN9eZ Cg8/bkbImw374N7zD51Rnd/oLXM89rh46P5WIq+Ulg4edVy3QqJ9TCd/GDmaturyVxfWv7dj Q32xnT88zDnHIeY5oK+WMXY9FArZnMGdnXP5L85/2c6PPIOOIoRY26a+bB53fVYiK2gBllvX WFdbNdzNvYztK4mJnMiaKy0jz7BWPW90pJgWjP3IeWVnSkdHMZKW7jnZaKuT+0bs23dw30jH LWLUp/Sx1zh62PeM7r70RqOtGazSSnrNlNuNtk/6sRPfL9uewHWpbQJero/7Xmxo+x9MqqFi oU2RhCKrAKRWcM2XcdWZhvKC8L0HBL11zzDzCUvL+tmBwm1WecHUGw4U9lQppbzAsmxLx3W8 Ptoat2T59VPziEMrlZVRrCZ7ojWVdLW3n6dMK9CbOHbj5N7Cceiq0yeaa1nGcaXst9Yuv155 +ErOxfyzFN9I/FMr72jR+RR2s73Pfv+JL8w+7mIda6/d3bKLYyQ/6p14fQ1a+Z/ZN9oaP6a9 5dJ9yzZ/AlbKt+HUV1qUp2v93wsmzT7xciGp7ZvI07L/lRadS3LFSqdr8Oxc0DYiDyAHkQVE zEO+jSjN65+UtoSIVH5Vcjs99I2gIs4nAWijhWN8nPov7SteouCV2evL2ohbjSRys9i28m3i pyDe83fPsa3Qn+f0HrFOyFub9428ofac3sNc1+eom1sR1V8++w2B3lHlocVBDzOwjHjbJKf1 zJfHT+E/U5mQZkR4+39TSM9VbET0bNKD5nmMDS9tNM9jjPnVBvM8xo0nrjfPY9z38wc4hucx ItJuvhw9jxEJpnpOryO4t+qu4AKuVzh4wZvvH0ZEUWhlsCJ0drA4FAyK1OO8g9DecaoLntML RkKRIBOEhnzTXa3OoArR8xhzkXZkIVJBnNcuHm2dqZ5WI62IU09Wvs32FGQgudCed0Leo5bh wpB6Tu+3XKe48BPE4wLPwozqDAwGF07FrsWF6cbGK5ZMr5fNv/zotHpxwP7B9Hpx4s5VZ9SL I873Vh5Eu/lywAV9XysVF6KB8uD2QDApF7YGzg7uCKwM9gTuSsqF7kBHsCHgz4VHqD9x4TH0 QHChi/NsRMSFSbb/+yF3fnhO/acvrDnSZ7uZb/jFhUK2E322RuJmOcfEfLZh7LvvZqz72PkC 7w0XOu+V/KltANaDm8D5vTZiHttNYMaf9c+s+k73NP+b898mX8j4SPwgYYL1JWs++sUTegWP FX1ttDWxe3rzRO4AKP7w4PhOXpx8pxZ2tt60p7D4L+8WTr1lT2ES32mh8qXwnRYm8Z0WZsN3 WkyZXkQqqIC30TVuXXi+k9KOJ042MQeJD14/0Uhktt7l8Wxb4wub35niFCBmq7KbsBXp6BgA uxzPuTy71DVJ3kGEzbvoRGyUJmxUBj9sGkgLIwre+T0fMEJcM5LoA6bD9WR41PLAdDRLeLxP eYXHfnQiHkpLBw/KZ0Ku8KhjeM7dsfeH47Qc+irH4dujKVEporqscrdRSb+lIvv4ABEeB9CJ eCgtHTwonwmJeNxG7BrkaOzjtuPvM32B7EPlm2XOfGg8nu223bsG4ajfX4zIlxFGy5BEjJQ2 mO1LPF42ZZ2CEHLWvnzHxebqPrBRWjr2EzZFHpj2JR084G/W2pcmF49r+8BDaengMZDtSzp4 1GWxfbnOxaOlDzyUlg4elM8Ej5te//NZYsuRxPZlDnFXIGoTC5Bp+ayawG95+5qvF5cnWutJ 9YJfy+qlH67HsluKyIfQuC++LPm2k0a0eXZljDYI5Yi2/wsAAP//AwBQSwMEFAAGAAgAAAAh AJ+bnPMrKgAALMkAABUAAAB3b3JkL21lZGlhL2ltYWdlMi5lbWbsfQl8FEXedoccJBCcBhQD BiYOR0KIZMIREIF00g2LEjELETkCAiIfKrsggoAcDgYVkRVwUeKCLy4guCwqoOviHREVlXV9 FRXXYxHZFd91BRXWgyPf81R3TSbNzKQZZsa83++rX578q6uq63j6X1X/ruruSVAUZQqQBjQC 1uLffYnwWO6nCsTdqihZAy4fqCgJSt7rinIsSVHwV8f5GitKbwQ+jPPnM9MA996VTZRBbycr yEDJA7IAZNclQUtQMuFXgUZq9Uc8bZwFpt0NPAcwrVdrJNKZ5fqK3FqSko44unZast/fVlOU cxGWCrA9VWhLqqY00uDvAbAcCOUt/oP74+bN/ZkuEAyX6eCtSdUSEmW9Gc60dK8Nfrfkxo83 F1Me2TnRUBLmK+ehTSrizHoqyoXwsy4TANaXbexgQVF8/eC1XK2f+V8N9AaYnpJOSoYmm0Gn /e+IEFmO9COt7yqEs9zJwLnADQCvM8tanTI8YXVKwcUyPS6lT/oR7QuobzGOLefz+5lHDiDL 5bVbCvgAXrtY8d9/T1OD/FOG4j+g7nHnuiuIIdcFkJLro57hCUc9Pw/Xy3bOLOK1CgQOHet6 TuvtJSe/TjNWXdteD6br0eDaxQoFcVIf2R+kP9mm19TxXDTuYUi2cXXKiuR5nl5NZPpo6HUF 8i0DTL1OSOwLvxfguJAESafvSzP0Y+106uXO9R300fPTjEZzs3UZriQkLDxXS/CpSGudU+OE u2ykzwDIQaCT7WN4S0D2QxmeCp6GIzwP6ARi1kJ6IR+BZPmzPEfSjnoGNxnnmd2Efnke+QqW H05xNCZwHNgL7AbIV65mjkEZOFaU6hIhLH/iO3rJhmlttVStUYoXYeRDjMF/zO0vklj/kiGL laHKpfhfCn+h1sg3DXIiAFdDDogUYIgyFeHXKllI60t/qL9y8vz+vi2fCKmsSCnicfXgdkL6 UgqF1D4rFhJNLEIWlqv1t0CI5JftoJ+uFUA/w4YC01AJUKwcqampgfC75awcXGMwX6xMV65T xov51ww98/9v/3euOOnQZzc0paf6TVNOe9uUMsfbJ31+/BQuaNlf6sZ7ZQJLNlLMeM9lZvrJ e8zjwl/+TZyvWOXZTlP2/zI9lWFv91so6tHqwFsi/XIrYRtv5Szhtc6XvMn6+4+t8+caVnk4 iXESy0UmmAtR3sSbxdTqHw/IdzkwDbgC4HElQB0m7ZubNCu5MbNZCeOaA9SRUiDQ4XIJNwKB gfrD8mkjSSRZJ8m+0gwKQ33fCmwAqO9dtFr9yIW/A8KpH7hKJUJY/jeLjuvUfWe6XBJXXZbt C+T2PBzw+FL8s3PLuDPjtkRcW8krZShuqxC3FLBzG86+OJs5j+M357z3eh4oMee8hAS7fcdr SuDy12tfJCJVb5G2VlIzXVaYXUjueZ70J6Ogq3DMMqcC9NO+eBiS1+SoZ0Vyi8bRmfNYLnW6 AigDws15/9j5jxLOcbSFOec9/K8DJZwDZXikc55sN/svdY39kH4Zngo+huM4D7gOWAvcBDwC UI/yG89usjplcJOMxkfS6JfnYSg867ltMfKfB9Q3t5GTFZcvLWH/Lkf6QQCcf64iz0Mwa2Qp yr1/MGenbl+Y8roWYWcjRWmBcyUnGZYfos58JNtM/WD544C7gAHA7wHyR07l+Mg4pmO9SoFA J8dHxlt19o/NTCfLkuOhD2EzAHufzdVCj4eBfCGZuG+D8PPFunqVat2cuXEhixBguUB/JNyw XQ8D5GYLYOeGcUzDOoTipgxxXoAuXnzkKb5TPWOgK2zrYwD52ArY+WCcEz7ykI4uXnx4Fe3D 8JZcZH2Hbd0OkI+nATsfjHPCh1f0itP5WInzOa6cSX9p88WnekMbXz5FByFH/4G0c8Q4cvRz jS+BfGmoRw8ALm7jy48WN5yw7dwwzpn+mJWORn9ywkcsx5dG4IG6khSED8Y54SOa44sTPmI5 vqRYfDQLwgfjnPDhVU4IBbHrRxVClwL28SVWNvT8G9obo6Zepp+3tZmQsAMblA3dE3y+Dj6W Q+6BhFA+ytmUPqX9pnTJHW1F6Ue0rwP+EfAWC2HzM48cIB3gGDcQqADKAPLO9eS+8HuBRgHr Rj2ONTMGvDRErBuRMx7/uu1AIRkeDxs6H5V/FfXqDflXyCRgQft/px/1bEpf0H4C8O86vLRE PNuJYcs/t8PriCPysgZYDpCXcDYh78XuuauXTht6MtKTTzj/mJ2Mg1LcEV1jrqe89Xk/ru4o 75SZqz6frjLlXTtNu7rmG1NG1Xacgjr0AW9/hhwLuRuSvEi7mnHk1qwrPAFO2tUjEBbQDv96 QyrC06z0UhfPxsYO5FNDvj3MvP18st45inZLoxjZlOMsnq4JwhPjyBPrUGrWy/9f8lSGkBwr 1M7HYoTPA+xjXK4W+p4jkI9BOLcvAOfnA1VCPx6m+B5XBSO+F3PDMtMC6dMBtiHD8kOEvS8b gfhrURD1ZzbkbshA/WEceYEIywvr2QRp6Ozc+BA2A4iUGw3nBtOVzorS8xdhGYnc3r7F4mR+ EE4Y50RXUD/h7HxsRegG4Ez56HjlGJ1r1Tk4NxPgOK7Y1qp5nWY8+tzTHLMGwW/qVE0dnSrD KrCy/BpztFrWMeyo1AJ52HWqBmGtrPAMSNaHaVj2UGAaFIj+EOvQC7kOzToiSVTcD2VTxPrv kRJzHVhRLkpmxvut437FVbPMgqjZqGM382hotyZX0Me60j20MQfTLuPN8CQewN123qqTXMdu pPxKlCPTDVlqHh+05PKXZtZZh5bpnvvcfYrny2OzFrXlkDs6dUCeKP+P89uL9LJem681z5f1 UtDTQq1Dj0A+tC8+hRwE+W9IlifnA8Z9hWPmXQoEusBxjjoS7f5M/aVeaijU7M+1esk69lGU T+4Kq43B+7NdH2V/YxvLLXDdmJwMhrRzwjhywjqE4wT1E07mf7ZzYX18DFSUMRtjxMcQi4/h QfhgnBM+BionSH3Uxvv6+Oij+Lp9GCM+Rlh8jArCB+Oc8BFv/ShVfNuPxYiPMRYfnP/t/YVx TviQfcneX6qgM0sB+/yXqimNNIRzbBBzG+RbAN3Z7ql802eazj2Vny59kPc0Dep+cCra9zXA PZV+GIQgsKeS5GrReHNLyR0mhrjcD3Lv5PHytWJPRf3yQbGn8nbz1WJPheHxuB+8Du0vBA83 QRZBch7Ob/yvlqtTXmiZ0fialvQH8nK294M7kP8WgPqYq4W217lGI20wL9J3AILZYMkItz8v wHloEADz3m+Lmffpw5Qsxbdlq+jHvj0Hhaz+6JwI7Fr7PJiD0tIB6tNQoB67LOrPByx2+HyA OfPWscvKUF1Rb0ppN8H+KeMx9YFO2mXy+QCZzoyt/W9/PkCmC2OXldWe7cgus9KHtsvGIcO/ Q5c/gTwKyf4O4bfLGPcVjqkTpUCgk3YZdYj3WVmQTQBhbELKvnA29ojU7XD2WYHie6pNFPRS 1pd6yTYRP6D95OYkpJ0bxpEbiJDclCGuAH0LIm585Cnajd1ixEcCyCEfiZB2PhjnhI88kgEn +Y69fiil/WPER7LFR5MgfDDOCR8FJh2n8VGF8KVAvOyR6Re+X0J7pPHhNGN+A7RHOP9S53LB q7RHtqckueZ54m+PTMdzjUNgf3CtjPaIjucaW8EOkeHxsEc6gQfaI15IaY/M8lzT8qjnhZbj PP9qSb/sY7TTztYeWQzu51n6mKuFtkeoR/KeiWPoIACujn0R72c87kYFOG6tB+zjFuPYT+ub 48w619SkIy1BJ/k9mzEskC8NefZgxgF8cX6J5TMeG5E/uXkUsHPDOHJT3xznRRq6ePERyz3Y x9EO8rENsPPBOCd85CEdXbz48MbwGY8n0Q7y8Sxg54NxTvjwIh2dnY94z3Ecr8cuX6if9+4p fcC22xvcPfcJdLQEgPfczSAhcM/dXf3I/WdVcheve+6RT9XoPz17p35vxnF9dNkd+l1KjX7B nEpdhsdjjuMzM40BEqFCJsH7vfsHdaL7TfUz9zSV/kBeznaOW4r8fQBtrliu+xiJd+s/PXBK H2csE2sXDelZ2uPg+VyAOpgFaerg+OZ73V82D+Ra+klZB/wj4C0WwuZnHjlAOsB5FmvIjp4D aHprjV46ZIWevP8nvfqfy/Q5r5zSXem/0WV4PHTwGDhoA9CAaQ9QB4+4c1tUuE82/9C9rjn9 koto2Fnx0EHaHB+9tVXY+vt/eq/B6SBt/XHgmrb+Y5DUn+0pbVrN81S3CeRa+hEdMx2kTb9t 57vC1p/+u/eFrT87eZ+w9RkeDx2krb8JPHght1k6OMszp81Rz9424zwJF9AvuYiGDi4GofOA +tYeqUfHRm8S+2flSG/a+nXXEqNp69vXEmWbqR8sfxxAe34IOFoPeTUk/vzrWYwbgwCOQaVA oAtczzLr7M7ieEXQybKaQdc4fvmAGYD9/jxXC39vJPlCsqD7jZHa+vVxQ35oz5Mb2vp2bhhH bshXKG7KEOcVI2D8+IjU1nfCB+158rEN0s4H45zwkYd0dPHSj4IIbX0nfDyJdpAPPgRh54Nx TvgoQDo6Ox9VCFsK2PtLrOwsjk0vFT+jV6xpo/e95AWO0w1qf41z3E3g+kHIBZDmHHfp+ZvT dp8vuYuXrZ9a0kZvlvicfnFzj/7Xv72gl76Xob83oFqX4fGY46gfs8EDx+2FkEmQD6ctPN/T 5OPz70lLy6A/kJeWiOfYjKR+XYPXkR3A8Zu66ANiaevz/Z0HLtqlZ9/QRi8t3t3g7KzJaP8d IHAN5L2Q1MHVKXdkbEpLax3ItfQj2hG/OUjIa8N5llxXAGWAyXXwZ37fVdvomWmv6kn7L9Q/ 3b9bP39Dhn5w8Bu6DI+XDi4FD+tQ1/sgqYPr0nZmtGvStvXdaZe1pl9yEQ07Kx46yDUP2vp8 zqDieMOz9aeCY9r6vN98zNLBo542rVo0jr+tz+cMWqTsE88Z0Nbnu5vdX35XPGfA8HjoIOcF 2vo3QUpbP79xwgWrU/a2yWg8pw390dTBxShnHsC+mauFtl25F9vi+o02W7/uur65Dxyd5wZQ pTrPc8o2c4wqB8YBfwdPpQD3rqVtIp8pZNxogGNQKRDoAm19s857psZi71rypaHwHmYFalAl MWdRFkS4d82sWgHpQAZg54b8cH+a3JwE7NwwjtzgLyQ3ZYgrUHavh/Dnfzb3PoH6oyHPYHxE unfNOtbHRwIUh3xw79rOB+Oc8JGnlGgsS/Idaz4KUOVI9q5Zx/r44P40+eDetZ0Pxjnho0CZ MDIYH1UI5NwWL1v/gXu6Fd/z8UHdddGuEsqGZuungYvd4Hoi5B5I0Ks8oazJ9KSsyZS6FC9b v3XSzpKqJw6IOY5c8bgy+QshGR6POW482v8KeLge8q+QSZDNU67KXA0+mqd8BlxVh5eWiOdY h6T+vgevI1uU9ucaYDlQ3xxHPfq4creY4yYjfQUA5x+zk3EQ8E7Srib9lZfP7a88fp0pL99g yh/eEtL3q1PmcdTfreKYvxxk9IX8PSR5kfMe49YiwKwrDgKcnPdGIKy2HfvHUz+JVEtC+Hk+ mzEukE8NeQYb83MU37bUIsFjVHkqR3n9AfJUDGnniXHkCX9h58AcZejrSHIaH4sRNg+wj3G5 WmgbKpCPQTiX1w/Or18cF4bhjqn6n60EI1pF97DMtED6dIBtyLD8EGHH/hGINwDychWknRfG kRfWpRQIdFJ/yhDIeja1IuUYJnVlMcJjwU0fJUvRplxucvKLkTHhhvyQmwpIOzeMc8IN65mE tHR2bg4ibB8Qqd5swLlVAJxfb3gdyvANralYkb4Wb37OwBdgpiq/Ri2U6Yf7KbvxHO8yjFGU 3VYI6dtUbR6P2Sek9mViEeOr+7cW0te6o5Dayq5CKlcMNOPTxprHUe2ry1F/2ivrwftYyCch 8ecf0xi3HQFsZyidnIi44Bxo7/A8jocc43hd5FhHvzxmGJ39eq1B2HIg0utFPSoD4PzXi2VO U8bjOk1WlB2/66+talrku+gNIZX1PwqpbUktYjimOUC6Wn8kfX8isskBngKXBuRrNp4Zx3mZ 9QvFczniZN3JmeQU3tO48yFsBhApdxrO7QHA+blD9ZTOivJ/ssKyE/ydLGZUn138C6QhP5dB 2vlhHPlhHULxU4a4zsrzhyFO42MrwjYAZ8LHH2YeKeaeUdTesex3qfl2ztHfhX1LJ5h+1aDu gfxRX9IBzhVDgWkghv54vWO5bljE71j+EtUUdaWUz97jWX4RnsRAOPksfwzesRTlYL4UzsE7 liJ9fe9YFiC3KxLMvj0WEn/+MZRxvM/j9Qmnu9F+x1Lqb7hn+PEOXdo7YbUxeH+266Mcu9nG cgsDIMkJ+66dE8bJe99wnGA+n4qkp/VnH8JmAJH053B8DFR8d30dIz4Go77kYxiknQ/GOeFj oPLZOiSNGx/QD+trA6Fmw8j1g3pCPoZD2vlgnBM++ig105A0bnwMVXyH28XonYZRaAf5mABp 54NxTvgYqhxoh6Sn8VGFsKWAvb+kakojDeE9gGi+Y8k94A7ffSuec1rpSsd3yRveHvBBcM3n nLoB+MNzTle3m+dJai/HssZQeelHtKM1Dzkvc+17IFABlAHkPdQ3d/ic0/zvmhjcLxpzdbrB dxr2n9vMkOHxWBfic05dAC/QE0hCnWd5nvcc9WS0H+cZ2J5+yQV5Odt1oR3If4vFS64W+r6d etTf96WwwbxI3wE483csa21YXpdoPheF7M7GLmtI71gOZVtw6YULsMtEOPWBTtplMXjHUpRj luLoHUsrffh3LO9Ghu+gn6+H/BwSf367jHGfIYA6EcoGKUecqS9NDqTDT9DJviDXXXwImwHY x1cnul3XHqnVVdY10mfScGodvZT15fVlm4iNALl5FNLODePIDesQipsyxHmVVJp3ceMj0mfS WMdWAK9fBhCMj8cRTj62Qdr5YJwTPvKUpAlI6s8/1voR6TNprGN9fDyJNOTjaUg7H4xzwkeB 0nMukp7Gx1aEbQDOpL/wfob7Jv//fhzE2VxyneNGyqqMRsqpxs2UXuqFFzOqOFsmYI+u8279 MB5zXKALGPdFeJIZ7B/3fdaxTGfmRrvB/MaSFa3Ib+/LdGHerRflbH3G/FaSg/txkd7J/fgb qJyBCn0IyXrKfZoC+PchgG0ON7bF4n6c+lt3vK99Zpt1jPX9ODnhgG3nZIDFCesQjpM+Sser keS0/uxD2Awgkv4cjo9Y34+TDyqUnQ/ej1NH6uMDz7A8hqRx4yPW9+PkY3gQPsod8tFH2fli PPmI9f04+eCEbtcP3o870Y+hyhMvBeOjCoFLAXt/idX9OL+B2/nvnQx+A5eyod2P857zd8By 4EEAf/gG7o7OU9rv6CxtNd53Sj+iY3Y/zm/erv8uW9yPkyseP/ZGRyEZHo/7cX4DdxXQG3gI 4Dy8oP3Jzkc9OzovaH8TcLIOLy0RT9uW49WZcjQQ5+wBqgHqY7h7Fq5RPNXRY0TyG0mTkX8F AFfDehLJgI5fH7pWGY9dVN/Xd4u1V989r5trsIs+FrL6RLJYc/P9uW0Ea28ooo6tm4NjcgVa neydRO0eHcUJ96uZ5u8UlVWaUn6fUrOOw3yfksOwqDeltK2wdyLCqSN08h49wfodJZnuwF7z d5Sq3jNlBN9BEuWkmcU4+T6lSB/OVpuCvPi9xcXAVOABgHohbTXGsR9QT0qtcqWQz0SMQECt Dh2ezWtLLlhPWVfZJ+T92COIWwPYx99cLfRaFHV/dVUXofvUoUwg2FoUquv/5iqys/ZR69p5 QzDUWV9cDbHL7GxdnfVge1nmUGAayKM/XvuAx66MeB/wSlQzmC6L8NN1OerfWhXlQB+Ec3Df IdKH02UqO+exx4H+wAtAoC4z7nkrrNQqVwqpy2UIGKIk8zT/OC51tgphSwG7zsbKZqC+X1n9 T33gPZX6k1NqGtyznWSJz3Ty/QU+R4w/fLPhw8zp6tfujvCzX8TLZlhy4yL9T88qxh2bbtX/ kawYzzxbqS/pcVKX4fGwGWrQ3p/ARxrAZ63Zh5ap+VnHXY2yZqub3PQH8nK2NgN10QdQH2Op g9ee7GnwuyH7mvUWtldD+mbDCXD9PrimDh4A8Acd9F30kTupayDX0k/KOuAfAW+xEDY/85Dj eiL8tM8qgDLA5Dr4e1z8Pkj3lhcb/G7INWN6G/xuyMvfFBoyPB46yO+GiB8nRiP+AVAHv3cP 6DrRndH1M/fzF9EvuWDf/N+ig/ue6mPwuyGTPujb4HTwODj/ElxTB48B+IMOPtZ1r7swP5Br 6Ud0zHSwKb4bUvFxP4PfDbk/p5/B74b0e/YSQ4bHQwePgY+vQQJvMn6ApA4ecc/Or3APzv/Q fbgr/ZKLaOhgFcpZCsi+ORv+KQBtw2yUTffmAzfpj12oGJTasQTj2O1z9MHTEo2s631CDmi+ SMhRje/UixFPyfThZK81J3Se59n4o858KL9HvpR7UA7jZbmH8iv10hMJxiPtF+ql1Y2M1+bM 07cvaWS8et0c/d5FCUZ5r9l623YJxrMrZukP/l4RkuU/h+MFeo3O+FsvO6Uz/cr5J3WZ39ZB c3X3PSd07/hbdXfKcb1i1W16+Y3H9THuRSLd/TsWifMmNL1d5EPJfClZDuNZLtOzHpQrILch 33bIV0ms4yprjxfWehMWGnV/y7imRo6fuAxirLXG237iYoh/tb+Vyf7C65QBMD0d51I6qScM DxyrLsFxKnABoAJ9XJh3sxRlBPyEdNKuQzTSLMh6wPVJ1jnqJ1mVwGfqAiDNhpXuSrWn+xzg AVdPdx/XSiAtixUPLG+Sik6cZZalIU46WR7vezqq27J2u9ZnrXJNyFrkGpR1i6szkAZ86V7k esO9yrXVXYh0KiDzs5fzJ1T8Xnf4cr53jXcPU6e6F6lb3VXqG+516pdAWtY6tXNWlTooa5E6 IWskyjCvATxwsp7knvF/ct3rlmX3RRjb2h/IAL4jcAFcwDk4IfA6yOuDJI7GNM6l8bBb+P75 FdPPNY7hm55fTMjBnJGY2JDslsngoQxc8vmX9QD+8P55247zPK1zJaccG6XfKb85SJgOJAJO 7ZaVH6cZvx1orre5duQYxXPB2aTOhgwPNmfIctgvqVdn2r9xinCyfcwnmF6lgoPhiMsDOoIk rk16gY1AEsJme97BmlzX3Ks9o3Lpl/lFY17Zgfy3AJxXcjWzjRk4xkpdiRCWn7r2VoGKdYnE M/zd8kRfOfIYZGZWQw4IXrv/F5+RMZupKB/cbK67HRlo+30Y6zjM+htVQfQVSrmuhvU3EU59 oJPrb/J3zGW6KKy/iXKamcU4WX8T6cOtWYxDXncBGvT595C/hKQOyPU3xl2BMOpEKRDo5BhO HbL0RfR99n862RdQX99AHPuAGQD1uYtmjhM4VJzodqGW6MMpQd9JiOUzMg+jTHLDfmjnhnHk hnyF4qYMcV6ALl58xPIZGW52ko+tkHY+GOeEjzyko4sXHwURfreJdWwFUJ857sr6ovn+Z6i2 w08+/gxp54NxTvgoQDo6mb/sL1UIWwrY+0ss11rc1V6D631DWvXjfW6D+m4T1/teAtcFwH8A /OE+15s3XR1Y535O8ohoRzZhDhLyGp+JzcJ1vT9c0F+s9314bT+x3nfxT5cYMjyYzdIBZRCo Fk1dy9X62R5Zd44p9dkjNUhzGCdxve9HyCQcL1PvzD/uGpU/W63pSr/MLxr2yGLkPw+ozx7h 9ya2pOQZHLPLkX4QQIufbSKibV+Qh3D9dBziP0XBj4Mjrk9VQ7Ieco5jHNfqf645LpAvDfXq AQTyxbpGOsfVxw2vz48ogNywQ9m5YZzcxyhFkkAn5/8yBHqtCKlvcgzzIXwGYB/DcrXQ9qwT PiKd45zwwd97Jh/8LWg7H4xzwkce2kwXLz68Ec5xTvhIsfhoFoQPxjnhwyvYOJ2PDdAvrp/Z 9YPvSgRbR0t66kZ93cJ+BmWPK4uMrutm6UVva8bsIwuEHO+uFHLWeXfoPRFPyfThpPrYJQbP S+7ex5iDfCi9yJeS5bgQ7y+3/226VlFk7Crw6VqWZtTcd4u+8X+KjFO3z9LvONjfWDrsZr35 gv7Gd4/O1FckmJLlH8XxEwn9RHz32/uK9C+062vU4DzKJCvfLyfO0ZM2XWJcN3++nvg56vPw Qv2/Mi4x5lxUKdJtf7VS5/m3tl4k8qNk/pQsj/Esn+lZH+aXiPxqF8vEelrAOlpCwELaz7+O lulSlPH54dfRMl3v58919fQeBiaqPb0vq+/nv6yOt+GrrhPV33Q97PpN17lApusrYHw+J95U QK7bDVLxHJdVnoZw6eTYloaAxmqad7PreP4c1zP5k1wP5Y92LQTGA8U49iA8NX8k0nWQJ0PK 89E9FMYPUvedVvYqtPV/uoZfW9vnerprT/W1rpPU1Pw5qid/kVoMjAcW4vih/EnqM/mFKEMF ZH6yjX0RxrbKdbRv4D+ECjVDf0vCZBfMvkASRzYT7+d2ATuA+uwBzwvpxonf7sNzr4m+5Ui/ CIDz2wPkeAi+mpCFuyj569lZeN17lvktl9ueNr/l8sMhIauHK+LrE77mGUJqe/KFrL5wgBn+ cYUZftUkIdGgIhZnukB/CwSlA6BD2Pf004WzJVj3y8DhVpy0BPIlSJ4vbQnGvYgAtqkUCHRS J8Yh8PT2/krUheclAZQEr58Mg/e0+WQxwuYB9vEzVws9vwZej0E4ty8A578eaIL4xoiycq75 BYtnveYXK0Iw2QLpyR15yLD8EGF5HIH4i1HQyzipFHIvJM+XPDKO7x5AhOSxDHHhvoXiQ/wM IFJuNJzbA4Dzc8M64rs585eGZST4szvMKJxulSP+couTsiCcMI6csA6hdKsMcTmK0h3iNF05 iLB9QKR8bMC5VQCcn4+mOAj+7Q/l0CMmR+9+JqSvH77JhO+c+D5sZX7f5EmP+T2TqX2E9O26 wgxfO9oMb3OtkNV755nyF0vM8BBaGBnny1H/YRbnq4NwzjhyznaG4nxiaA7EecmIl31Y9ukk hBE8JujstuIahC0HIr1eFTi3DIDzXy+WKb8h4kt92fzuyYJvhaz+URVf9vDtzQz7hY8WyCMd oB5mWH6IsLpNjkaAyw9w0gzIQ5A8X/Z3xv0TAaxfKJ7LESfrLnljejo7dz6EzQAi5U7DuT0A OD93rG9nRVvWIyw7kekh2zbL4ueWIPwwjvywDqH4KRP1wz84Ox+PIGwNcCZ88H2r7xIvL+G+ Qg7OzQTCP+8YuEZbe7/POg9RqhdF8uxuDc4NHDNZj3TWAxgKTEPm9Mfrecf7hlvPO5753sFV qKaoK6XcE8DegQiXeiz3DhKi/9vyohzclwvn4HlHkT7c3gF1diTAfjIB0AFea9mnGVdihYXT 2SHKv44g2Wk660PYDOBMdJbPLFJn6+4X2HUxOs/eyj5G/SMXBJ/xJB/9Ie18MK4EcfX14SFI Qyfzl2spuxC2AzgTPriWcudv/oZ3JqO3NxjLbw2fYf/G851JSjHeHLgO7w9MIWkRurf/O1ec eRa/UTyCGeASCxfQv0V4khUu+3cM3p8X5VjFONkbtNKHf3/+71DWJ4GjwCsA/vz9m3G03xMR Fqp/s0+Y+sKRJPq/UUzdrtvX687XBTH+zjO5OQnYufnB4gYiJDdliCsA6Ox93YewGUAkfT0c H7H+zjP5SEQnsPORgDDqSn185GHlBM2OGx/gP6bfeSYfTYLwkeyQj1C/YV0FjpYG0Y9Y7g1u WHO52Bt899uRDXJvsCcGIu4NXg8Jgb3Byd2nq/MLZd9qrMTneSbuAXb9YZTYGxxbMkrsDb7w /gixN8jwYHuDOahvOsD+0cECqsulPMvV+tm2bCADYPpAJ9vK8JaAzFOGpyLT4QjPA9jRrgFX 3D+cAsk5apn6YuFx14rC2WphIf3yPHIXLD+c4ni9cDESzwM4puVqodenaLMUfD6owe0ftgdH 3D/sAUl+pZ3L/cNuCMNfyLGe86D5jEz0f8c4kC/Qat231rV5Y71/SG7Y6ezccP+Q3JCvUiDQ yfXQMgR6ozzuS/3RkHcPANpe5z4+1vuH5IP7h3Y+uH/ohI9oz4P18eGN8f4h+eD+oZ0P7h86 4SOUfmyAYp3p/mH22FFiP+/pggqxf7hryxixf0jJfUBK7hc+g3hKpg8n71syQpy3xHWV2D+k 5P4hJfcNVyKeUpSLfb5XeleI/cNXT1SI/cMur1WI/cCmL40W+4P3jxot9g9bfTpKSJ7H/cPe n44U8TvGjxTp9eMjxP4hJfcPmS/3++6qHCH2Dxe/iPpg/7D9MUjsBzId9wd5PvcLmR8l86c8 D+Ux/j6Uz/RNUB/mtxj5/W/aP6wqrG//sFmvua4pvQ4DE9UpvV5WmwFVhXXRvnCiuqvnYdeu nnOBTFf7wkxXVaHcWwvcP3T1Cr+H11jVem12des1x/VN4STXB4WjXTuAKmA2jkcWznEVFXKt hPO+dHJsRPfA/mFR4SDV1cteNvf7LrTaqskTIeW5XCPd5zrSs6d6qucktahwjjqycJE6G6gC duD4g8JJ6jeFyMK/f8j8ZDl9EQ57oc7+YQX7MfrcLMiWiEsHOLZLOwFex/bAUiYGaA/Eym59 ZVlT4+MdLuPK8yr1pq7MBvccfhLI64eL7AWmA7zeBz2H21+jJmVLTuNlt1b9UKlPOretse5P C/T7x2Yar5dU6v/5to0hwxuK3XoKHN0AolLB3UzIJBz71IHZX7kysq9Tn+9EfyB3Z6uny1HO IsDU04TEafBPBLgW3gll032xabp+9S2ZBuU3l7czmq+crZ/Y7TZGH7hVyGFVlUJOvucO/VvE UzJ9OPmXjW0MnrezS2ujAvlQtkS+lIdQzh7Ey3L/89Rt+snydsZTm336qQy38fmdc/VrPm9n HJg1W9c/aWtMGzBLf+vmtsYHa2/Wh/yUKSTL34fjaT9dIOKPzL9ApJ97/gUG8zuF/PYMv0V/ aW0bo3TqAr36o9bG9e1u00c3b2PcsLFSZ7oNRYt0njft3kVmPpDM90ZIlsN4lsv0rMdfrPxC zyeBj6P8/M+jdMEY68bN1ghcY0I6OcYiWuniWpm9xPVddg0wQ/0u+x11JeC2YXOnGergTjWu wZ2WAF1cmwF3thxr5Xxylaoo91vlabIwSFkex/RW6mvZT7uezl7smp090zU2+3pXEeAGajrN dO3vtNj1aic5psv87OVsRMUfgfKyTRogXWA5X7hmdTLU2zvNVF/ttFjd3+m3ag3gzv6tWpS9 WB2bPVOdnS3LkfnJcuxzx7coYCL66jnoNz7Is+2Ti5HfPKC+e8mcX3+qz1ybZruXrF0jxDRm rU/G77fzeL/YCRx8B9kLEqLOvST3CVivUiDQyWtTjkBzTXXcsmivqQbypaGcHmYF6tw7FcRw TfV7ixu+V2/nhnHkhnyF4qYMcQWKpkH4bZJmULmBOPYBMwDqTBfNtF1wGPb9Eyd8xHJNlQYB dYX3jXY+GOeEj2jeSzrhowCXJ1a/ncd7avKRFoQPxjnho6GsqT741N6Sc4Z6jS0vpRnND5U0 uDXVyegbL4LTzsA5GJAglI0p5+Xd6HnGG2hfST+iHdn+OUiYDphjr7NvW5z/xzTjxzeLjYP/ 1dT4Wy/dOHRFmjHm37ohwxuKbdoRJDVGw/IhVcgktPMGz03eQ563vOWeE176JV+061taXHBM k+HwOuKRY5rTeZC6xm9XcW+oHOcNAuD84zqvRSzf+ZRtow6x/HHAEuAxBKyDpJ6RA7mmyrjn EcZ6hRrrmU+s1lQD+dJQTg8Azs8X6xrpmiozagWwD2QAdm7Yro0AuXkU0s4N48gN6xCKmzLE eZUhayH8+Z/NPOiEj0jXVFnH+vh4HGnIxzZIOx+Mc8JHHtLRSb5jzQfskA+Lo/C9QllfNF/0 HerHEwD52AFp54NxTvgoQDo6mb/kowphSwG7nRSrNRrq1vb2l4t58Mmnr26Q82B3DEScBxdC 8jpsTLm0+42ew70kd/Fao+F8t+bBsWIenJ82TsyDyovjxDzI8GDzYAfUl8C00k8Im5/tke3g mNIS4NhEvwxPxcnDccw+xDnuFvCQD1kJmYSwGzyP9DrkSexd7vH2pl+eF+85ruh6+75h7ZiN qv4sc9yFKHgdypb7HIFznBdxrFcpEOgC7/Vi9W49+53kS0PhPcwKxHWOIzePolw7N5zjyA11 MBQ3ZUwD0El9k2OYD2EzAPsYlquF3nd2wkes5zjysQ31tvPBOc4JH+yfdPHiI9ZzHPngHGfn 4wmEOeGjgGTA2fnIRJgK2PWDujYR4LoKilbWYoxbCY88vh/H9+K4s7IZsdIFvlUU6JfxdaUH h+kA+/hAyMC6NNLMOAQr5wDn0gOnAvT/XwEAAAD//wMAUEsDBBQABgAIAAAAIQAgOTqUjyAA AHzQAAAVAAAAd29yZC9tZWRpYS9pbWFnZTMuZW1m3F0NeBTVuZ5sstlNWJIlEAiCMbAJhLgR KBEtBZlkt4gYeFahBDBNwQtiLUrQ1FIay0IvSiyW8Cdpi62UoghYL0rlKt6CPKUVayqF1tt7 a1uqYm3rT2/5uU9bHnPfd3bOMgy7s5NkZrK558mX7+w5M2fOvOc73/nONzPnZEiStARETpqa KUn7GVHD+7WSNLpckko+PX0Kj2g+Lkmb3JKUJQ4QPFeSHkf6HJck3aI5n9mHR+ZId5a6JRQg BUElIBR3dYacIQ1F3A9y+Q//hqfNV4nHvgJ6CcRjx8gu5bjYdaOTr5KzJB/yGIpldzx+pSxJ A5DmBaEq0vMo1CtLLhnxKhCvAyb9nP8Q1h/54mQepyWmi+MQ7fDKGZmi3kznsQw/m5Yf/nPR sWrygpntIcAjFeKe/MgT+AxDnHW5HcT68h5LVZKk6CRE1XAxzvI/B7oexOPJGQRnan4s6bL/ ZUgR1xFxNEu0Dum87qdQ+CBw3vRjKJzXOhnYlHEysGewON6D40Uc2VFNfavxWw3ReJxllIPE ddl260BRENvOLvy//YlxCv7kyfDX1N1xrH+mYv26Buv24KaM9mDvw5oyvtg9rKbp4NjwxAdr ayiYelnvSawp1yMgb8fArwUHg1yvcS0NjssUsmyFXNej3AgoJtcZmRMRHwOiXsgCZzj26Njw xjdvqKFcDp0/o+ajprHhVbvm1oh0KSNj1QA5I+rHseo5HWawG4nji0CA/pIg7o/p/UGiH4p0 L7ribKQHQUcBzGjwdvDrwHn9O4IXXO3BCZkNwcWZjIvziFei8nCKKZ3gpB6gbP7tZb8qmxmr uiOblB2hawU3o3N5nsDODYzq8JvtWo0Myib1wLXgPK49uMY1ttQa2WR5xNqMbH7J20+RRfZn yuZ33vUrsirSuyqb4r7NyOAkVJgy+GlwIYOh0sWZJwMTMieUXnAxLsqzQgb34lqP83oYiyrk WJsU4TcskxqFqXExnntlV/YYpLHtFDvgk3k3KIeo/9zg1dKt0k34X4v4eNkVnQo+MZbfQQxI bJcZOE6a0zhJajs/SfrZ8BsULkUnxw7l/4vxAvzygXgu68c4w0AQ40xDaVIjDmDZZzo6OsDi oZUnInikLNTsXunz0gLFtouldvZ/gfSjWe7w8ilnPUNwagloqleSWr/R0fEgrvtSNuxEAME0 EutTdE+GtGaNP4yo1Ha6QHqqYdby6NmzHt4Qq1YOip4762l8t0CSbzzrYdmncNxd89zhocgb Dnoc+T9GGkNRZXjWP4flyO/j97J75y0vQdpenNsG8v/grOcl8KmgtXPdYT/yVsJ2bcVvkiTN W45qKeHoN+ctXzkoZmcyAaaqdORCZvj5scNGVx18IZt1LFex2wVOrBfer5ht8f7M+5sFmgMK 4UcRf4OPBFdOjR6sfvv6g9XMo+zy+FqQNgA2JUSQSLlgPRh4PK/ZF/CwH68FNYMor1fLF+Wg AnHKJK+dTHaNZHEMR6rD/6rIYLR2b7dlUdSb9yqwmY0frN/t4HpsmGcGG9YT/V4J4hrdwebD 34xU7EQjbKzup6LeWmx2qtg8nwAb5pnBxmq5MYONE3Lz7yo2P06ADfPMYGO13Ezxjg8/tGRN jZHcTJFmSpJ7UKwvnb7blj71Lu6/Gr3hHHgEXKtvmDcDaWCG+ob19OIYBiGbok+1IW0dSK9v 7Jy33Tb7RcVeOzrwOOYSGRndsdeg9rtkr/E8gYUburcOv6lfaa/dBk577S5wYtsePOkeW7oq WxwP/RQVcWRHeR4JUTaVGi7GWUY5iHqe1+2Mvfbek2/U0Db5YeYvFHvtr9XHamivMd0pe20h 6kx7bQl4FihU+nz2yUBL9oTSm7MZF1gQl/7I531STkU6oqYwIi7NoEZQKnuNuuutwdtS989f r4/ZX68V29I/nwAu01HfH4LXg2v7J/PmIQ2sy/1zLc4lJvr+WSEntwfMYDNWGitJTz0Qw2TB E7Zgc0DF5uUE2DDPDDasZzJ7wGndxX44/fXzih/kzRuz4fNLL91FP8gKyAr9IJQbMPhBDniW Bhd5RV90SnfR37Hst64Q/SCzfpQdoh/k7tackEh3QncdBQCrgQH9HQ+DU3fdEbzG2x5c4m0I ftPLuBYXp3QX5eiXG39tqLucsEk5X/kCMOFchnKj1V3MW440MEPdZbVNagabMdRdDsxliM38 BNjMNokN65lMd7F/dlav/2ekJjzpp88ayk2E1mLkRGzMc0+1Ra/3hxEzB/UvBV8MrpUb5i1C Wiq5YT1zcByD6IPCJo0irQnUmTFPi42Mc6tACHF/DOs4QZKWbTJERJIKcJwPxOOL1DjYJX4Y UV/e4yyVylRMRiTAhHnEhGXWgrRB6xdA/ZQgyrcbD9hb4560CY9RKh6jE+DBPDN40B5kcAoP 4L/jhE14jFXx+EQCPJhnBo8J0vz5TuIBWV30rk14VKl4TEiAB/PM4CH6kl4+uqJb7yvOCB89 7woZzfdncub2jurPHTjEEJmu6BHq1FwoldXgg8E3gFNnSKp/kXnr8RPMUI+wnlbqVi02Mq6d SLdWStL5ZYaIdF23DsENr8Z1rwTXY8I8YpJKt6J+StDLShSpnR1rzOBRh9lVq014lKh4BBPg wTwzeNRJsecHejzagMc6kH7s9cqSS0Y62155LgJu1XsU7f8oDfHZsus3o9NyTrUD98o51bO8 d9DJQCR3afDjXIGdk3OqrY1BZU614pYxypxqU2CcMqdiulNzqr3AgHOq/eBZoDuCr+S2B7P7 NATH9WFci0t/5PtA7J8iHVHL/UGcN7S+WZhafwt/0LERhr2zQFNvs3Yg9XcYuGwGnwlOudHq b+ZtRxpYl/X3WpzbDNL3zwo5uT/IDDZO+IM+o2LzuQTYMM8MNunkD6JvY8p1oRDfPfjKoBlp p7voy34ZskJf9nFwMPiyq3xjS9/yib7olO6iz9o3/5YQZfHMIzNCfPfA//S0kEh3Qnfx3YNX gcGnwU+AU3eFSgf2PRn4k29C6R4f41pcnNJd9NfmDK4y1F3Ksyahu2z0ZT8HTH4IfI6Aa3UX fdmHkQZmqLuMnjV1RXeZwcYJ3UV/NbGhL/sIuBYb5h1GGpghNka6qyvY0A49dN8CQ7lR5iwn vhvzB/3kGlvGPB9u/BTunbb4R+BabJj3AdJSYWPHnEVgI+P6VSCES/xBmBOcXG2ISNfnLJyr nMIFr0qACfOICXGqBWmD1h9k9ZwlFR4RSVr1LZvwGKbiUZ4AD+aZwSOSRnOWtw+uUuYsH1/9 UNqN+3wO5IJwcc7iBwfDnOV6/9Lgu37t+CbiyDZlj5fjQNrymSD65upBERBtUb4nPxHxMSD9 +7DH7l+jzFkmLH5ImbPceHytMmdhuhPj/lEAkAscOGcpAI/NWZ7xtwc/8DcEh/S7I/jMJbg4 Ne7TFnp4blNq/S3GfRvnLGfQbpyzUG7wB4mIvdPGOQsTyIx0lZH+7srYZgYbJ8Z9zkuIDecs emyYZwYbo3G/DUWsA+nnc3b5WzhnKfnv1tA3vIXhRY9tSTvddSswLYG8cc5Sqcpde3BoQahs f4HQV1bMWZqBeaOKe4WcfO5M+9N1c4thH3XKNu8HPGibEx/8xfsobfNiFSujPmqHbZ4KGyf6 KO1vYkPbXI8N88xgY9RHo4C6CaTvo0Zyw+eR/C6BzxNknJvI/pwhRbc8ZJO9FcAgPRLXrQAf D66VF+axPkwzkpcZSeytrujznUPfCv1t2CkFj6m47kQQQtweRzPBlqiGU/HF2FzluomGyBTg eB+I91CkxsEMn9POQX47TlgK/jvwr4LzfDHWMa8ZP1kXI1xYTyufr2ixkXHtRLKCZ5MPP2KI SNfnKr9XMTmVABPmERMwQ0xQPyUIHd0XqNJGjIKaQJ3pO2bwQNm1223C4y0Vj/cS4ME8M3jw 3hmcwgP4v/SaTXj8RcXj/QR4MM8MHk7Lx63o3qdswuNDFY9zCfBgnhk8UD8lWCUfPTnWUJdy rDkNrh9rmGdurLk3IR67kLoNpNcfXllyyUhn2Z1/HtmhfNc9EeeOUc/PAmeo39QnvPAnuaGy C77w6s/A7AQ/80he6Olf9g3PHtTfdnu5I1aN+H8hHxiy47rEDbVah99BEgarFvBPgm8B532c Hv60Vw6MyJEDf/LeH/hEjijDCru5HuVHQGyPZHP+6g154beO54fem5OnPJO78CtfOPjPASGR fvmcv6OjHGX6QBAX5V36UnDc5iSF6eK4VUXeOO7zeAaBm7hXpvcHiTJFuheFzkY6sRuHgtaD 01/yKDix2xn42Ls10JAzPhDJYVycR+wSlYdTTPlOOB5sA7WCYthJLhnxKpDV8vtb1+cVuf3n hkaFL3l1iSK/r89clpby+0dgQPk9Ax6T3w15ciA3Xw60590fGJivbQMRx6GmcBdyxf7DNqgH RUCp5Pe2vvco8pszuClE+d153X2K/DI9kfxSXkmoVlKZFXU3K5sfojTK5jlw4rIz8Ie8rYGa /PGBqnzGRXlWyOY61hzUfdlMvmZG9nuF4eCpTaEbsgaEDz65VcExnb79mQGsR6Bx5oGPBQeT VpQ1F7jKzlnqe3ACa2JMrM//vjD87a3pi/VcDdYuYL287IylWO9CG1LvWiXXU1HWRBB1thuc gfMVfp+1Pigp32mRf/iKq4bpgjMfeiODfT9dZH4M6nIEFboKPBPtcBc47yk8tCXbV0LyucJD SS2XfOMl9A4O7ZIOdqpNuC4M20JwtoFoK/LYujHp2SaL1TbhOj2xNtkz2FdCaslme4SHWrOO jBgXnWgT+sSkp3bUDFh6S5yzfzBdcOanYz/xACj2E66RNQucbbJlTLG7vorkc20ZQyp2i77B MVnEcWja9hNiz37ANhGcbSDaSuSna5tEAC7bRPSTLWP2DK6vIhW72R78LdrBijZxYuyu+Mf4 8I8f3lzzveeqwluffjztvpH+BcYKjoO/A78VHEw6VLkzq7Iy21L5r0e5EZCRrb5/xrXh4Q/u rFlZWqXolMD8qvDcum/ViPTLbXWp23NNVEkJQq44pvcH+UCMi3Qv+r2Yax4HSNOR9wb4THDa 87MqK925lcXuwZUnsxgX5/UWe57fwnINPHJ1LO3W2kvoxpZ+y78C5Q0CPQCifqCcHvBsyjjg 6X064d6vrQkRa/J0xDoH+BLrvuAC633+TRn7/L0Pa8oz/amlW1aHYuvddW9NMTvkegSw9gDr a8Fjcr3GNdNvzZpirK9ZX8nPb14d4np3lEuuKTbEuzrE9e5EeiL9W4rySVCPlvhKsoDDaJTm A78OnLp1mv+Ca59/Qma1f3Em471NtxJPymAonJGWMrgSGFMG2d+FDO7zr3EVep2Xwc80uBSZ Y7+lDP71jQxFJkW6EzL4FWBBGfwaSMjgCO/izAOeCZnF3gsuxq2UwWZcpxFE26hCjvWnIvzG m8g1ClPjYow2+q7RibUGVqE+rN9G0EgQxAbdP/aOGfOIDfVYLUgbtO/DWr3WgBlsnFj/ajNu mNg8DtJjwzwz2Fi9/tXovZ9V7I2elpu3cf/E5mwCbJhnBhur5cYMNk7Izf+q2GSiM+nlhnlm sLFabo5d8/VQOqybVgZMqoFBFXgEHCyub5jX29ZNoz3AddNoD6Tjumm0B7huGu0B+pGpy/f5 T7oLvc6vm8Zxn+ujUb/T50t7gOumiXSn7IGFwID2wBJQFmiE9/nsA56W7GLvzdmMs3/SZ+CB ZPZX45RTkY6oKb8hbXWz9gB1Vzqsm/YO6kx/yBlQPUjbP5k3D5TKHrD6fVYz2DjxPus53Dux 6QDpsWGeGWyM3mdtQxnrQLQdr5ZjMoiftu2VwH5I4nw6HddNo5+IxPn0WnDK3QHPAc9Mv/Pr pnHezHXTqO+5bhrn01w3TaQ7obs4n14NDDiffhicumua/xrvPv8Sb7X/m17GhY5yUndRhtJh 3bRVwINrg20EUW4AEzT1xbnMcvxMpbustknNYOPEummbce/E5jsgPTbMM4ON1eum/eXQjlA6 rJt2CwRlDjC4HXwxuFZumLcIaankxup3z7XYyLh+FQgh/l4+6zjBxnXT/gUXICYLwfWYMI+Y sA61IG3Q+gVQPyUIndQXvZE2URTUBNKPcxVycn+JGTxQtm3rpi1W8bg7AR7MM4MH753BKTyA v23rpi1V8WhMgAfzzODhtHxAVm1bN+0+FY8vJ8CDeWbwEH1JLx9rITPNoM70F871xXflU3Hu RBBCXH9QnylrENi8bhqvfQpUB/oIBCjiYzLzPgCl0q1G37BGcX5ndYkWGxnnJ9KtlTaumzYX 1zwF4rxcjwnziAlxEvKAqBK0uhX1U4JeVqJItQMPtJ9t66Y1oM6nQHeB9HgwzwwelC8GPR5t SFsH0vcdryy5ZKSz7Tv/nnfyd2lp73ENAs6p0nENghW8XwgX51R+EPveAc/1/pl+59cg4NyJ aw1wTsU1CDin4hoEIt2pORXXIOCcqgCUBTym+Z/x7/N/4K/2D+nHuJApDzSXU/4gylGqNQic ej5EX9BGVW4AUVx/r2IcCan0tx1zqlTYODWnIjacU7FPabHZbBIbq+dU9JWl+vbbie/i38H9 9wMgxKdEhw3zipGWSm7s8COmwsYpPyKxoR9Rj805k9gY+RHXooyu2Ium1tm1ec2qaaj7ahDt oA0gwBTXN8xbD0olN3bYiwIbGdevAiHEbWnWEfaYbWtW0U4kJp8F6TFhHjFhHZy0F1PhEbFx zar5uFfisRikx4N5ZvCI4DgGMbb3hZRxft4T9iLX2aW9mI7r7NJe3AGivfgsOPveAU8kd6bf +XV2aRdyPV3ai1xnl/Yi19kV6U7Zi3uBAe3F/eBZoGn+V3L3+bP7VPvH9WFcyJTT9mKqdXad shc3A5ONIMoN9ZLWB78dPylDRrrKDnsxFTZO2YvEhvaiHhumm8HGyF50WnexH3Kd3ecaCkLH /6PW9m+YAdElQfSzTKSKuBvSRl9AKagV9DKI7z68Dk652+ev8o3Iec3SdXZpazWC6GOokJP7 sGmbp8N6su+grs+BzoCOgABPvI8y7zAoVR+1wzZPhY1Ttjmx6QDpsTmHtMOgVNgY2eZRnN8E 0vujjOSGzz56ch2RBRCQkajzneDjwbXywrwqNc1Yp+MgBNFPhb21FmnsP53B4/uNV8rpsGZV H9R7KWgo6KsgLS7M432lkhWrnxtqsZFxfbYNwiVzlQk2rll1JS5GTIpBekyYR0yIUy1IG7S+ bdRPCXpZiSK1s33HDB6w+21bs2oY6kw82H/0eDDPDB6onxKcwgP427Zm1SjcCfGoAOnxYJ4Z PJyWj1tRVbvWrKpU8WA/1ePBPDN4oH5KsEo+enKsGYo7YV8JgPRjDfO6M9bswvnbQPqxxitL LhnpLLvzz4KSr1n1Rv//qmkIfT505bx3appPNCr8g9y7Q3OL/1IT2Zx+a/58Aff/R9CXQGdB WaBj2VvyAp68/IDnF3lzPVc4vubPedf/1Lw5/Z7QNfJHyvOQE+Vv14xYfl9IpF8+5++ZNauW AasPQV8GnQMRuxbP6bwVnin5V3iuz2dc9E8PrO3+yPeBOBaKdERNv1dMOW4FUZbtlN+31+Qq cptRWKDwe6fnKfL7qzcKbJ/vdeD+tEHglIlEEXcDszr8DoIovy0gyu8WUEx+n/IGPMNzAp7T 3rmeaxxfc41yuqA1X5Hf/G2FIcrvnhcHKPLL9ETyW4q6k3BrkxSmi9OmFPdP+UkkS16cPBt5 xIWyuR5E2XwUFJPNv3tXeOblXOGpzWnx/N3S90bX4RpRUPdlM/lzdvpzGkI3hSiPzSciabdm FTH4KagNdBLENmvI2eI77c27ZC8b0Y7INtX3y3GgD8Q+QLvQCayJMbGOvFQYmvhs78D6tHeL rz7HZynWWvuhezo3JtdT0X4TQbQ5oMeUwPkKv4058eJXlG9kyLkGD9MFT9c1q6iLrgJVg+4C 8Z7KpZbsjzJJPle5ROp9a1YRe67twLYQnG0g2krkQ5dnEIN0WkeM9VkMYps8hh+xNtkz+KNM Uks226NcsnYtCCf6CX1iXA9p4YWX45z9g+mCp+uaVVPQDuwnD4LPAmebLB9Q7JaLSD7X8gGk 3rdmFbFn/2CbCM42EG0l8tOxn7BNImqbiH6yfMCewXIRqdjN9uDvMhzD8deD8VrE8TNtx+4N BY+EuGbVqjVrQ+m4ZlU+cOc4OBScfgzaSTv67czq18/5Nau+f7AlxDWr+C4i5Xb17x4Kcc0q kX65rd4za1blAavpwGkA+Exw2vPX96t0f+Avdl/wn8xiXMgm5TTR/ACnmJJZx2xMPEvk/jd8 lqjuf5NWa1a1ArAS4M1niZUgyuk+/9CCETnW7n/jhD3PuRPXoKVdn47r/RKDEcC4DXysinVD TnPBaW/vW++XGBNrzp3Scb3fRFif9jYX1OdYu95vM9qyEUSfQIWc/Bk598588rHvGe7rFP9u 5c1Bk6SBQ26QyKXoZBSvhovxAqT4QBCjTu1Hk4sOPhEnDQa/GZzni/dYmHcTEsAMn2NZ/R6i FhsZ164CIVzybA/PDM4vM0Sk6/vRcB9RYsJ9MvWYMI+YEKdapVoX/2mf7aF+ShDjU1+gyjEm CmoC6X3zZmVFxrmJ8KiLfbdiICFdx6NExYN7PejxYJ4ZPFA/Jejx2IXUbaCu4nEnzq1XSr4o H278DmHVi0XSAuleSXp//SRpe+QGaQ92nyUPz1B49AffiP3+1PMxnqRndQ23JahDH2BTC0EZ BX6bKjOibzFvLtJY12RyNOfS+5By8Zv+MNg6CoHF/aNCvtqQtg6kx9MKP04Q5ZaA6MdB9ZXA fRL3fPc5ZS/So/kv2O4rVy8bZ0KeiIuIA9P4u1GfQkUXAedj4E3grPfJQNPApcHhg8TxtB1F HNmm7MVyHOgD8brs1/WgCIi4J9uX5NijY8Ot8w4oe5G6bn5B2Ys0b/+Lyl6kTE9kd5eiTBKq NUlhujjvR9Qdt5fSR869SO/BgdyL9H7wLJxzR/D9ge3BikENwbpBjIvyiEt3bepmlN8IIi4V cvLxkHL0iH+vbjzsiOt83qcyHnZjL9IOlDEQxHYrAon7ZNmzQHNAYfyoAy7ci/QOcPwBhYt7 kfI7cR5fy3RN0Op+o/FwLc4hJvr+2V1suvvOmBlsuN8oseFepHpsmGcGG6N3xtqAy7oE2Nil u7gXKX043It096GfpJ3u4l6kq4E39yJdr8pde1AuCpX9ukjIrhW6i/LYqOJuJIfci3TK3S/q +ujFcRfVhC6cKUmij75WbLgDWgGO94Fwa52yWZ/AhfitOfciJT48X/RR5kWRAGbYR61+r9MM Nt3to7zNVPqL+40SG+5FqseGeWawMeqju1CHbSC9/upOHz106JDhfmjjFz2h7CN1NLhb4R9P 3aXsJ/XMI7tt77OoG2GPB9HvEtkbQRwlbORPAmvqSo6vp4e3D5ADUwqxp1Th/YFbC0UZVvTd epQfARnZHdz37It/3qXsJ1X71z3KflLfWrlH2U+K6Xq7g+1RjjJF36T9QYL0JLVBRiK3CKT0 RXCBm7hXpieyJbwodDbyiB33Q7sFB9Jmm6NitzNQXLg1sLJwfKCxkHFRnhW2yTpcMwqKYSe5 ZMSrQLRvwaSf8x/C+iNfnIwqKTpFcKaL4xBV5Jf3UKKm8zgG7jnV6Dqq7DklvfqKgnW6PDdj m3LPqbXAmntObQZnvVeUbS9ylV3R654BcM8pYs09p37/QvpiPRcgb1KxdgHr5WVFlmLdjDZs BFGuK+TkNjfXB0kHH9RU1JX+ljpwvX+BeT3hg9JiAwgT+lwqbfRBzcU1iclt4HpMmGfG54L6 KUHozL5Qd5yrRkFNIP0YblZWZJxLPYkQn5+hqmw/rp1iiw+qAeUTj7vA9XgwzwwelC8GPR67 kLYN1FU87sS59SCEOB5u/EgHH9RNqAd9UIvB9T4o5v1/8EFxDRH6oPhtcTr6oFYAZ/qg+G2x 8EEd8DQNnOl33gfFb4jpa+I3jfRB8dti+qBEut4WRNW7bQuiDCWIfgcYUtqCWTiIfiofSPip pvnfH7jPXzGo2l83iHFRngcqLZFticuY8uVRJ5odMylrl/upLvZ72k9OfX/M+cVGXE/vi1mF NDO+GDu+P06FjVPfHxOb7yTAZrNJbNLt+2P6qfjOQDr6qVqBKX0NfGdA+Kn2+eWiETk946fi 98fp4Kd6B7jQF3NGxQdRaKSYL5l5ZnwxVvupzGDjhJ/qHO6f2NDvrPdTMc8MNunkp+I3UPRT 8Rso+qnI6afiN1Dp6KfiNyS0o78ELvxUx7LbBwQ8UwoDntzCuR7n/VT8hoT+KH4DRT8VvyGh n0qk622TnvJTLQNm9FN9GVz4qVo8xYUrPCsLr/A0FjJupW2yDteJguz0U/FdKfpO+B5POvqp iAH9VG3gwk/VkLO96LS39/mpiDGx5rtS6ein0mIt/FSnvduL6nOs9VN9H23J9kzlp3r6oCfM bw+4F1Qjjl8IQojPtbPxYwa+tl6INz5KpGpJ2r17ktR2fpKUO1F5/hTdsCb2HKr46djv3b+M 8SXvxdKTvPlRgHJ9IIid6edTjTh2JCYBPIfP7/zgjItxn3l5+Mk61zJdE8Qz5DlI095PLn5j jhOnLPUcoWOEX+ffkE5MO+PHeGDH1Z3AtqbHseUzLOL5hwTYMq9z2NYo79TYhS33S+pNcrsI uBLbVpAfpJVb5nUO22pbsV3y6pKQeWx7Xm7PqXheBVD12DKvc9ial9soym4CdUYn0Mdx58cn lOf8Ms6tAiHE9S3lolySjo6arGjZJNqza+/NzULZB0E7cZEfge8H5/WE/mTes2paMv0ZwTGo nxLK8J86XOjIKOJ24LEALuRrbcLjMOpMPI6C6/Fgnhk8UD8lOIXHKEm+/Sab8Pgp7oR4HAPX 48E8M3iMUtC4/FlAFOmdlQ++u9aT/eUBjHvEIwqux4N5ZvCwsr+YweN2G/vLKhWPBxPgwTwz eKB+SrCiv5jBw87+0qLi8fUEeDDPDB7J+stQoOQH6ccX6uaFIBSv0I14YYayKX5Pwe/n8HuU tBtHiHDxewZI82SRmowPRwZ1O+1m+vC1dXHJsTwkK2PrAEYQ/CDG/08AAAAA//8DAFBLAwQK AAAAAAAAACEA26+ii0MXAABDFwAAFQAAAHdvcmQvbWVkaWEvaW1hZ2UxLnBuZ4lQTkcNChoK AAAADUlIRFIAAABrAAAAeAgDAAAAwiP8CwAAAwBQTFRFosTZh5XE7PHyirbSxNbfvNPd3Obp 1eHlmISnZI68rMrakbrVGzeP+vr6pbLP6meF8sXQKESWlqPJ5FR2daXIsc3bd4m78fP4OFOe aXy09PX2xtngrWiOw8vih6PGzd3iapfB77HA0N7kncHZSmCnuNLj6O3vWW6t5Ovs4Ojq7ZGn hLPP5O703ufq6+/ws73Y4ursVX605CZS8p+y2OPm09jpyypXyNrh8/T1wNbfusza3Q0959fe ttDc7/Lz5uvtpLfQlr3X9vf45z9mpAxL4xBA++DmXXWvmq/LLkyaXIW3Q1qhOV2is8bXytTf 6n6XTnWv1uTqvkZwYxxo4uXxmb/YRGKm3+vyfpO+z5mvyKy9rMPWvMfaR26rxoCdy9zj4+bt P2WnUWqpz+Dq2BhHkq/Nzt7mvTdlu8XV7+Pn2d/qssDVydzlyt7rqb3Snq3Mx9zpz9rj8fPz p8fa/fDz0dfnpbDT/e/yp8nd4+zvYFeY4QAzf7HODiuJ////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzblzxAAAAIB0 Uk5T//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////wA4BUtnAAAAAWJLR0R/SL9x5QAAAAxjbVBQSkNtcDA3 MTIAAAADSABzvAAAE01JREFUaEO9mu1D2tgSxgMIVCBqEMOJyItAiYggKi5SCyK9NYZEKl21 3K2sK760V11tcdfKGsK/fuckARLEtveDd7BCA/LLMzNnzpyTEB3Vtia0F8/4RGjfTa5sPSNF /eouq/P6HfncsB6r825WfmZYn7X15tv/jSW/m3xmL/Z1dSberjyvMB1LHn/7vLmoY3W+PTyv F/WszruHlefMRQNra/lZvWhgyfMPb/56vvwwsDpbpw/zz+dFIwsi9vB8RXiA9W35O14kSW/K /MceWCrllUv/s7MHWPLKw8P4MC9ubPhvTAzLcizLNvBvmr7zX/xvuAFWB4Q9DBRhkrxYrEUF lja5i4ef/ZWvlcPPl2Numm4I0Zr/b/KnK9sgqzP78LCsLx+pCzfLs6bL1Y2Yudk0m82xWCyF f1rxTIVuCwJjupj+OX2PWN/ePOjKx94iy7voynSpAN8PtjEHlk7HwZI2WzzOsYeBRpQ7LPwM 7RFLBmFa4pf2TFGqza42mypIpQFOgSXTrZjZJpgK9lfgYdPGj135iNUhQdhbnPirpijDIHep tLbWXGs2m/DUbBYKqRSmtWIx/1jAFKi5XrVsSft2Q3Dv/UjbY1ZnYh1C9i3lRkzlUhi7qNyY ajQHBqlXc4/5v2bM082mPRBFcCoMS1EN+jK8kCk2kHv6+3VgCEseBy9O1tlK7LOLYoUoy9SA USwqTMi9BlsrFgV2LAPykvEwINGByZcMbgsN/3cdOYTV2XoLsJmPtOBquC8rf5AyPEokGLxo xiuf3bTQbtOX9rlUy2ZLbwv2EZOATMGqj0a17zlyGKuJhT38Y6KFObI0DSECg1A1C/hlc7pU KgimQzoqcDfZ1Jwt06i1bMFtdHBdDX8UhMrT0oawyJrrX8Ba3qq7S6mUWeGsKYZTo2BOTV8L G6lm7NDUQFzRZi6iSiYMoqja0clRjV98sng9ZsW4NvUeC/sUrTZVFGCmwbRENJM03YTUNzfj n2kkBL6yNVs4XG1di0wueDKGTN4nEvIR60JoMyNzkPcPD+9Js4KaVkgKDSszy5y7iUd1Oj0X s99EBQGFW8HL7QDXRmyjgdqN2PB8HGRVeOoa6s8s5P3D+koJUFhTSTUNRtK1ZiymDOl0rDR3 g9rRhqDkK08FzgLbrDC8jAywKlRjNTUXb5mV9FifKJl1qC6MdLPTSrmKmdM7Aa5xgNouzmoP np9YBRqerJww1I1G1t88HW/F4+l0+jXO+4fl16SqCmc8SSqwtcLaKgqbUwXz3CUtINZ0/TUs 0A0UOAlnz3eowFXOelUeqszAuuBrsXgSWHNz5nnMeniTKvVRGqxZKLG0nDqkDwRmLJxMpW1z NFd1841Le/YkgKw5ay7HCrHHCaJnxQQmHbcprFZKTY+HcRwnVVVXWLNAVpCJRUwxbYbKYctk Mn60kxxhqJovOCLUzq3WfJ5jH080OhbZQBmbTWXNbXgnFC8+vCtpNUNWWKXpNZK011xt90Wz OQf13gYsu42lbfbqNhI+VgNCLgcsh2B6NKj7LJl2HcYBloRwzc21FtT0gPlFUSSDqTD5gkbc IsuspTAKWACzjSFfOFjNMVTglXANrKl8hFoczPw+67BNp+GvNFYsNV3E1QNsRcciFZKfJDOI SaV6rMxXYawazB6dBHhO2PYBayof4FcHQtZjXVBUBZ9h14epwlcXHmSQ+bNYkSJLLpgQVymR UKcqAptMKbrAh/YWw9mD2WzWvnPQPrvCLMdLBg1kfpdFMi4mbe+zYjHzRuO9GrLTCczBuEXU 8Msl6DpSqUKSQ4fmOegEMCtZFLLA8vmCOy6q6Mvnpxz3DrFmFNZlFQU0ZuuyPpgXoIkhA0uT qhffKjD5Dw4VSXKtCeU3lYoVUjWetpvjCsseFophhbUtMNSZT2Gduf42wDRWAZkOKnaN1Xq9 MjHx+j//+fzPb9DBqcpA1B2iN2RoCHCpxw3IRvOwgUyZmA2zbBxTBR8Gc4g+qfG13JTj9vZ+ NGqo+SpLrnHbDfgL7ENbMp1ZXj9dBls/VZ2IlS1w6LNMTsP0r7E25mB4jUVR7VUmHa/a3AfV c/vJtdDI+bIBV80KLIJAd3phKmuPtwaYMGYBLB5fUIuG3k7/oVOyVnwVF0LtheKbSo6xqFG7 2am84q9fbXMUk/PlrL4AFcoD6j5kKB8KS2aYFs2ALkUYjGWb5js9bQX7T5stsQsBhZvEudgr NydEEXLx0JcWj0ZyVrAAFZgiwA7cOmEKa4/faTE0druWiAvQ1j+yd6WSMi9r0VK6RJyGybTt q/XzK4a15s6DI1A1oGxYa66Ag4gQHqRrQDBLhtJpY+gqOFGDfbCp1dBo4wWYzzAKZEG01JEM brdn7GE7BCx75PNprHx+lLfcRiL7x3f96oFZe+jyqFrj4A/6wpTJctAmX8NMraF6spSMDwft H9FOjwVDeWoX7RORSEjol0VgyXdsMFs1ceGwAlPKb3JBq4ZG3PIEdDtKvivRUlyosU5eoesj VRaUDYfDQaA6Edl3osVexIBljp6Fs3Z3Q2NhWDzeej0kPaBezZu9C9r8b0AFj+yNQBCzcJUH 1u29kxolNvfLjJ61ikZgEO4gqwJT0h7mlSF5r2icfG1Wlg8GVeFg8KjKMMERNVzgQhhd9zVK ijgl1CvBoKtG232+bFDYBrcrEVOLfUsrUINBW15ZWFAXKn0PhoNHWXuNVXRhWcCChL/fRZtO J99zItEho9sQ0+wJFBmdF5PxDxOnQ9JDlaap6gYLo7LhwAEMLk0WZkUiTn4JWFy33BMdv5Cz Qafi/XpYaja9sPrxxjMxL575J1aG2/wEWUolk2atP/UWml6z+SR7jZTRlbcttFqtD4qNjFUJ 0ZXSIkZ0ipxvAc+6fduwN40Hhvxv2mYrGQ5Xfa/QDtQna95rOO44bnerPSFzgVxMduO1vfrw y2l7QX+g+0b/mXXLa5hVw/sC+MFW5OqIDxGYNVUie8cbF/J93dWdxoi9aHFkQWbbPbuR0+GC /kD/rd6rBrAy0zLqHVjELOEsi1uNEsn3jvvlgChyXR+uNqasCzIzyNIdGMpqZoAFyzDN7uRM biTqzuKEL5H944dyw1VGWukg/AdWa0wv4+4ndLFyM2M36rKP+A7c0NXkHSWyr9cvcy5J9KvC CBPjs7aMuuLBgswNUdM/JKgsvS471qWx9Lpol1S/0Vh0yJdvGXXFj8zyDcsyHDwYpu/8NmKU IxxzIxfsg7pyuWgANzX3Rl2NdrlMa6xGIAcsQ7wwC5bG+Af+mfpyTEpHqhxXWAZdVmDloGTc 6uPll+m6WDZprOiZdWpAly04579LwToPmqmSTOtZa4UL902MNBfS4bAxXicay3HrNcSL8PBL rJocBCrmgWXQZTs6QrQtiItjOCbX9Ky4/esNrPntNqidawZdJ1Yr6MKV0JiHhCQeN5QqdUEg YuqRLrtJCMOX4VIcM+qK2+3psBtoIzb7mmF8neSBZYW2kDDGi5CW+KjSCCxiliNu1JUcQW57 ELPC4ZRR1wfcAFXt7gPEfDTG6zxvPQhYYd4ivIbxRUghV0PZaFwFlgNYurpxJ5trgi8IBqjg gK7Z6gk+A1sYWjW/Qdd5Po+28bwVMeqKSJJLUDc1CRRx3CaNurIoYM8eKTRgGeL1ZvxPgAWD 59Xwq6QhXudTU3xx6hZY00ZdHgvFayzqzHE7oIsRRmA+yh4dHQWPNozxevMwWTkJwjvwAa8x XrkickBqPI5XQkQay1WbIgZ0RVEu6AMY4LKtAV2whP58gs8k6/MadF0HaP7sLOCpsXu644cy 4UnUu6x2GbMM8YJFtxWmagWXHtQFmwO//YlXJL6CQRctUpQA2ypifc84viRgqQ0pQR3fRgZ0 XeYEAZRhmO+xLlhI/PvPK4WlrxtXU9xuxFncJ6BG6esh6FqKql0AIbicg7qqvhFQhmE+3xBd 0HGM+658I8Z4fclHRyFYRMQ5UDekRK9uMO0QUTXmod3qgw2Ka+iuMMuYh1q7M/n5C8zmUd38 lSVQ4Baaz31gGXRJUt2k9tkE7apHqsZ4QWnzXXH8WHjEN2LURcI1ENWWf/uin2FpeeFMbeCd 9/KFq3cOF6RTSux26/wd4qUBXVDarCNXNBWAnjlu1JX5vQtb//2Dbgpw7cmXx5uR/U3nvVcO 9FBUrGSB3OjOXxficf2DUReUG7ArN0WP+JLGPLT7fu8tKsZlf78scyXZfAINdlKWD/tHWfmD JElCd15ejYaol8Z4nU8pMN81OthZMOo6yX35rQs73dIld1s4VFu1PVPfg223/FKSPLy2XUR4 Gx7BbdR1NJWH1Vre6stz/KJR1zlsbHUX7A/vZLe+UxBo942JpXSHEElaJEu50e2j5NquZ2yg HkKtwbh8LlcLGHXBvpb1y7W2hFne+kFrtyh/kaSEqKUG3A+weOD806gre+vANEVdxqjrCJ+C dUdbVozLe3oZg+2QSTZDZnj6fS+sKj0DeegDlkqbmrIZdV1h1lTeMaOm44q813iq4XK5ZRIm lMQx1V0yw5qILVdl3V/cyDkCpgaMA6sadWUxH84jr6bjOmwO3OgaLR2XWZVLBKBG20x3QwVY d+gE9vNclGZ3wCIw7V5lmXrvwJn6tFNw3P9bXTGNf5NLhwyvyz3gueBCjizbNiHfJb69qKUG vn9jgX9pXIjkIioMxN1WB96CbSbHPZwHcX/ziwI7nd+Cj1zcwQXGKFiDo91+aPnkDw5MAg/2 dx2AVeIC3gXz+aoX73hd7JnNLyMYhu2W+ALrMVhfwU/Sv9okc8op4EUjcX+tXDGAsj85PzGw arK9hEgpKFSne5sOeM+hgqSEc5TybDo3nWKI2N+PgGk0VR+WSIzyYi0yBaVcMfjEx5nusF5/ +2Z8/k+8uqt+yTn2EwpISkjHvAdpRQPXXvjnFcqJhKXOS05nQgxFNjc391VeD6hodERonl86 u72Hcq6ZpkzV98sLqBHw6JolxCOpfNDfalP2iK75hJRIiHwCs/adTh3NwLuPeA6og5CFuCfg XLZffOoWYvV5/ZOpB5Is0q6rLiX4MeO+TaeERgEmiaIlgTALwzb3QV1EldcziNJZGfHHocS+ e2bI0n39fUD1XkJaoviQJVHWbduo9xHJd7ziXl6UxJDTYgGaysPOHLDIfUTi0K+/9Mq9Udvp TACiFapT/Ch8YQLqaTfju/cskRAxgHkQQpgFNB2vz1TYTvfMsI2xHvJ0hhOp4xDWZimL+k16 bV90kYKzwG5sh5yQJ6op8gy26X7x/ilFfX3rv9Ysairyh31VvXuxZLZuUd1IgZd7tEHc5kx3 U9bouYH/nb7AXwYTMjdkvxcWLFQInwqMc2oUTgrjuvIUjyoPQL94ajNHJ+s9DhkuhbzxSml3 z1wO4PSAyaZcpnaxPzFOJ1Bzq8V5ZhhTj+Wtv38BkVJ95DZe5ehddyg1sBct9bozRIkKDH9c BapM5RmO9KrFED+uvzdpRQNc1Bi4etO/nrJHlWHC3j2GdBT5UcXhfVM5mpnUqvvYTmde9D5k KfPdfShdnddeyn4IGWQplrOEh7yRpgdLw6T98h5qVM8sIcqQg0ov2k9K2c17oIZ5AGLx8CDt aZo0UJ7WP828MJxcwsMHHl2M1V/XK9EgilfzUdql6p4BRxqlGRLyxeCJUf2ppKfGcL3Syxxb xCUtL0IitfQ9RwYMCTljiK6EmCGX6g0s2GYWl0RNTSIxSqEy1OunzPKPviZ+Uquumr5ir8cY Uje6h7wsT/VmIFysYQZ4ImyWJWpUX+tPuzkIA4v+ievLHbnAtJec/Wzy7FJiGZfRQUskllyh RMKky8h11Y8JDzVUlSEPVW0lGipi3x0WzxJMxp7B0CcSuxTMeWCm931P/gIDGTK59sSdDsZ4 KbA7F7QEfR3gSQRzhG4sK50E1c3ShKmfJKcz0i7vfuoOjsesDlypPjaku0UKHVP8bkiCMqWc Ax5+eBh2c0Gn7V//PBrCw3O+e/SCGUiJhMVTPubR7ijgIHqjA2UlIQW0y6jQL7578kbQIbqw H8dAmjEjLIATeUrc9XjqVNmJJWrlXCnMUu2Tdjn6YXniCdpwFsxnNL87MLYSkDKhJbHtaqOl 0VEPHhpQ/KFP84TKdVGkXL++0WbSyYmhd0w+xeqQfhZPZMZsT1hCx3y5vCtCY8KDiaIIvxEv 1ndFnrsiZ8dV2vJQRz7J6sheuKS75MFqujmQ8BzjKonVeEBNaHRpqRwKgcLQrsguluQOSU68 W1bGALT5+pKhvH6ahRviQ04QoffC6uAXZGM/ito8ikM1KoqMv1cptmYnlbK8PDtI+y4LaH/D JujuKMTGA6OsDqNMN/AgJyTPaJ2Pmvb0o5f8tqWIe/tmljTMKz9ggTiyYooeiHwbogfdja4n kELlY/EgaroYcgsKiMNN5OSs/n7yH7MAZ14t0qzIi8e75fJoCOJUXto9hoxg3TcXT91UtrU1 r9wXN2u4NvoohsMOwM0ph3DHKM00otEDlmZMd4cX3pL8vXvlSHJrHkZBfwD8lK6fOpuhH9qC vHw7PqF68plZnc5ff82OL4/P/gVZ8uwsLAgyZR6y5P/CAnVbs7N//Re8cRV0pEeJrQAAAABJ RU5ErkJgglBLAwQUAAYACAAAACEABDhASaMbAAAImwAAFQAAAHdvcmQvbWVkaWEvaW1hZ2U0 LmVtZtRdDXgU1bmebLKZCQYyhAQihJBACBH5iddUuRRwkk0RMfKsBAnBiFChUIUaEBUxvSxY /iyUQPBCLShetEZEvVHaXEELVbFi689FL1dvtUX5qeIPtIj2aXnIfd/ZOcswZGcn2d1hPU/e fGfOOTNzzjvf+eY7P5kkSZI0G6AkluHXDA8iRtjdT5KyhklS/veuG80Syi8kaUCKJOHn3NBJ krZ4JWkSzr2eFzKFPQPSpFmFXgkXkAYB+QAud2mSliTlIq4CHnXPH3naVAMs+xrwAsCyJZpH Lxe8b+CqPlqKlI48hjzNG4r31lBfpCkAmzEdvxRN8miIlwK8D4T0Jn8hrHnpzqtYzgymi3KI tipaUrKoN9NZluG6t74uP5azr4yy+cWcCtAjZaNNKvIEPwWIsy7fB1hftrHQgCQFRiJqhLNx Xv9mALTr5SkZhGRqRjDpvN/9kSLuI+J4LIFqpPO+C4EewI8BPmfeq0VuTGqRS4pEeRnlRRzZ AVN9y3BshEAozmsUA+K+fHargADAZxcv/ufdt9RH/inD8W+qu+tcp+Fhk+vOkILrZrUxqVn9 9nFNHZ/pLSgvfGCJb8SyynIqplXXLyTX1OsiQEa9vgMZ1Oulnir18mShy7HQ61pc2w8E9Top eQTiJQDtQgokw5vXLvGt+2BUOfUyd+q48l7KEt/ipppykS4lJS3O0pICKsoa57Q64W4AyucA aOI5QbSP6d0A0Q9FuoKuOBHpg4AUFBrKMpBX8hgYq572NKvDk8vUmcmMi/PIV1vXwymObIKb doC66atIMnQzaXE0ukndEbZWSCc2l+cJ7rzgqBrHfK6LAOom7cB3IFmuWV3qyVZio5u8Hrl2 ops3TPHousj+TN08cSBJ11WR3lHdFO12ooP3oq7UwfsAoYNFyszkFnl4cp5y2sO4uF4sdHA7 7rMFYJ8dqAWfSQ6OJWlPuS6MuHifK5ontQRpfHa6H/CvXUbpRYxfXsgyabx0DX5XIn6F5gmM gRwRzG8lBwSfyziUkybVjZQ2fj1S+n3fUbqUAlcFi/L32XgmjtIBnsv6Mc7QHWCcabiaVIcC vPbJ1tZWiFBo4IkIspSCms2TfihN0327YGp7f2dKv5ngrVgw2qPk4tR8YIwiSQ0/a21dhvue TpWkr0AE0wjWJ+dHSdLSpWoFotLGI5nSE1MmLAh85VHYIFatGAic8ih1RzMl7WqPwmsfRLlb J3sreiOvH7AF+a8gjSFncMWEfxakaZ/jeO68yQvykbYd524E1Kc9yguQY4AVNd4KFXmLklE/ HBOSNHkBqqWHvT+fvGBRj6CfyYROwEunkytmDC0oKt31fCrrWGxw1wRJrqffpbttof7M9k0A JgGLgRxgHTAA0E8N7Co7NGxXGfOouyxfCZgDaNODH4nUC9aDgeV5z86gh/14BVAPUF8v1c7q wUDEqZO8dzjdtdPFEr6p9vxE18FA5faodVHU28zNetSM9dsCWLlhnhNuWE/0ez2Ie0TDzdDt N+l+oh03se6not5mbg6hReTmK8DKDfOccBNrvXHCjRt6843BTTI6k5Ub5jnhJtZ6s2/IT33L Zy8tt9Ob0VKVJHl7BPvSkTlx6VP9wUkZOCiF9ENCwFIE7Q3zxuEwkr1hPRWehyB0U/SpjUhb BVjtTTzHbTdO3FlOf21v97cxlkhKisZfg9nvkL/G8wQXXjBajWPaV/prNwL0126FJLfN6jve bGVxqigvo7yIIzvA8whEy3RhifMaxQDtPO/bHn/tk8cPlNM3+VXyf+v+2omyfeX015julr82 HXW+D5gNpABFyq9TW+SVqXnKtamMCy7ISzfks53UU5GOqCOOyEs9UAdE8tdouz6+eFPk/vne mqD/9Ye8uPTPw6jrdcBJoBZgu0X/ZN5kIJr+uQLnkxNr/xyohfcHnHBzmXSZJD3x4yAn034Z F25Ood7kho6qlRvmOeGG9YRe6UHo04WyXeyHBOdBPrg61ZdotmshWCI4D0K9od61yC1ylTpD Edy5Zbs43zH3Q4+P8yATfpPq4zzInIY0n0h3w3ZxvmMJOOB8x/2QtF1j1SFKszpbKVN/rjBu 5sUt20Udenfde7a2yw2fdDH4uA1YB1BvQFPIdjFvARDJdsXaJ3XCTQltlwtjGXLzEGDlZr1D bljPcLarI3b9s91bfSN/96yt3vjpLfr3B9953jFxsetc45kEDr4PORMSIqQ3zJuBw0h6w3qm 8TwE0QeFXQ8gbT7QnneemRsN55YCCKH5GNZxuCTNbbRlRJIyUS4dYPkcIw5xzjyMqC/bOMHA LTiBnEyHtHLCPHLCa1YC5mCeF0D99CCuH28+4G9d/nic+Jhp8DGnDT6Y54QP+oMMbvEB/rfu jxMftxt81LXBB/Oc8DFcevhhN/mArs44Gic+7jD4uKcNPpjnhA/Rl6z60RHbyrH+3q89Prvx fhVHboeN+dzuvWyZ6Ygdof0YAywBqoG1AKgI2VbmrQFod0TbEdWD2Y6wnrG0rWZuNNytLds6 WJK+nmvLSMdtaw3uSU44LrdywjxyQp7sOEH99GDVlQBS2/uuccIHnt8TDXHiYwrqTD5uBax8 MM8JH9VScP3AysdGnL8KsL57FU3yaEjns9fXRSDfBBii3Ufxxj8KfRxTef44NCHHVFvRRo6p noVk32uR/Z2q1DOdBHcyeqiII9vRXEcxCqYDyQDfc7WAHyDv3HMyAvESwLq2vKFukD6mWnh9 iT6maux3uT6mYrpbY6rtqBfHVDsgU4Cx6mudmtXUi8rUyy9iXHBBXtwcUzV8kB3Zfov5oH1F tr0zk20EaFdyjDiErR84Cfnsl+sB9kvqDc8X80HMewSgDlUC5uDUfq/ASfWAtX8O1MLPB3FM FYkbN+aDGlFvcrMZsHLDPCfcJNJ8EOc2Rl/p83Eu+94e4xLOdi0Cp78FOJf9NiT1rlktTc9W Pk4391ERR3bcbBfnrNOnXu+jLp5cPc7HvQfqU2N9It0N23UvGvg6cB+wH6DtKlK6d26RP03P U55MZ1xw4abt4nxt2sWltrZLX2sStiuOc9nPgZOTwEsA1CZkuw4jugeIZLvs1po6YruccOOG 7TqFtpObVsDKDfP2AJG4sbNdHeGGfujuO6bZ6o0+Ztn/cHA+6NUhcXnnjUXbDwL0xY8DZr1h 3hdAJG7iMWYR3Gi4fymAcM58EMYE7yyxZaTjYxaOVQ4CNwFWTphHTsiTnR+A+ulB2KTO6I30 FQPAfKA9PoBZVzSc2xYffmxveTBOfEzFPQ8CMwErH1OR5oQPf5j5j404fxVg5SOeY5ZDuxbr Y5Yzly5PuPf+QnDhgXJxzKIC7Hst8jC1Sj2qCl2SoUYijuy4vfe53rPvrqX6mGX4zOX6mOXq t1foYxamu/He5zpQJ4BjlkwgBQ0eqz6jNqtfqGVqr66MCy7ISzfkpwMoKol0RB1xxP5J/7wO oD5G8svvr5kf2X6L934cxyx8568FqDdst3nMwoRo7HdH3m30EyNx48Z7vxFUkJvNgJUb5jnh xu6977bt4pgl//8afM9NyfTN2PxAwtmuBlCaD33jmGWwoXfNam5mUdqOTNEXY2G7nPZR+p+e a1fa9lG3fPOu4IO6SH7wE+qjhxHNM7iqZLopmOcV4uGbR+LGjT56Cu0lN/TNrdwwzwk3dn00 gGu019/ieiT/LoHrCRrOb8vfGicFHlgeJ39rGvgYgPvOgrwCEiKkL8xjfZhmpy/jwswRd8Se P1rXW/tbwUGdjzG47wgAIeSP8/3CNWFpx87gWOXKEbbMZKJ8OsA25BhxiIjzcxehzO1ALvBv AM8X7zrm1QOR3nWsZyzXV8zcaLh/W7oyHFtYVtsy0vGxSm/ck5zkAVZOmEdOIukK6qcHYaM7 g9WOjlWc8IFrVz4SJz4K0BLywf5j5YN5Tvhg2xnc4gP8v/CHOPFxCdpBPgYCVj6Y54QPt/Vj PKp6ME58DDb4YD+18sE8J3ygfnqIlX5cyHdNLlrCvtIPsL5rmOfsXTMPJc/vL01I2wTEdmzf qv9d9whctwQwr7Ed6PZ++fRXO/l6Tz5cvuSGTF2eXN3FV5P3WfnEHt3i7i+3oj7mIPQjGYki 7oVtrcbxIOA2YCVwN/AAkALsS31K6ScXpfWTP1Vq5H9JE+fJOE/EUczReLYYBdMB3p82rRbw A3we4dYpv/b8tfzjtzN8Q7Tj+rrT/uJD5YP+meUT6eeP+VtbxX34nik0gCqORNQIZ+N8P1Pf +N5neQbBm2gf07sBrDvjIl3BRSfimNzNBdYA9wD/DpC7lfIZZaE8Ja2n7E9jXJxH7tq6Hk5x xCO52wQ0AEHuJI+GOPtG+9fT7fX3Q88Pdb3959o6Xc5+fbauv29VzU1I/f0LOLgbOAkE9Xdt l35yp4x+8htdauTuGeZnIOIo6oh3oVft1d8bO/9I19+0i+f7qL+PXXmHrr9Mb0t/neisqLtT 3fwSjaRunjJ4WSl/1GWhXJ7RUy7NYFxcLxa6uYqEAtHrZvhvZnANetDBRt+867r4dj2+Qecx kf72hxwU4eFshLwMknZmSlp95hHlVEznHtzgmhyTa/8L2b5fbPh2cH1Eqc+sTTsZU66b8Axp d2Ol12NwrREAbbYXkoHjFf591v6d9+p/p0X55WuecqYLyXzYjST2/UTR+RLUhfXpA5QBtwJs U7G0MvV4MpHuKZaIlef8jZewOyjaIRvs1jPhd2H4LITkMxDPijL43ZjEfCYzQS6fCb8dE3wm JUXHk4mVqXwexVJJTL7ZI96LbjwTzolJT2wtn376tyHJ/sF0IZmfiP1kNDoK+wm/kTUBks9k QVaeV8sh0j0Lsog8r+gbfCeLOIombD8h99/sPeDjMxGSz0A8K5GfqM/ED3L5TJ4Bgs/k/Z5a DpHn5fNYkPV+T/EcYvFM3Hh3r81c7Xvl/vXli5eu8G14akvC/Y10BrjmezAXcjwk/aStXR9L 6do1Nab6X4vr+gG7seaju1b6+i57rJxry9TbJX9a7qupfrBcpJ/vq0tRjzVRJT0IvQINEcea XVDoOpTLgqyC5DhnWNfB3i/UPO9p9Z0UxsX1YuHP1+P6dQC5G6iF3xvKfSGPb/4P2/Wt0N89 fNBjpMS/e6A0fbvGHM/EPdMBcpJjxCEizstTn0bgpGrIayF5vpiXZ941SKCeVTLdFMzrW/HY QyS40XDP0uB9Q2sWrCPm+/h3DzaMdHxevgbXJyfcL2TlhHnkhHWw4wT104PQrc5glXMRAWA+ QP24VAs+MxxKTnUFp7TJB54f/+4hLnxMwT3JB/1UKx/Mc8IH9YvBykcT0jYBHeVjFs6tBRBC +uHFgQ9fTZghTcMXmaTP8SWCR/yjpCexC4+yYpwuA0//LHj83V8HZZie1TE9mo06XANUgreZ kDcaOiP6FvNqkMa6htOjScgztUP/dhH9RtkAxHl8bkTaKsDKp6JJHg3p7Evtn/cKP7fA/SJP Pvycvidrb8bzcZ/nQvXPCUKfyIuIg9PQd0UWIn0GeOaerPkAbVmLPL97ldq3hygPPqP2GamD foC8h5uf5Z6shskt+p4sz7XP63uyuuzYqe/JYnpb78xCXJNAFWH7RTgbZ3tEO9C8iO9D7snC J8P0PVl3QabgnLHq592b1YE9ytTqHoyL65GXbshPB3htkY6oI7+a9q4eqAPIy0At/PuQerRa 3R75fejCnqxqNHYt6vwDSLZb9NkliE5HAjmvZLopOH0frsA55MTaP6Plxo39Ho2oN7nZDGnl hnlOuLHb7+G27eKeLI6/uCdr2+5XE852NYDTJeCbe7LWGHrXrGo5RWnv5Yi+GAvb5bSPck/W 6Dk7bfuoW3uy+LfKJw1+EA310cOMGlzZ9dF47MmKxI0bffQU2k9uuC5H3TFzwzwn3Nj10SZc YxNgtV/R+Be7d++2XRe+YsYv9fW0vYO26fLMmCZ9Xe2Z1dvi3mdRN7T2bBD9LhlJIu4FrdU4 HgRwXZg+8t2QtJV8v+5LfSOrnzw6G2tr2TXy+GxxXiz6bi2u7wfs/A6u/955rMnHdeHKE0/q 62oPLnpSX1djutXv4PMoxjXTAeoP/Q8CzQzrgwxAbg6g6xuk4E20lendAHFNka7gohORTu7m Atej4D2QkyDJ3Uo5L3uhvCi7p1yXzbg4j9y1dT2c4tg3WcXCQJA7yaMhXgrE0j/m2ludZ6++ 9ia9/prOdaKsQ/CZkoMV4Hoj5HpI+jZT0h7JOaL0vNjMtYgj2xG/Qn/YT+gHusE1197INdfe /vx8YnPdaHB9RHkkpzYtJ6ZcPwq++Typ1wO18D43vwfJ9Rjula1D+ekAQmgcnYqDcdiBNh0j 6XyuimzbFtwj2im4RzSwdmlwp1feU7oMbHs3KGd/YrsDLBPXTQdAgeO5qjqUnWGc0wCpGnHh mzOvC8A6VwLmIHzzSUg0t6cTjmFHQkgxThK6LuZs/hPp5NT6zrPjlns/nHNbfsG5PYX28Xn0 wS/ViAtumdc+bsv1uQon3Dbh2puA9nDLb8S+WPy27ofOwrm1AEJIb704MM2bcP6HXwLn/A8l 538g9fkfHnP+hzLm8z+9weXDwHeBpwH84CbBb8gybzvAutrpq6kdCTn/wzWTko/f9XHN5Mix /427P0YKzaE/DtKBtvyxQqRngGN+XzwXeBbg+21r1809u3Y9E9P1KeqgHwj6Em1/R4RrI3LB +z6umex+4j0f10xuuOGAT6Rb/TBcLmo/DNfQg+AJFET0w7hmQt3MAp4DaBeHde3f6wu1e6/T 6u97Mi6u923xwzjWHzf3A32s31j6UcL5YQ3guAVcc6z/CkA9bVbX9CpKG5Br5lrEkd0hP6we J9YBkXwDjvXZr+2+y+XGtzIPoa7sv19Bkh/8hGwo835lcBXOhvpRJtbfynTCjRvfyvwGbSM3 3Nxk5YZ5Trix+1bmRlxjFWB9N0cz1sflwv5vL46VJt/9Z32s9OmoQwn3LiEXL4Jr8vKaoXdT 0o73OqLMimkf5X0CQPBdInk0xEuBWI5LOVYi1xwr7Rvy7eD6iHK8V23aD2LKdT14rQMi2UPu x5ktHba1h36OdCc0Br3N5cW2XmVHxkCTUM9x0LvfATcBBwD8hOwh894F+O6oZLopiDGQH2ms Z5qRJ94nYqwTQPp8wNrnB2rhx5FmblBM11WIkD/OOg7HMugiW0Y6ts46Ade+GTcgJ1MBKyfM Iyf4seUE9dODW3xUS4E74/lNXPJxO2Dl4xakOeGj2mU+wP/6A3HSjzq0mXzMbYMP5jnhw239 GC9JE4/FiQ+uD5CPhW3wwTwnfKB+bfaXHUhtAqz2Q9Ekj4b0aN5jY3D+CIDvQS8kA20P9xNz HU/ID4cd9DFdyETdbzwaXO8GlgFiv/GCrJIiLYdQchdkEbHdb+yGb8G1/J+u+UzfE/JY64mE 8+MWQm/+B5zLwGGA78sWeV7vKjU/T9h/jmtFHNkdGmvV4kQ/EPTj2p4T4J6QurHH9T0hHw3/ q74n5Mutf9P3hDC9rTmBQlyTQLXCrseIuqN5Ecf7KSj0JyAdOAqk4Jyx6rHezWpxXpl6Qx7j 4nrkpRvy0wEUDa2BIeqII64F1AN1QCSfi3oUyefS90i6sCeE9nIt6mx9ny5BGu0ldagSMAez z2W3R3IFTiInVptp53M54caN9eZG1JvcbIa0csM8J9zYrTd3hBvurdWO/d3WV9f1ht/n445J fp/PZudkJtoh9D3HiENE3Fs7FmU+ATc1kN9A4ge9JDj/y7xTSIhGbwK4xnygPXpj5kbDuaUA QivrJjA4+H0+G0Y67qtzTy05uQnSygnzyAnrYdeXUD89CJvUGazSrgSAePDhD36fLy58TEWd ycdMSCsfzHPChx/lGKx8NCFtE9BR/ZiFc2sBhJB+eHFgWpO4oHtr/27wJqMTUWdE3+LeWi/S WNdwejQJeaZ2OFpbCcdnNL5tpL0vbzWf1ve8PDNCquC3ETY8cEbf+1I4R6qAbxDX/+En9nCA Kj0I/UrGkYiD43P2vvCZ3I38FPCfArkvdUOffrKa309+p0+NnJsvzqMfIeIo5sh3KEbBdID3 Z3+nbvoB6ne4Pbfc+9LlylYf977ckZdUwb8p73lUqhDpVv/qQu59OQPuuPeFukvuVsp/6bNQ HpPfUx6ez7jgi9x1Qz65oN6LdEQd8UjuVrEwEORO8miIlwKxnGOkj+I5mlLB/zGQ8ZBMfY3q f4TzuQ8DGIQkAxnBpPN+C17a0tdClOY4IBNcyyAxHxI/GAcML6hSPykQ57qlpxwHzH85tYLr VE/tkiv4f9sur1MqRLpVT1HVC7I2yLFCLxDFsUJfSOrpWLW5oFk9XlCm9u7LuJm7aPW0Htev A6inA7Xwc5DUNfbvC71etRh1TQYv6yCpW6AJHe3s/6lWkYafsO8lP/JivV7lhBs31qvWo23k 5iFIKzfMc8JNIq1Xsa82Dulawf9DsOVot7i/j0HROUH0s3D2bRFK+8A315THG3rXrFYWZiv/ KBTnumXf+P8G9v5XVgV1cVRKVsUJ/B+C1PRuFSK9LftGG02gA43UhSXOfiTawX7Wlq1RcPJE 5A0C7gUqcdJ9kFWQKZBFytD+LbKnf57yciHj4nqxeMc6tV1cT06Z2dliu1pDPjfbGe1aO/eD dwfSgRxAtJPXngBMAg4BpUj4CpJ6Y7ZdzCtDGstXAuZgnueIte1ywk20tssJN9+gweSGa+1W bpjnhJtEs130zWi7DN8srmMJs74wLvQv2RT3oq9W45h9nraL7wjarnxD75rV4QXZivu+GW0U fTHaLvpmtF301US6W7aLfhdtV1/IoO3q3bdFPl6QpzQXFCm9+wpO3bZdieB30T4lgxfaLqtv wTwnvkU8bFckbqK1XWhaRLtO+0RuaLus3DDPCTeJZLvYD+l3cVyZiH4Xx5V8R3BcOR4SPxhX VhZWqe77XRw/0s+ir0q/i+NK+mEi3Q3bxTEj/S6OGasgabvGqi8XNque/mXq0P6MXwjbRT1K BL9rMfigb7HO0BvQhDfh2TGjE98i1rbLCTfR2i4nftd6gxuOGdmnzNwwzwk3drZrB67RBFjn yKOZ08Xl9D2OYxAZAVj3K3BfAvcrCMnvP3G/gpBMR7+kuU6ob9aNRoW4L3wZ8BIAfw3f4lJy uVeB337iN594bO7LIo6ijuYmi1GQYxT6hZynnA/MAiLN/wj+7L77j2u/dfMo6c6MUajMVbio EczxTKTx/mie479NmoCytTjhaeBmgHtE8RPqw8zbZaTZjZ3YdgbBWTTrWk74MP4PQlz4mIb2 ko9ZgJUP5jnhY1yQDtf4uESSTuyMk37cZvAxpw0+mOeED9RPD1b9yEWqClhtGHVtOgCzqWMp 7jMdB+L4Jzi+BQeXSNtQQgRzbzDHRf65si8O2V84B8D+aq6LRwvmIVn/+7EsRhBUgPH/FwAA AP//AwBQSwMEFAAGAAgAAAAhAIMGjxjzAAAAcwEAABwAAAB3b3JkL19yZWxzL3NldHRpbmdz LnhtbC5yZWxzhNA9a8MwEAbgvdD/IG6P5XQoJUQO/cZDl9ali5dDOtuisiSks0n+fbUEGih0 PI573pfbH46zEyulbINXsK1qEOR1MNaPCj67l80diMzoDbrgScGJMhya66v9OznkcpQnG7Mo is8KJua4kzLriWbMVYjky2YIaUYuYxplRP2NI8mbur6V6bcBzYUpWqMgtWYLojvFkvy/HYbB anoKepnJ8x8REpmxdDMdzbHUp2JjGokVDNZRaS4fd32XcEXr+q+QTP+By0qvmAz19350aHPf 8sIPmK3enJnKBD5Tb8GUss9HpuTRgWz28uJVzQ8AAAD//wMAUEsDBBQABgAIAAAAIQBMvYw4 uAYAAIsSAAARAAAAd29yZC9zZXR0aW5ncy54bWycWN2P0zgQfz/p/ocqz1caJ3HSRBTUfB17 x8KKwiHdm5t4txZJHDluS/nrb+zElOwaDvFUZ8bz83zaM33+8nPbLE5UDIx3Gwc9c50F7Spe s+5h43x4Xy7XzmKQpKtJwzu6cS50cF6++P235+dkoFLCtmEBEN2QtNXGOUjZJ6vVUB1oS4Zn vKcdMO+5aImET/Gwaon4dOyXFW97ItmeNUxeVp7rhs4EwzfOUXTJBLFsWSX4wO+lEkn4/T2r 6PRjJMTPnDtK5rw6trST+sSVoA3owLvhwPrBoLW/igYmHgzI6UdGnNrG7Dsj90c7J3PPXNRf JX5GPSXQC17RYYAAtc1obktY9xUGBU+Avrr6Gbh6NZ69UlAgjly9umo+NE/kLdEeo/ia7QUR Y5ghAZQWbZXcPHRckH0DSXVGgfMCMuoL5+3inPRUVBCkjROHzkrRe8E6WQpSqWiRJjsQtabi I6vlQe+g7Z7Wu8sgaVvyTg6aqPaf6EfBVJru5KWhAE76/g1p4dDb3Uft13PSEJXsNV3mhQM7 TrSrubjJ4Xz1WTfNP6Y+MPIUCdK7+qQBN45rVOT8fieJVGcMPW0aXUFVQwmYe04eBGkh9zfO SBn1k5IAVP2etj1kIl2IhNUbR9zUaAQdlM53pKOlrqCSNWA0gJ0IeN8vXaSQSdNoVQYoX63c cZC8NSSoZ2WgBH/OSBp6uOk+DOAKvelAiar62a7uCH4F58+pUkVttq9mglZy1FI5+2337tgZ hZ4y7yB+4JD+8P0tb8zJk1VPQd4rLQyA8qq4nj8JSd77r+ZmaRed2MAem0CUbztwlDZMpQhg T8Gt6T05NhJO3AGkCQAOozFMh0t/oCAKyfkvXJKGH3h45Nf8DZevpk00I/2YnrUgZ/DVn4LV r7hgXyBvSbPrSQVEg4E8owIbIEcu1435VbqA+/tiJOb7IXMlq0jzf7uVhrsDqXWm5UQSnaAd vzt2lTxq0/4G94BmmlGZCpzUzUB3wRujgzY4gytewA00+agWgN/TfHTl8OI5TwZFmHw7LE4J /Qw1T2sm4cnpWd2Sz5DlcexrN6/OyeEJxjm551x2XNI7oS4K8wWKqEpaTnX0iKxdBHiGPMpC 1V+Bpo9HOHOqgZkJjg+b0mVc7cZHEoA6feuM1Onhu+U1VfV5FOzJbfrd21gJ6AsA7iIIBthx PROe8Rpce07U4h24xux13Sj0CrcYg6G4V44bRKW/tnK2QeZnNg6KQw9N3p2joSxI14FNxnNx FFllvLUb5aVVpsRhtrVxfIQ8PBXgXAO4GHHk22QCF5Wx1Z7AR/F6em3maEEQhLldBqMotGod YC8urL4OyijNc5tu2EOZPxXvXAMcoLCwaoADLy2s3sEYl6n9nG0YBzpzxiy55gFOUZbaObnr lVZ7cOFFuTWmuMBFGdssDWMv3lotDQs/TK3nRD7aImu0v5/XUYiLyKpBtEZ5atV6jYPQt2qw DsPYt3p0HQduZPUbcHLPzsldd22N3Dr309RaP+vCj0xHNM+Q2I3KzFrBMfKy0qpBjKIysHoH 0gOvrfkWR8E2t0Yu3oYlTm3Rjku8tcd06yIoYpvMdo381FqN2wLKEVtlCuzbPZrC5ZdadUs9 N86saGkQrHNrfDLf8+13YuZHUWi1JwsQ3lqzN8Noa78psjTMImseZDmK7HdV7iJsmo55huQR Su0Zn8P7iq0xzWPs2/MtTyPXfofkeRS61twpXA/51nwrtqhwrfEpSoRya/aWYejlVo+WUZiu rbdymXs+slZJCfdOoKseXlPlOHhD20QNdKo1GFdqrFi048ubkXYvGFncqpEP3uA22YtPKesM f09h5KXfcnbHvWEulyNjaKFzV0ONYeggtEkNnR50SRq2uSXi4Yo77RBWKjRSf33FUvMTFX8K fuzH087Qbt90NZDNcSgIJjwYrl6z1tCH435npDoY275hHbv67UkowNXVPedEwrQPjSOgwCBl 3hPaLT/sVK9CySC3AyMb58thmb1RpD2roeEhYrmbSqxqxE79Z0BvYTwb29/9A9o4DXs4SN2y S/iq4b8D/bF/8CaeHsckfCme/iCVsh12Twt13riEXdPiSvMNzb/SAkMLrjRsaPhKCw0N/ruA 5vQCYysMfZ+gkzNLRb/nTcPPtIb+3/CfkJRHYdBUTfhNVzXHmkK+1LyC+UyNlOO4oLvlX26f p24bRgh+lLNeW3XiqtnuZ9RFDUOAGqNUsGfCuuV8pAwoTysGCb27tPvrHPBsNKxhg9zRHoY+ yQW4RHevf2jk679IL/4DAAD//wMAUEsDBBQABgAIAAAAIQCTMNizvQMAAIEOAAASAAAAd29y ZC9mb250VGFibGUueG1svJZBb9s2FMfvBfYdBN0bUbISy0acInHjoYfk0HjomZZpm6hICqQc x+cdC/SyDdih/QgdBuyafpstl2HIV+gjKTlOTCVSsVaGE/tZfCZ//r//e4cvrljmXRKpqOAD P9xDvkd4KqaUzwf+T+PR88T3VIH5FGeCk4G/Jsp/cfTDs8NVfyZ4oTxYz1WfpQN/URR5PwhU uiAMqz2REw4fzoRkuIC3ch4wLN8u8+epYDku6IRmtFgHEUIHfplGNskiZjOakpciXTLCC7M+ kCSDjIKrBc1VlW3VJNtKyGkuRUqUgjOzzOZjmPJNmjDeScRoKoUSs2IPDhPYHQU6FSwPkXnF Mt9jaf/VnAuJJxmwW4Wxf1SC81Z9jhkEx5QR5Z2TlfdaMMzNDTnmQpEQ7rnE2cBHETwOUAft oxieEbyK/UBnShdYKlJsbkQ2PMOMZusqKk1ec39Oi3RRxS+xpHpjdo2ic/hgqSZo4J8ihKLj 0ci3kXDgDyHSTeKwjESwKXv1ykhnEwEFwcZMHnNLaPNABPKUq8w+AyuhHSIXazYRmRPEPhw/ BAAh6gKQCN513SCi/wfEZrsbEGEZ2gFhjg34nCCSrVXNQQzFUlIitTicNCKg0EE94KBJRCCO NrJgYkokt5zu6WJGr8i0hSg6Oyy+gSjeQHFqU1JOEvvVD3X3v4Uu8LIQDg719VF9S3lw0PX3 lMUJBj+eGw44K87BRUCdxij+/fPX/37+rTzKjod0oGT0FVYPJ6IktOH7HnKHiItiLJdkvM7J rqXUSKfkVbmH9oGe3cxD6YSPlhHkMZWkVzUvozFegAM6dROhE9hHXFprrGvICQU5jVWtqFL2 /kepPCmkqoK2DdI6zp3RPgXG/LLtwJxdeGeUpwvh0tLt9afb67+8m9/f33z4aA/pbks94Kf9 J6ltS4mT3lZbepRec00l4IdwtdYUTCB2VXNNXVB2sbTN+kEN/vPHu78//1IHLDSy71QViMpi e9DHkwO7vq4G79l1G3VFSTKqDgu9aqOuECYw0/yd3QtWxPA05dsc0RBndCJpTd2NTMfSnUtX 31fXXUMSp9qfo+2BRh/oeLiJbEigBr2rZwaj5iSOYc5yzzOV/2gO9vGV/tOUg8bgGuwqB2rF oe1gd4az+ZJ7P4piQdMaXZyALrQe9KX/unm4m9SWHzfk0TNfc7w16KLey253ODrZMZHoiQrR jal1hTAokLrOpEd9O/Lr0b9dhWx5a0MSeuTfrRAUOyqkMtg6rwAOT1ZIOfuroy8AAAD//wMA UEsDBBQABgAIAAAAIQDJph+nuAEAAHsJAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVsFu 2zAMvQ/YPxi6N5LsLHGNOgWCosCAnbbuA2RZToRKoiAp8dKvH2O3XbruUAMr0ENOpkm+Z5JP MHV1/cuabK9C1OBqwmeMZMpJaLXb1OTn3e1FSbKYhGuFAadqclCRXK8+f7rqq141P1RKmBkz ZHGxsrIm25R8RWmUW2VFnIFXDoMdBCsSvoYNtSLc7/yFBOtF0o02Oh1oztiCPNKEt7BA12mp bkDurHJpwNOgDDKCi1vt4xNb/xa2HkLrA0gVI/ZjzchnhXbPNHz+ishqGSBCl2bYDB0rokcq hHM2WNaQzMrq68ZBEI3BCfZ8TlY4vlbv4+Mz6yvd1qRc4BQQOYQbaA83eo+hvTCoDKHHZJzd N9WlJy979n7Xm+0/3HfgX+euISWwf/mxnHUbjt9IfzAONSeYGB9qgicDDS8k9jDYEgygVGKX YCzDnFQ2Ddm8qGgaNpx2PgVKBw2GpkfzpRqccV6WvMjPckw5BO8lR8HKYlHmy8uzHB9BjiXP 2XJefCnOcnwEOXLOl4xfLs7LY8oG6Kv/+bcal8iw08EnbfWDuoWwDtBHFXB7Y/zkyrT6DQAA //8DAFBLAwQUAAYACAAAACEAi0LsCAwXAADerwAADwAAAHdvcmQvc3R5bGVzLnhtbOw9y3Lj xnb7VOUfWFqk7l2Mh6REiZpc+ZZGGtlTNZbHoqa8VIEkJOIOCNAAOJrx/iZ/kGyTqiyyyS7L /I5v5TNy+vQDDZzuBpoEJTq2F9YQjT7o8370QeNPf/68jHufwiyP0uTsYPBV/6AXJrN0HiUP Zwcfbq9ejA96eREk8yBOk/Ds4EuYH/z567//uz89vsqLL3GY9wBAkr9azs4OFkWxevXyZT5b hMsg/ypdhQkM3qfZMijgZ/bwchlkH9erF7N0uQqKaBrFUfHl5bDfPz4QYLI2UNL7+2gWXqaz 9TJMCpz/MgtjgJgm+SJa5RLaYxtoj2k2X2XpLMxzQHoZc3jLIEoUmMERAbSMZlmap/fFV4DM S76ilwwUTB/08V/L+KC3nL16+5CkWTCNgXiPg6ODr4Fy83R2Gd4H67jI2c/sfSZ+il/45ypN irz3+CrIZ1F0dnAbLYHY1+Fj7yZdBrC2x1dhkBfneRQYBxfnSW6eNsvphJfskXGQPADYT0F8 dhAmLz5Mqg/5efHi4ppdmkZzgBxkLybnBzDxJWIg/2qYrBRe/K4a2sAwYN+ESxEQJbx/l84+ hvNJAQNnByCJePHD2/dZlGYgKeW1SbiMvo3m8xBkVt2XLKJ5+OMiTD7k4by8/sMVCqC4MEvX SXF2MDw+QU7E+fzN51m4YqIDj0uCJTz5mk0A5j2++knOHTBEgUKm2xdhwNSlN/CeMfSeceg9 48h7xsh7BqivJ61OvGeAHfJ8xmnrGbMABYDdn2uShQxd18SqPZdvoyIOW69hsp4WfhOKLE0e WsN/s1wtgjwC29iSjFwLen/4MZz+kU1aR6Uenp469OF9HMzCRRrPw6x3G34u2GRK1rbQrtPe ZBXMQMHqi2jPiXfRw6LoTRaop3Uwx30HLnzmuyhHLHQSHLtMAp/2TRbNydOGjqd9F86j9VIu lBuUyjMP209G21KZfNQ8mSFqeOyo5Uz6zOPmmYxKhmeetJxJnzluORNtaYVCLqm+hNClZxKE E5f8XKRxmt2vY8nTujicuKRITTY+1iVIaqZJBE9cUlRRld75bAYu2sAdF86lztjnu9Aulcc+ 34V8XYvsUFyEqEEZ2qG01is7CJeC3YSfIhadM9HZ3IyiZr8PsuAhC1aLuhiCPW/rFn5YpwV6 NV1zhu3nv00g6svDnhHOIQZzraIuwR/Ey8Gc1gbIzpzWlsgOorVJsoNoZZus072MlB2KS22V zUGW2CzHiUtzFQj0CVYQLrU12i/qI/zsF53vIgS1X3S+iwo1yzOQ7KBQXISoQVEqQqF42y8K wmW/jIpKQXgrKgXhragUhLeiUhBeikqmb6SoFIpLPpWW6YpKQbhEVIHQFZWCcMmnUVFpSOan qHS+ixBUUel8FxVqKqYUlUJxEaIGRSkqheKtqBSEt6JSEN6KSkF4KyoF4a2oFISXopLpGykq heKST6VluqJSEC4RVSB0RaUgXPJpVFSsKukRYMssWvoyOt9FCKqodL6LCjUVU4pKobgIUYOi FJVC8VZUCsJbUSkIb0WlILwVlYLwVlQKwktRyfSNFJVCccmn0jJdUSkIl4gqELqiUhAu+TQq KhZzt1BUOt9FCKqodL6LCjUVU4pKobgIUYOiFJVC8VZUCsJbUSkIb0WlILwVlYLwVlQKwktR yfSNFJVCccmn0jJdUSkIl4gqELqiUhAu+TQqKu6hbKGodL6LEFRR6XwXFWoqphSVQnERogZF KSqF4q2oFIS3olIQ3opKQXgrKgXhragUhJeikukbKSqF4pJPpWW6olIQLhFVIHRFpSBc8sn2 5OKwp2+d6Ro68K962kAN229miUXdhPdhBq0aYb2We9gelKzF2mFhTt+qHvs6TT/21JanTqZD zDfaAYmmcZRiifpLY737EDeR6f6sfaf+9vuL3rd8t74ZOjKXQid1cmh/0DsZWJsAdsbAjcWX FbQTrPSqO3Q5sL4PaLXBFbDmh7fQrCBaDthk1oMAc7ELQ1xGjAQB8d/QrjOX9/T7l6eHJyNR KIGeCwakCKbYWgJ/5X1xeF+wZ65S6P84ORUW1XbDYHAq9NN6x2gsLJH1jtMxGl2gENyC60mh 1eg+Th/fr5NZIVcmlh6si5Rt9YaXb6wj1/WR+V/WeXHD9nffJiVJ+A5gzveNYco0hC4kYMVg KJ5VwL70eRw9JKyDSMKcBnkYR0nIZsOaBSmhOwd5+rO8bSidUbVd5pvXjLplTw7voOGgEAaA RMFokBC8h8mEkNQBNqroUlE2nKAwsGXPv2ftK0RmEkDTdN1Llj6G4eoaAOHD2I93QKMcf1EK H8pCQITsYELHpQ2WsQCCYV+Zkr50XTCCv/sUy1Uifwjxp9uTcWglo3AiNTIq6iOinRCSUmt4 JOSREgK1TxJiQ9E5tOIsvN5z4DyQEkJxRk5siTPvsDOpi1BbM86CIJ3wWRo7zS7O4jDIPKxv HwICLvMSmK5PAzasKxReQEGlREXMtiTqyCpIIqo2E1VQvBOiUsQQ+paIHVsRE7H+7hGTDLZK S8lc+y3CWwM1JLiKvDBXXZEX5bspWaXLRvcHADfxWby50qSEIv8xk1XQfEfygtC3lJexVV5E LPQciCFNt0Ts1IqYyBWfAzGkaTNiswVE2LMiRANrCbBFW7LqgGHd1QRlcVNP3dXD29CwlhmN DFVEfFz25PD7Kv2i3IZbVAhUlTeIWtZ8y8admUEPb+HRLl2g7NJsWiEYjWks8oZpzONoaJ3H Xhyewsw/B/whcONFGMffBRlmGekKiGG5lYV+fHTQR+tTAzVNiyJd2udn2LSJ4E0AQCz0xfCf DAn4l4XeyXo5DTPRSWqh+XXKKg5EMqALFa9bRKEtpe1rqySJM8hp0uWEJYf1RPE8Aet4nfJW YcYD3cji4B2s9R+C5eofe/wmXHJNe/W80mZtG3NMr7zgaCwi3b/MpP6w1kLQWa4i1WRriovO y5RLWoKGRKpiCVxUXK2A/4TL56vVHbtuItklT9yVaSgtg51QInXMml/lsLytwRfCKdQd6pkF dXa9G9Q7kPMVvD00j+yiLsbbSHtFZxBBX5m349Na4rLCKHFZ8auVuNYmKytExYIqHKAvx0yS 14mdomn30xgjD/pcp0bSwOWdUWWH1htepxHlod0Z8KwwWjGQp72yYllh8dSw0H1yz6oQtVP3 3FojJte06nk+uf5KhNyOaMbujO2V8ebiTPUOY228dotKsCHIVwFPpQg0ENVxTNnlLZUi/Qhe UkT912BUbhgMDkWJxXrHSV/QzHbHcHjcUMYfjg9FlccG4/CoL4qo1jtOj0UeabvjaHQo0n/b HaNBX1TprHcc861JcNdwC244UONvrjDXY7SLdJ1F8AIbvHCLlRP+Nq1+lVtm/H+Svs/S9B7/ rQWt8kkNkVtbrbgI4pi4CbzIl+K/DdCoLF5OQhV29dKTKPUDR6oRfgRrhotdkWYRrAw+9AIu Q4D4q3SiU2TqFq60tVgBkcxOCsn32/NSlZAeSwlsN+5NMk/gzacbte1eT74hXWE39CD+EBvz JrW0p5G1Ko1dN0VWCTupfAtT+o58vYJzHGZZtCqYxHenXSEUTuLwE3XJasCEqR6725ERVoGa aVkvqBsTwLa+jyiNC/y1VH7a6oJAiO4VqgETplUyNOKqY4ShhI7S4ekm1VxHqUMsjm4FqgEH SsKr+6EkQp/uuPLmpzWe7UGcnxowoeAlfzJc0CKLWkBn6oeo3bJhzCfqYCAF2JpxNFZNCmXo iMVQFojgLafHhxhNAYn5wrundRw+gEGzUvxOjO+e8KpXoHPWVGk6GMPhLICOoikYE9I/YjJK GMfrKiwD++6YchU9rLOQMENcbuKBb7FLhWpe0R/LIIEKwT3UdLVGG1c+CQTa0l5zClhklQ92 JqkOajRaj90Jcc0E0Y4rKsRgXkpGcVsjRVUE5MAXVbkZtCy9t3WxnCu2HQzBs6fcwnB1M20g 1IqELIAHunaU4Uiyvb6xmAHIc+5gcD+MASuwljKmuu5cxkDRTaQ83ZHulm2jYhpjIB4O8lLc /pBvc+LtQuhspBO6isM22lVoj7K5tTcCucI+R7GfWNo34XpEcV+aNPjbiZN5jIoFNMvwdLie +wlSiHueorLbsdVqSSWVDV+lkOpmxBTd88tNRqgxn9g7h+oo0p6OaA22GlqScN0UWspiYbVM puo/5hLjQPY0deZlsryw8PYqKsdMDBbTcGh7Bo9MZK0GOwayVtrLcSVaU3nt9zX/XWkgx0ul RZmKtnHZpWvsGmdPEIkD5V3NWAkuVq525+g4B354T9SSD9zBCCL4G9k+Oe3T7ZOqYo5PxnRX onqLQciofJh1l/liPZIeYjWlmd3m+iPjobsAeS/ueLIKJNQiInFwJnpksX+zu9wBsgaaBePF reWaMpXn+sAu1OpNHCRjFx6AWA8XFKeYQbHoJGDK5UcdSIk/Gy0rS1PL4MDgSCs7iMORbPeV d+rVSTYKtkrVW8u7fWjiKE7i8ap0U0tcNjEVdoHFhqadEqJAPt3GzKpIh70HYoh0WNcKb16D t4vsO2/2RQpfIckOf+Vyq15ur0oHIuZulcftzgwwlkAX55T4OTFwN7XoFB7ri1K1dRbCdZMU CMUeqLQaKqllvqDZ8retoQg8IysBor0jwAb7vUoF3ybz8DPdfQJLFX6GsylNZkIv/tt43XLD zdfy42rpDhJfrdhQcViMLVerirfwPDAozNjDadfjrV4CQozoBhLHSLRkPDFGo2OZ+XTkibjA YAnBnOLzG+7wjl0n+DQYEa9VSrtil0lz8Pg+eAivsfudmIwVDPV4Z7xRk+wb1jbfZl9cW/v2 PsgKQzsHu7xf7RygYaLqJHeGWrlGldWXPnLYcZmd0Yp1QtZDT6QhG9jUatq4rgyPY5+EyvWw Dd26ESizWiM9+JA/RTRzgZM7pk1lR60VpSrxRiX37Fi8bsLZHL7SQMQLrt/hwPMSc5+j6tJC 8EoDUEqadcU+Fi1V2NeydLDSj5pw5F0/rMOcZe5GHspBOyMl93GVNGBpqxbb6zUsxOAnmBDu Tddfy9pQx/opeWigjhyykYjT1MJa7jZsdq4jhhq26ThLbbtMbaJ925o381t+b5A8gb+XXL1O DdSTg449YuS63D+mKv0EfDdFK4ztvsEKzCk90DZc/3U4EcdblBvk3C18holPSsBszAKmqCFd uuTEZo51YlvMMSCTsv0MAdVpOmXQ4OD3tB417MipmKkoWekgJRBao7NJDpSQ2BTXLgaVzNch x8w+GBIjJgTsOtKwVs3wz4FVJMd4AmvuaH/2Bso5bMugntXB9TvHXkJZ97SRVXlBvWzESs+Q 4aryvyhFAzodFV0YOvjNKyM+OGJih83dS+rgnEZMaTLq59S75uzKGIzfhPBKOsu0TIRgoqzG dHUi1SwnSew61TafgFUaIk22dkscDiuXI3TdHFcbAztarSFM4uu1BZm45OeMkFaZ0WytrBES rJhNQd7rVAY8S7HZKZlt2r3ayEnAuhU+u1x2btHE/Bk1sb13y83eDRYvZaE771Z/a9LwkdLt T7Zob4RyoxHK99QIwWqNRoitd2+NUG42QvkGRoir2c49ExS62Hc4aYiRb2iEkAQ7XvaERcpp Qjc9xcDd5tueNsupQsB9zntp0HYsj2NtnSJ1F44LZtDNXsmlzbd7/59xye98iW4LF4IZBt8g 2SRD0ZpjtOUZ+vVGPnlth1Xfm2izN6YSzSeoMQpyme2ppCUfRfPoRc62mwbKTG1B2P3aS5vA URNwjHvdQYnLT0BJalTH1a3Hvk/fF8uLK3tXHVehJqtwFgUx72mmVOOjcHAjvqBgop4+1Ki+ BmdYaaDcszNawLfJFZf+EE5aXLAsEAZF16HokGQ2Q3YdChZv1qHeNju5Za9i3WfhT4RvOHKH QyaebVmBe3w1Yx9ilrhqLfsdFeZw+awn1IIYDpkQ032JnqPr1xuFtGIKJf/hr8T3qTpKK5ox HNP3Yio3NKrOeNRwdlGL84+O+Pur9vd3Bl2ckDQaiUhPI3oF1xZnKMFRELxUY4PR4pSl4zG2 xdmxPRTnMGl2wmD99fcPvYIQYvs77lu4ZfbD8ro3jnX2tjcwof4Bjd+1yC5Xv2uRagUXDYH8 nTHicrWOv13oBrwMY6x2cOXY4rV6BFB6MT+XxPxT+U4KNThsmxN8laCc3+vizOQAlbv048a6 nKSgrTKnO2zdkeM8ZIrcO/CjHaXWaAtqiSyxY4KZaoKcXqpe3zIX7J5a3pIFtNnyhXGOhGmf lhOlm53a4ncPVX7PavB7nFeJN1vFeZUk/+n9FXNUtMB9yy5b3urRSyK6jdVtb6N1fUa9qUaQ 8pwoe1TVmCG1SIC6SG/EAbBgGSXxqFeqHpVj6XqVCakoNnTvjZjw0HI8lylzMR7HRJ7pK1Md uAq2YPpqFV+w+dUqHBO4+C64Ui2uMKPDiIChdETrIKjXoiRQiwYQJYGtjpJ4z1Fwx67ZopzV bShYpLM+wQIu9oTw1nDQbZCOA3xzsnH9+/oucMUyNZyLAAJULS5uwA31xicSrV4QZ7QXpHTQ vuVbnWq11dxE2jf4K9WjarSf+nXsCgsqLv702F5fg4PG4e30s4N5WoZIXR12obby9FbBYygT AcFQRs4OWOEOfqnGQTaq1Z9bmk1dGqhNZ9JgsehK43xlgXo1Wf3ScR2M+Cd2FXqiTik1YAP0 qAdg6Fns//cXAu+W6G2wHmq+2Xosxvv7C7HQ3a1nZDTE4lT6mjEA2yEWurv10M8GMvqI2usz rId+b4+tRxx/8wzroZ/JY+vBjUByXMau+OVoAX83uQQDGbNP/dadjDbUtF1TjUdOr0bnr98w M6eCLOYBAd0L9jEUUMKOSlTvJnA8yjm2BxlWX47t7fIt+93vJnp6VxNaPbp6NrpjmGqgOb++ t/QGkXib3NMvDKEg4Yhp6bqY4biN7C3di1MdYYkX6ZJ9i9tAXm1wRwutbF+rsONb+Hp7Bkbi I1lTOWJaUNu96tdHR+PL84rFqOxS9+G/qys+vpbRaA4H30A3IzzX06IotNh3DOGt9+AhC1YL ghobLb9/yR/u0EX7RyftnxiH7puTS4GXSBn08OqEH0nMtuzh+4Cfi3UQT/jmCkcap7QUOoU0 tx8/hlOCMB/p/QHG/rgFuuv6Zz/B3ucRO4KFH1baH50fnx6JwG1f8z2gqkyAdnSS4gBaiYAm UzxY8RxOThQht/jMpdwB4nfhr9pNqHBMLM7j6CFhFkOSWGvqqCai+c8XqstFNovG8Cl6OTFM XnyYbKNRr+HDPGma3Joq/mKsh4Mma6F7NmZs5Ko0oBfwfVsumlWRGl/2+2NhQATKNIOpZF4q NCGN+8EiXQaYtPEvHd2qC7P87ED8wvWXO5j89FHW61USuO2JpBWT6/ANdTLU4zWdvr2SUDWT ZTfJFpI3kVtUnHZMRji/qSqn37xmLAqDvDjPo+DswEN0KwRXdlF43Rv1zZo6fYMETjHEr29s fKxkVWgPr/qjE5EwCip2I1GV10TqCBp1U8ONWZRG66/LiiAcg1tKXSOmSl5KFn436X0XJbOF +EpVSQt1Mn9D3lBhrEOT6iuuc1qMo6XaVpO0Z5k0ySADzZTpThUqkuKgWECChf/99//85T/+ +2//8s+//Ne/NopLVRouT0ewKccn/Xb9P3p/0CP4rvUhd/Lsx82afeg6KN4xteAkKrtXyxfe IToxOf7yBohfqq7fIFWTaDlZJ4J56NA+hlkiva6srKnPXwxFxbkmfRAwVAzxz4sXF9cMqGdU 7pI+uvsA4ve3f/ufX/7pr79LILNeLOJjqUF46XGW9wYSKPunLfJnDTwbpM98pPv2Aidzo/zr /xMAAAD//wMAUEsDBBQABgAIAAAAIQA8QG0DxgcAAGE9AAAaAAAAd29yZC9zdHlsZXNXaXRo RWZmZWN0cy54bWy0m1FzmzgQx99v5r4Dw3vi2Enja6ZuJ03aa2baXlonc88yyEETQBzgOOmn v5UEMgEDu4Y+NcZof7va1X+VVHr34TkKnSeeZkLGC3d6fOI6PPakL+KHhXt/9/noL9fJchb7 LJQxX7gvPHM/vP/zj3fbiyx/CXnmgIE4u9gm3sIN8jy5mEwyL+ARy44j4aUyk+v82JPRRK7X wuOTrUz9yexkeqJ/SlLp8SwD2hWLn1jmFuaipjWZ8BhYa5lGLM+OZfowiVj6uEmOwHrCcrES ochfwPbJeWlGLtxNGl8UDh1Zh9SQC+NQ8U85Im1EsYdrRl5LbxPxONfEScpD8EHGWSCSXRiH WoMQg9Klp64gnqKwfG+bTM8aPBsyJgfXKdtCKnYGG+b2TIZvBkWhmQeV311W6xanJ13BFBlR JqwPGBdeM0tPIiZia+awqalOLqyHIfX9dyo3iXUnEcOs3cSP1pZalgTPTs71yquGlpEMNJbu MmAJd53Iu7h5iGXKViF4tJ2eOaoi3fcgFb70rvmabcI8Ux/T27T4WHzS/3yWcZ452wuWeULc gYSAlUiAwS+XcSZc+IazLL/MBKt++al4pr4P1IvVL+1IL8srBj8KX7gTBc1+wbAnFi7c2ax8 cqWcePUsZPFD+YzHR/fLqjML91dwdPVdPVqB3YXL0qPlpTI20ZGW/1YiTl7FD5+0KwnzYPGB GbbOOegQCJkyGgqV4NkcRM18+LlR88s2uSwg2gDAqmbhY23SQZ5ArJZGtOFbvv4qvUfuL3P4 YuFqFjy8v7lNhUxBSRfu27eKCQ+XPBJfhO9z1SOKZ/dxIHz+b8Dj+4z7u+c/PmuFLix6chPn 4P75XBdCmPmfnj2eKKUE0zFTSf6uBoCMQToqHO3QRuy8MQ9qVP3wvxI5NTncSwk4U13N0f53 gnTUm8GgmYqoGoC2S/L1dLiJs+Em3gw3oYt32FzMh3sBe5mhGTG1UalKfFJz6Zniq87D6duO klUjGlXUO6JRNL0jGjXSO6JREr0jGhXQO6KR8N4Rjfz2jmiks3OEx7Rw1avoVM8GamHfiTyE VtmjdNOBUle0GueWpewhZUngqN5ad7tLLJebVY5zVcvp4WK5zFOpdpw9MwLdWS3dgzX5U5QE LBOwMe8DDZz6O7X7cf5OBexge1BvTPE1YtIbk70t7DZkHg9k6PPUuePPJqOE8d+lszS7jF7n Bqb1q3gIcgc2hqrl9sLOWya9fSaM/a8i03PQ2c3PW0LpM47K4XlLXbYb/8Z9sYnKqUHsRs6N nhPSXENoF7un6EylqLm6eqNQCcCEYNoFPQRtH+G/aS50+yrHGP9NKzrQPsJ/07gOtK/rozu/ ZKW5hr+sOKjlNSev3SsZynS9Ccs10CsPc/IKtghcCORFbO2jRGJOXsGv5NO59Dz4zQ1Tp+Rc 7HSUQCGnw1D0YsPHQk5KTfamhIjICaqxZgTWMK0lgMii+5M/CfV3YGoz0Cpt95q9y/m0ZQag BaH20D82Mu/fQ89aNA9LuYnhzyUZd3C005aVh6UV9WT6HSHHwxofATSsAxJAw1ohAdRSH+17 HtsT8ZDhzZHAIsuy7WK67NDKPCcrswXRWsBIfROx/2pZve210OybCAo5Qc2+iaCQs1PrZbZv Ilij9U0Eq6VrtOeoqqmUoMh9swqyOwFEROOINwI0jngjQOOINwI0XLz7IeOJN4JF1garqVXx RoD0K5Rf9S2oKt4IEFkbjNoVfzMq+5620v3L7QjijaCQE9QUbwSFnJ028Uaw9CuUSqixrNQh WOOINwI0jngjQOOINwI0jngjQOOINwI0XLz7IeOJN4JF1garqVXxRoDI8mBBVfFGgPQrFG3Y K9561f928UZQyAlqijeCQs5OTVDtJhXBIieoxrLijWDpVyjFULB0cVOCGke8ERGNI94I0Dji jQCNI94I0HDx7oeMJ94IFlkbrKZWxRsBIsuDBVXFGwEia8Ne8daL8beLN4JCTlBTvBEUcnZq gmp1DsEiJ6jGsuKNYOl6GSzeCJB+5VAQJaJxxBsR0TjijQCNI94I0HDx7oeMJ94IFlkbrKZW xRsBIsuDBVXFGwEia8Ne8dZr5LeLN4JCTlBTvBEUcnZqgmrFG8EiJ6jGslKHYI0j3giQLszB 4o0A6VcOAOlVREnTOOKNiGgc8UaAhot3P2Q88UawyNpgNbUq3ggQWR4sqCreCBBZG9Q5Wzgv ij6eOm0pAuw5g/JUAxo4a0kSFlgE+JOveQoXC3n/6ZCBwDJCArGlPLAhfpTy0cEd7D5tKRA0 SqxCIfWR7hd9SqdyEeF03nGT4O6fK+eLuQDTGKdL6vXJG7g9VL0upK8nqYtD4Gf+ksCVnaQ8 Wa6swQUhdbWruAKkr4XewIWg4lqPGqzu+cCL+lJV8Vj/v21BhZ+BqAc2UV4ALA9uRHWgigPv 9gySPu5eB7eciteO7K5klG4Wp+N3eyjz3qszmp1+5+okeIfP+qR45xw5+hWT1aaDcDlLu9Tn IaRsFZorZvDDTexDhNvidpZJpv/MjCn4/oqH4TemL6TlMml/NeTr3Hw7PdEdsGZqJfNcRu3j U31AXHuyzwCUQ9UZ81EF0V4n8SZa8bQ4bt5akqpz6Jtor0vSnHVtKQXsTO98K3/K3v8PAAD/ /wMAUEsDBBQABgAIAAAAIQBZNqjCgwEAAHAEAAATALMBZG9jUHJvcHMvY3VzdG9tLnhtbCCi rwEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALyU0U7CMBSG7018h6b3Y+vIlC0bRMYwJipGwFtTtzIau3ZpO2AxJr6Db+iTWAQJu/BGM+/a nub//v/ktOFgUzCwIlJRwSOIOg4EhKciozyP4Hw2tnoQKI15hpngJII1UXDQPz0J76QoidSU KGAkuIrgUusysG2VLkmBVceUuakshCywNluZ22KxoCkZibQqCNe26zhndlopLQqrPMjBnV6w 0r+VzES6daceZnVp7PbDvXgNFoWmWQRfRl48GnmOZ7mJH1vIQUPL7/rnltNzHHfoxmP/InmF oNxe7kLAcWGiP96S9T1ZUbKO65QRo7vSASvXSst+aB+vv3l/JJvW78imY7wqGsB4cgOQBz7e 3sH1FGw2m69l0ooP/8hHhvU/JEdmDA/RhWSY5430Cc8ZVUsgOKvBRNKccswCsD9upQkIHVl6 YhUpKX9umPJt5LWDdo/QGVG6gW0HeZh6M3u40kshG9Cr2dyagamushpcSlGVZhh/MmJvH+Pu q+h/AgAA//8DAFBLAwQUAAYACAAAACEAga3+MxsCAAA0BAAAEAAIAWRvY1Byb3BzL2FwcC54 bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVF1v 2jAUfZ+0/xDlaXsAJ4DSDhlXG9VUpFVFIrTPnnMD1hzbsg0q+/W7ThoI656Wp/vl45N7TkLv XhuVHMF5afQizcdZmoAWppJ6t0i35ffRbZr4wHXFldGwSE/g0zv28QNdO2PBBQk+QQjtF+k+ BDsnxIs9NNyPsa2xUxvX8ICp2xFT11LAvRGHBnQgkywrCLwG0BVUI3sGTDvE+TH8L2hlROTn n8uTRcKMltBYxQOwVTiEb9xLMepL48oESvoMR03gqpQNsPx2io1zStd8B559oaQL6ItxlWeT m+KGki6myz13XATcJ8unRVFQMqjQr9YqKXjAXbNHKZzxpg7JU7uVJCJQMhyhuKkNiIOT4cQy SoYp/SE1kslzpNiFSM/xneN279l0EkmeU7oRXMESN8JqrjxQcinQB+BR7TWXSJoew/wIIhiX ePkb9Z6kyU/uIe5xkR65k1wH3Gcc65I2VtYHx0oZFGJjr8vbcDg2jOWM5e0ABteDEaDjgI1r du0N/qnGdwv/IJsPybYcOqoDOoPwfMdfqI9co9COrcrtqKSkT+nSNJbrE1tp1Fe3KnKVlKBA mKY56Ddlk61GfZNPePwzyv92KOr1y29tae6jDd9kuC4O3PMiw35juYgSF7MMN3Xx0aBHN+g3 qNAYPeKlQB9QM6fitXhW76DqZ943ojOfu58Ay2fjDJ/Win0N3XT+OtkfAAAA//8DAFBLAwQU AAYACAAAACEAXwcZSiECAADQAwAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhJNLbtswEIb3BXqHgfYySStJ bcFWgDp1UCBGDVtBi24ClpzYRKwHSPq1yx16w56kI9pSnaJAAS1Ezq9v/nlodHsoNrBD60xV jiPR4xFgqSptytU4esyn8SAC52Wp5aYqcRwd0UW32ft3I1WnqrI4t1WN1ht0QKTSpaoeR2vv 65Qxp9ZYSNcjRUnB58oW0tPRrlgt1YtcIetzfsMK9FJLL1kDjOuOGJ2RWnXIems3AaAVww0W WHrHRE+wP1qPtnD//CBELpSF8ceaajrbvWRrdQp26oMznXC/3/f2SbBB/gX7NntYhlJjUza9 UhhlI61Sb/wGswWqqiCjVCH1GD7nj3EO972BSARY3Jmm8/Dr9Sc8mBKlBarfowpatzderWkU QL2D2fxhGedzKNHvK/viRqzL0WRTFqWvbHZKsPRbfYR7W21rENdB2gqa0b3gkRjaZUPWRC9v GpZGp6ypGxPZ5MuMCCeHSzgcDuH1E8C0sik8HTjn+umuUttmGEBVYne7lDvU8OMIi0l8LTi/ 6t8MQXoQScp5miRAlfcTxoe0B6IfTF5mboxupPMzWsdng/rjMVtMgtm/bhth28osGQZJd24p c2tKjzqjkfVjPoi5yPmHNOFk5XsHbUXUhLAtp65SETT/9LQtbeRrMrnLpxHxBPGGsbjKxTDl 9DS8VhWaTlk7YHEu5n9EwWOe5OIqTfpviS0gC6bf/oPZbwAAAP//AwBQSwMEFAAGAAgAAAAh ABZ+ae/+DwAAg7gAABIAAAB3b3JkL251bWJlcmluZy54bWzsXcuO3LgV3QfIPzQKaCBZuFvv R2N6BvUMHEwmQcbBrKurZLcw9YKqunu8i52fyB9kk2QRIMgm/+RfyBUpqShRokiKUtETe+Hq KlGUeHTv1eF9kF9989N2c/UcJcd4v7sfmTfG6CrarfbrePfufvSnN4tXwejqeFru1svNfhfd j95Hx9E3X//yF1+93O2etg9RAg2voI/d8e7lsLofPZ5Oh7vb2+PqMdoujzfbeJXsj/u3p5vV fnu7f/s2XkW3L/tkfWsZpoH+OiT7VXQ8Qj/T5e55eRxl3W3p3vaHaAfXertPtsvT8WafvLvd LpMfnw6voPfD8hQ/xJv49B76Nry8m/396CnZ3WU39Kq4ofSUO3xD2Ud+RkKNoua6+MzZfvW0 jXYndMXbJNrAPex3x8f4cB6GbG8wxMf8lp5Zg3jebvJ2LwfToa5XDJnnGcyS5Qs8inOHVHc1 YKzxSdsNxiF9vuenWu3RNFiDyZ5I2kVxDzy3UL5mfifbZbwrupGDhgQXVKKLfP8m2T8dits5 xN16e737segr1UyBOzM8pHnk0I5CHVCq+/3j8hCNrraru9fvdvtk+bCBO3oxnatUIkdfg7VY PhxPyXJ1+u5pe1X69np9PzJQk90xXsOx5+XmfrTA/yaj2/Tk7dPmFH8bPUebN+8PUd4G/bpJ f8WtTtvDJj82H3vTqWHN8ZHNc3ogho/8WmDTklPe2MStwKAttsWP62gVb5dZ13Dmm+in4th1 dgb8/NtV3ssmenvCHR3+kKR3fYIxZ595G7jECP4+7AFvx7bS5rfnhvEuHX/aDz4KXx6Xu3fI Fp9bZ70n+CLJYr87HdOW8Q5OW0dvlwBW1jFqAxeA+0xvBD6gIYbBRJB3heHmGo0BdS2PhOt7 DCTSoyQS59ZqkLBUIXFzbePn30ksfMtggJEeJcE4t1YDhq0QjJtrRwEegYd6aVCT9CiJx7m1 Gjyw8VKgJiAcgMfNtasAEtMwAoaMoMMkKER7Nai4aqUEULm5RiagoyExTZdlU9HhEjDn9mqA 8foA5ubaVyE0VsiysmZ6uITNub0abPyesLm5RsrQVXQch2V3zfRwCZ5zezXwBP3Bc3MdqhAg N2BZYjM9XELo3F4WITD6BG9MKQzxFa5FfEtpJOY0JI00zIntTCbZ8Otp5OP7hyRe/y6lmA1k 0jPmjheYZwsFl87JJPx5Omxgrmo4RmgYBi+venjabCLE05Dgkuzy08f/8Dwuki1WaYHt5cLc AP3yuIphAvL9++3DHqaPQB/HgFvpB1E+WUXCTrs9wewYJsXPMB1QgMxeFBdKbXmBme6fkjhK rr6LXgh0qr+KQWQhQEhhcdVD9Onj30RBskyQllQE8rkGL0g/wMwk9RSBs6MQoPJvYgBhiSEB MvsASFi7rCCQA0ideiHTWjI0OqgXCIocMFVFwsan+quY9GBlIqVHD/WCmbscSGVVwhCVfxMD CPG7kgzpoV4uvDql7I869fKRnSFlRwf1Ak+HHDBVRVKhXhAIqFAdPdTLcySNc1mVZNRLkJ5i R1OJnlrBxDadzJsoS09DZxbMTOwSQGQSHlSf9PTD30UZhlOxgOl37Ppk09Puj6iMB7Z3Pav5 pw//FMUnqBjAS+EzDEP98G9RfEyrYggvBdAwDFVcwUyvYgQvBdAgPFVCwyzwgZY4xqUAGoal iquY5Wpio4dhqeIqZoWaGOlBuKqEitmp24B0I1xKxYZhquIqZvsXM9KCTBVHAUmmahoLy1lM skCELFM1Q3MahLPaqHwxu7DC0Jt4jppQyq95qEZLoP7sDssbkq7XqtSfWzdwW+FAfYEMdjGb 2ACIO1aX8VO0X4Df+Yd4DblFKLMCQtWk6/lX15YKxFI+25za0MJ2QVZr8hUoamrKOi+yxI75 brXZH6P1NE5Wm6gWDSXxfMRdm8Foo7b1aNA8dIGm5+JCwUxzcW4KXOSzOxA3ZQDQQl3rAaB4 Zr9a4arQCsRBm4Foo6j1QFB8cgi9OEfC5MUCEU4GGi18tB4Nmjz2ohe+Cr1AhJIBQAvfrAeA Iof96kWgQi8QcWwGoo1X1gNBkcAh9CJUYC4RS2Sg0UIiczTgk4iOt4bOcZ5TifEFgWl7PnqR N2VgtofOrcnEMebuOUOjzjcJc/PLhc4hKaict9BK4PqMnWdQ6BB9MANfDhiu6MMKMmCrDcXC WQQjzFDTIyBhuaEcbqq93QRJLDQsnUuIk0S1ySo2hDxKjoLhNQ5dH4dCNdI4x7DlgKkqUm28 r7vGEVxTK41zfEkTrlrjCPqplca5jqQp7yXCrpHGeaakrR5I4wgWq5XGeaGkCe+ucYLEFqeq l4jtJJzYNlhaINnyxNaw/GARBNOC8dcRW991p3MvxOVN7UUErNfsn/9RXEl+zn1+0SrxZPZJ hLN0WiX1KJaK6TpKJW2el7VlmubzsnJCAsFhswErKa2wVQwYpYU2D7gta7R+wAQnzQbMmxbc v6MSpXkyBtySBVo/YIJpqhRpV8UTBnPA8tOjw2DWmvKC6wdMkESVIu2pGDBKxWx+wm2ZmvUD JkifSpFW4mNEqZXNA27LvKwfMOVjNJRY6UDFE0Ypk4wBt2RU1g+YYGEqRTpUMWCU/tg84Lbs yHzA8CniLsTBWZJVWY5jmmHYMZVxMQmd+dgZF1ynjlVlz2ChpmCquBSDVpHxXuFSm67x3guV FLURmpe7agW6cjpYx456cGB9KZi5H7GmHuLlaF8KZtKpZZb/QRqPNkrVqFQD+RvqyJsOGtfG zBpx6+5vKE/Y6sheDwAJl6i1MblGgHrx8GVvaB2iWP3W0HT3qddxyx4ESvgd10YcGwWqu8YJ clG8rkCZi4Yzx/WyLBXpZEV3bHkzix26ziQ95OSirNfsX/4rSkXTBFuQlWJ+fqmEW7qsZiKZ jcbE56+i+LQkGvYowuWXBs1jZz3g8/Ffovi05R4OBlCdV1C9ERTP+de4rEYPDWvLWRxMgmji qoeKfSmruR9RC+ORMyKNy2r0ULG29MfBVIxmqnqo2OdTVoOXeCox1TGsKzSbZRxTlqmOXT9w 5xN2LDpjqrzhNhYTE3cICTtNlfsSaY6qw+xU2snK5Q8S9DzTNBW/VRXnCwpPRdsizYNZwGFo qrh2fXG3XsTdKqheNEXVQ72++FZbKOoX32qDevXrWxVUL5qe6qFen48jFTsxy/TUn7hzf4Id S7L0dObNjfl8wXakzsbB3AoWc05H6mb/EiXfRqdTlBReL7KQ+drkSq4gZ6KmZSKJ4XenCkoo RUH7rc3jq+QuIeDZTATyZJEW7+YQlXZcK62TY7MMV2JsNOPrpZ6Ur866NByoeWD5/usfFZWM 2K8E8lVNl4YVhBLDQqeQCxsOIYFcNdDk2KDsSWJsdMC5FwnkyzYsDceXMRZU7mC/EshXn0wO yzFl7ARFPoaQQK5q49LYXD6jIRiANentW6y5A2thB3434jBeQJWFsWBnA06nTgDVw7zLxbQT B66SdhJWv7IwlF2sfsJcASZaHk/jY7xMMQLEmXu1pMEwYtlCM5SMHz4dDmzaxFcqQY4eFo+u RKGLpHI0/Po3EeVrMmW97eiB/nG/Xe7qiWBtLUQSv3vMFl+vydKC/cMkhqQxV5AZDs0VehM6 vmIGUuisQGZINE/oS+hqqxXYQgerREsInb70QMos0PSgN6HjKzcghS59pZU5N3zHxpth6Whq 0JfQ1dYTsIUONjHhGpIoI8BRJtKVYE/DieNMs6XfZF0JQWgF1tRpjXT5g+7EkRdTwie8qNH+ deRGb2nwq7lCQ7fQWAodfpUpjftwbd3RAmTHEszGOBFXMK17qmeZ86Q44xeSUpw59/9oQbpj 7Wcj0t2TQ8u+pzLnwlqvPnGMLyLXBmlaPtpsBrSL4WlsBzrWrTZK50B2oExDtbYDHQtmG5FW bQfKNFhrO9CxJLcR0r4KOTS2Ax2LfRuhHMgOlGcGWtuBjlXGjUh3twOiMxN6ExbHtQLHH6OX s/x6MO7MCeYwNymcUEBDqE1YLhPkbCEmiqcnHYKihhmmWYqSvs1Wzy6fb7MFrY5zkHZvKGxZ 2RWE7t7QFhBEpwdmQX0ZjhKSyxvGogMIP4OlYnpWBT6Pa4sUdKTh9apAkuN+VYHTR9sCgihD 5lIFks72qAp8Qd8WADry2XopIP3APasCnx+4DYR0XZnmyX1bolw9CCQ/7FcVOD3HLSCIksQG VQAwRJaiMenNSpypb7rTccbFZH3N1tyz5rMJ2lC+7HVCLnMcj/Xd2TiczcacaWuMqopXBXPk XIhGdt/DN/E2OqYbG19hngBENQ9F348myxPsAoyiHHgR2ZrWqSe05ucOxA9vnd2D11liG6Ow WlRdDvL0OJUpC1nZW5yuj96Ht1h8FyOzup1tGkIiomCDAUTyxXzvdfW+X4mi4WpE51IAURH8 PuI6EhpmmZqoGMk1sQTpoWJ00fCFVIzkoTqpmKWLkSZ5qk4vMVsXI01yWJ1UzL6ckRblt/TW LF7oW/7UX2DGKMtvZ9bccC2fzW8v47Eks25CyCKF1/r/cVWGYzARqJ88UvRxiIxk4aoMM7Ak xkYzv4Wkz1iBp5CUVctyJIZD8bR+c+IlqjI8T2JYFLsaQgLFqzLSLHWGfanXLpoY9SKBfA46 UgJtV8ZYIARKCeb4F/HMJK49RsWrMuxQxk5Q5GMICRSvyrD5jIYob6B3vvDdwLRgabxuvMGe 2p43a9n5otj+Ji0d7rbzBV/2FakEVW4HgQouD4W6FAqi1FOj3W76XW1EaYKkVrvd6LgASaFg 6l1e4gqnV/KiRhr3Ga33rJXG6bgmiVYap9eaJBppXFuotTE8MXzSn1Ya9/ksU2LSm4/4c2dm uvOOxUXzwHEW82lGjzfPG3i1Uil8lrOAzYpDnEbYidgKB3xTGkvOVHlpbV2s9ucQ3OUqKSLn BaYBeWgyCA5kGyifXS8h34/CC/BBooYcbt3Te8sxcdrxhyda4n4KRiLGJwn+61YimryqqW7G STkR+wj2CmucbVXXRuCcig+kcZSPUhONs0NJW69a42hHpx4a53iSplydxlFOUy00zq1WdPOa ooE0jvLJaqJxXjUphRe37hpHO3ahehxoCvz/en0/wrX0RErk6zUcRFXmuVsTWqZ+1tJpmKEK n4azKYVPw0Fq4dOwj1r4NDwDqD0NsXdAtA4SvFNM7WmwNBfOYas7D6/bXXseijc1XA6vp1h7 GtomseG0bDml+vOYJzIkBQ0PkanfP0dJEq8jkKF8cgMjrz+EO0SzHOI0JHr5jcA0KT/U1Asx V8qb5gIs0Auxx2iHXrCcdh0RsUlzh3shlqzq0AsW6q4jwiLO30uT7DKsDkoOaDqPYXZgvt+s mrANfSp29crCMo+g8I0nopSYpjtl2B4U+ms6j2V8mNAwrA+MngENw/6ghdka7hSmMo3ImCxo LIb9QYu/5hfEnw9REu/eff0/AAAA//8DAFBLAQItABQABgAIAAAAIQCubbwv3QEAAH4JAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJlV fgUEAQAA4QIAAAsAAAAAAAAAAAAAAAAAFgQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AF+F/3kUAgAAjQsAABwAAAAAAAAAAAAAAAAASwcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEARq+n8hM8AADBdwEAEQAAAAAAAAAAAAAAAAChCgAAd29y ZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAvjXtgLoCAAD2CAAAEAAAAAAAAAAAAAAA AADjRgAAd29yZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAAIQCHOb/HwgEAAJQFAAARAAAA AAAAAAAAAAAAAMtJAAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQBhahVuwgEA AJoFAAASAAAAAAAAAAAAAAAAALxLAAB3b3JkL2Zvb3Rub3Rlcy54bWxQSwECLQAUAAYACAAA ACEAXLV8KPwBAAAmBgAAEAAAAAAAAAAAAAAAAACuTQAAd29yZC9mb290ZXIxLnhtbFBLAQIt ABQABgAIAAAAIQDxbN49ywMAAPQLAAAQAAAAAAAAAAAAAAAAANhPAAB3b3JkL2Zvb3RlcjIu eG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAA0VMAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBvJtuGLjwAABgVAQAVAAAAAAAAAAAA AAAAAJpaAAB3b3JkL21lZGlhL2ltYWdlNS5lbWZQSwECLQAUAAYACAAAACEAn5uc8ysqAAAs yQAAFQAAAAAAAAAAAAAAAAD7lgAAd29yZC9tZWRpYS9pbWFnZTIuZW1mUEsBAi0AFAAGAAgA AAAhACA5OpSPIAAAfNAAABUAAAAAAAAAAAAAAAAAWcEAAHdvcmQvbWVkaWEvaW1hZ2UzLmVt ZlBLAQItAAoAAAAAAAAAIQDbr6KLQxcAAEMXAAAVAAAAAAAAAAAAAAAAABviAAB3b3JkL21l ZGlhL2ltYWdlMS5wbmdQSwECLQAUAAYACAAAACEABDhASaMbAAAImwAAFQAAAAAAAAAAAAAA AACR+QAAd29yZC9tZWRpYS9pbWFnZTQuZW1mUEsBAi0AFAAGAAgAAAAhAIMGjxjzAAAAcwEA ABwAAAAAAAAAAAAAAAAAZxUBAHdvcmQvX3JlbHMvc2V0dGluZ3MueG1sLnJlbHNQSwECLQAU AAYACAAAACEATL2MOLgGAACLEgAAEQAAAAAAAAAAAAAAAACUFgEAd29yZC9zZXR0aW5ncy54 bWxQSwECLQAUAAYACAAAACEAkzDYs70DAACBDgAAEgAAAAAAAAAAAAAAAAB7HQEAd29yZC9m b250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAMmmH6e4AQAAewkAABQAAAAAAAAAAAAAAAAA aCEBAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAItC7AgMFwAA3q8AAA8A AAAAAAAAAAAAAAAAUiMBAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQA8QG0DxgcA AGE9AAAaAAAAAAAAAAAAAAAAAIs6AQB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQIt ABQABgAIAAAAIQBZNqjCgwEAAHAEAAATAAAAAAAAAAAAAAAAAIlCAQBkb2NQcm9wcy9jdXN0 b20ueG1sUEsBAi0AFAAGAAgAAAAhAIGt/jMbAgAANAQAABAAAAAAAAAAAAAAAAAA8EUBAGRv Y1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAXwcZSiECAADQAwAAEQAAAAAAAAAAAAAA AABBSQEAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAFn5p7/4PAACDuAAAEgAA AAAAAAAAAAAAAACZTAEAd29yZC9udW1iZXJpbmcueG1sUEsFBgAAAAAZABkAXAYAAMdcAQAA AA== --------------000400090309090501010504-- ------------=_1355313289-8043-0-- From loa@pi.nu Wed Dec 12 05:55:45 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E311E80C5 for ; Wed, 12 Dec 2012 05:55:45 -0800 (PST) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/vnd.openxmlformats-officedocument.wordprocessingml.document, .zip, liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g8131y1382-revision-linear-protection-switching-for-mpls-tp-networks-attachment-1.docx | .dat,word/media/image5.emf X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt36Eb0alpHH for ; Wed, 12 Dec 2012 05:55:44 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1355320545-4561-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id A20E821F8A06 for ; Wed, 12 Dec 2012 05:55:43 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 3F87B82350; Wed, 12 Dec 2012 14:55:35 +0100 (CET) Message-ID: <50C88CD6.6020103@pi.nu> Date: Wed, 12 Dec 2012 14:55:34 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 To: "mpls@ietf.org" Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] soliciting comments on response to liaison from SG15 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 13:55:45 -0000 This is a multi-part message in MIME format... ------------=_1355320545-4561-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1355320545-4561-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from mail.pi.nu (ns1.elverljung.se [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id A20E821F8A06 for ; Wed, 12 Dec 2012 05:55:43 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 3F87B82350; Wed, 12 Dec 2012 14:55:35 +0100 (CET) Message-ID: <50C88CD6.6020103@pi.nu> Date: Wed, 12 Dec 2012 14:55:34 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" CC: "mpls-chairs@tools.ietf.org" , "mpls-ads@tools.ietf.org" , Martin Vigoureux , "Eric Osborne (eosborne)" , Yaacov Weingarten , Scott Mansfield Subject: soliciting comments on response to liaison from SG15 Content-Type: multipart/mixed; boundary="------------010301040806040506000103" This is a multi-part message in MIME format. --------------010301040806040506000103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group, I sent this one time, but it came out "weird" - resending with another subject line! We've had a small team that prepared a response to and incoming liaison from ITU-T SG15 on linear protection; both the liaison and the proposed response is included in this mail. In my opinion this team has done a tremendous job in creating the proposed response. This mail is to start soliciting comments on the response. We need to send the response before the end of the year, but will have meeting the 18th to check that everything is OK. Comments will be useful whenever we get, all the way up to when the response is sent; but they will particular if we get them before 10am (Boston time) on December 18. Thanks to the team (Eric O, Scott M and Yaacov W) for all the work they have put into this, thanks also to the support from our ADs, Adrian and Stewart. /Loa for the wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------010301040806040506000103 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g8131y1382-revision-linear-protection-switching-for-mpls-tp-networks-attachment-1.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-itu-t-g81"; filename*1="31y1382-revision-linear-protection-switching-for-mpls-tp-net"; filename*2="works-attachment-1.docx" UEsDBBQABgAIAAAAIQCubbwv3QEAAH4JAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0Vjtv2zAQ3gv0PwhaC4lOhqIoLGdokrEN UBedafJkERUfIM+J/e97tGzBCZRQia1FgHT8HvcQjvObrW6zR/BBWVPlV+Usz8AIK5VZV/mf 5X3xLc8CciN5aw1U+Q5CfrP4/Gm+3DkIGaFNqPIG0X1nLIgGNA+ldWAoUluvOdKrXzPHxT++ BnY9m31lwhoEgwVGjnwxv4Wab1rM7rb0uXPizDrPfnTnolSVKx3x8TsbRICuBxHbIkaGMR7a 8ALEnWuV4Ej1YI9GvsilOORREnJ/JjTKhS+U7CsKMfI8j1OBA+4XNcArCdkD9/iTa8qWPVkv mbRio6lS5ds0Az5tXSsBPT6yOW8FhECd1W3ZRzRX5uj/VR9mo1fgCXl5Iz110kTAXQvh8g46 3pHyfxU2d3UNguY63RQdilj5spM4wabVAJHqPUbk+d9WpDofDsxJC0+w+j2ZixPypJHaWjQW p+h9T500AUZO5OHInLTQAJfgr0bM3TtHoiNO6sdiTaLfEY/Uv758/qP1DS75qoUpHByok0VA WrHA9s/zJ2FP85YkrYkHb12gle0/kPZxW0Z0QfvHgUcF/b4c2je9Iu3Js+sM8UIhQb5XW2wC Wn22fEczIM72t6fFfwAAAP//AwBQSwMEFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsACAJfcmVs cy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsks9Kw0AQxu+C77DM vZm0iog06UWE3kTiAwy70ySY/cPuVNu3dy2IBmrSg8ed+eab33zsenOwg3rnmHrvKlgWJSh2 2pvetRW8Nk+Le1BJyBkavOMKjpxgU19frV94IMlDqetDUtnFpQo6kfCAmHTHllLhA7vc2flo SfIzthhIv1HLuCrLO4y/PaAeeaqtqSBuzQ2o5hjy5nlvv9v1mh+93lt2cmYF8kHYGTaLEDNb lD5foxqKLUsFxuvnXE5IIRQZG/A80epyor+vRctChoRQ+8jTPF+KKaDl5UDzEY0VP+l8+Ggw R3TKdorm9j9p9D6JtzPxnDTfSDj6mPUnAAAA//8DAFBLAwQUAAYACAAAACEAX4X/eRQCAACN CwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8VtFumzAUfZ+0f0B+x8akTbOqpJu2rMrD XrpMezZwAavYRrazNH8/JywJaYOnVdZekHwR9x7OOT723f2zaKNfoA1XMkMUJygCWaiSyzpD P1Zf4xmKjGWyZK2SkKEtGHQ/f//u7hFaZt1HpuGdiVwXaTLUWNvdEmKKBgQzWHUg3ZtKacGs W+qadKx4YjWQNEmmRA97oPlZz2hZZkgvSzd/te3c5L/3VlXFC/iiirUAaS+MIFy42a4h0zXY DAkoOeuLFHeyRuQyBjr5PyAmGEQ1CiIoE5VSFvSJin6dYifXGIAxEgQvtDKqsrhQgvQi7Mi/ OdeXGLttwfzktllUFRTWnKa/euXDcRNSDJCldEwMsBwqPgg0DYlh3JWp1xBBibhsCOpjISgJ vQVeWsI3nk5DitAAK4cbol/7/9+FZbhssi4zB9m0X5L90wuChsQg1yIH7bL/pMOx5JMiqBI7 J77Yk8eSDwQNSkXjDh3dcvl0ouLPCbTZbDC3a8zdGaOhIKv4cfE5fsCzZELjNKE0mcZLAvLw 4TdVuuNr8ezyVrLRdL0OqeMG8u9grRNyEGyDopfGoEjGs+3am21Bt9ZbtJzhvZhJkr5BTPoh pJqVknbF8naQDseST8mrkCDMKz8dKj4IQXm4IKNgvLXq9qFhkuNPec7MR5dfhTFK7m4j/7YF aVDCxp1/dXA+ObtEz38DAAD//wMAUEsDBBQABgAIAAAAIQBGr6fyEzwAAMF3AQARAAAAd29y ZC9kb2N1bWVudC54bWzsXdty40hyfXeE/wHBp+6wLrxJlBRurimK7NGuupsW1W6vXxwgCUkY gQANgFKrn+Yf9sV+87f4U+ZLfDKrCtcCCVIkpZkde3eb4qVQlZV58lpZ//yn71PHeLT8wPbc D5XaQbViWO7Ym9ju3YfK15v+/knFCELTnZiO51ofKs9WUPlT+x//4Z+fzibeeD613NDAEG5w 9jQbf6jch+Hs7PAwGN9bUzM4mNpj3wu82/Bg7E0Pvdtbe2wdPnn+5LBerVX51cz3xlYQ4Hld 0300g4ocbpofzZtZLp516/lTMwwOPP/ucGr6D/PZPkafmaE9sh07fMbY1WM1jPehMvfdMzmh /WhC9JMzMSH5j/qFn1uF5rnilxeSAvzEQ99yMAfPDe7tWbyMdUfDEu/VlB4XLeJx6qjvPc1q zdzzoiWX2YML33zCVsQD5obTEGMifjR1BB1of+NdzY5Yqy5ajNwRGiKaQ5kppJ+pZjI1bTca Zj3SJIkLiXgJf3/0vfksms7Mftlol+5DNBYJ5gozqx6z5CWXFqw0QE50h/fmzKoY0/HZ5Z3r +ebIwYyeak2DOLLSBliMvMkz/RuOHPnPwJcvvhlPZ08fKqen9UYFL8PnGX48+W5WDuUXrsxn bx5GH93a361J9GHXcpxPJo/lWLf0LYx11NKM5Nt398WfH/LcEqNhplee94ABH03nQ6WK/6NB b20/CK89PIT/dMzkX/xh13PmU4Bp9HnqDdf76RxwKj92vX9Tf2G1Yg4RYT769oRIcId/MYZY Wq1Za4nFp94G5mnePTrWfrd12tB8uXmiHeKoqfmufuBGo3lEXxbrUNMPfcwcCmZyTVTsVeu1 xilRkt8aAG6jN3m/fbH+semGwxnwXI4n3w7H/KWxJNJYMg9TBWNmmOfxk+XfWXift9C3oMn8 UM1QjjFTU0lMRL2Vmp1688K6NedOmP/6IPEWzXIE9iEFNaSn4td2tOvmFCx+6QaWH155d54g sO7rNSKUy1+fuPMp/TX2nD7x4IdKXf55BR6kv1hedKPwF+UoIQmnOU9/uedOovnxKD7+1O+P 3IcRf831Br7n3fLr4Ad+w3RuHIvRHdO9U+9Z7v7XIc3XwmQ7gW1+qPy43+9+pm+CXeSoUpOA eLMz23Vs1zImdhDegLAVfnUevbqKXhFbYWQgzZnpju89/5LoXGu2jrqNrvzAmtghvV0/7XSq nS5j0uzM+h6S/TL+/qHSatWO6kcVY/z8oXLSOFHihO/c3lrjsCe+CRyonVaP8DgQHP8L5j3l n43oTyLDjMyigW/QXmPzBNEH9jic+5aBNyZWMMav7HC+7zkCxWZn48+PH31zdm+P+z72mnjb hNTH71x544dAGkagXAbrl6tkoQhdr3uPLbE6wQxLovkx8Rc//6VPTSzlwgxNY+7nFd/yBcwE BaFK8OoM/5XTwqs1yJEezX0c2IwFeJu2Qu4etrfE7qnfiBFMmprYrDyxjegt3/ee7i1zAq0r 9iA9yiH9mZrVyLFnfduB6jTP6LXhn1nTkQUeA7Of0DaaZ4E/vsa2itehb4Xje3r7Fj+T7x/i S+oDfkY8LD0xmGHlo6dP3gTgZM5DD9Q2z77f+lP6F5aZATkBVSAhzOsmyc8C4cHj1I9nwKuP ljc16AUmjXny4ObjVcAAD8LJr9CzXI8WyytxXINsAxKyzCdTO7R8w7GnEFhSznJORFfAGf84 NG1HvMZcHBdIo9YpX+JPvIpkjRg0+TdeR0BEr88ifCLI4ndm/L9KK2l101HtmGE8o5tIfQ9n JtYnUJNBkzTn1vUS9pkmKjE3xu06k1ChMf5VX8QUFyqDoiGwmPbl55ve9efOzeWXz50r46Z3 1et++fTp6+fLLr9n4NWXz2wxMCVLU5VtDUwsRdXtka/bqDegTYhukio/j9XOsWHJ6K9oOgL7 PZ0lyMIyqqFsYh8W/wYLJciDkJpjiOcMtozlP1qVNqhp1I6MX3/5m5GiIuZJqrnnkyoXRALs Ow4bI3Kyqzy9fTUsNT7kbY3R9WvLroiWwowIBKomdiRlkxRRnZix2TjKLCIpCWvuANO+lxqX ZCcCBmJKfszLDWEa6SdL+jHC1jqKLG5JBYVFq1jIYNftiY60+InZdMYpO33SOJ2YIdzI0jZu bLZKUyZBdZBK7yo0q00oMXyc9jOzcCy9ntf1IBQAi70U/DnqBll0UaqDOYB4TwK8EpeUG5MT +mUDglTtHG6n2B1SualHjXxeXNge3nQ+X3SuLy7/Q+iJYa978+U69VghZViuejjBwiL/Un2v tAenCCnoGUxNx+masxz9t6A39YA4vPl68Vdj0Lu+/HKRA8fExiYwMDU32kq4Nqf7CL/WNbRk EKBximSneYzI6lLZ4ejCTgCltC4WTI45pWREcJBcNf2zNZxuieAKP0MhsyC0+qtMJEPIxvgc 4VGE7On3Iy8MYVdLG5LC6A4jaPADvgX7/dJiYMxD7MCD98nGvcL8aDAmg5jN9iRKpwGaxFJS A3g+RQ3ojZJxjlgHKK6LNW8xH6+hA377tE+j2WraBMxRhq4r4ANtTsR7G2VkCEPHse8iz2qM II/lVxTDL2fxVfXDcldAo2NLuwTLfgtCtnuQezu4NzzXedbg+g505OvT4Av8MNs1nTNDUkND CMY4YexuDeobyD5IXltikh8jlL9cm3JgdyfgXAwQeHxKcepNecRPIyCfWlbImcTSSJ4Mk7OV IVXCyJlbM5vSXcmhOKQCHSGC32z/x5OKlYI04338dmEII4mGarEkWP86R9IASd13wfuzYn4q VDSNxnEZZ2N3W1xMiLB9elhLu8cgRBnQP22WMQp5J3bJxhpEogUR/KcWRnN6fTAoSH9m3VKl NXYWJYypGKtRCQaQNzaK9LZ1LI1JwWbAk4Id2qEwVmNTT1mpQqrZd4nHiaWaYx66D2TmqZjL JSLrJk7ifnXZuRx++WzA+7zpfep9vimW+bfBNogt/750COqNIh0SeHN/nAkIlcR9mfdemxGG /Oh1IP+kQdVHYKbF8SUVs9m+IBfTANH5m6/7N8YwnE+eDa5PQSz598TypJi342SQ+O8qU0Mu PGwpMJV5C0+GPHsV1pEmm86t5iKLJNQq0ZHlA+rPJRYUaxwg/roW1A2h/LYF6e9ln4t3oSA9 hNSvN0WVJiLrsGINIe8pCU9sLcVPj5r1816HACxhL8s3OWDV/nhwUmvUDv96UEOdRImh+Ff6 eGYuhpl+bCJzELZ969GmKlVOt1yhNMT0kU72QuSS6d3gyUbGm6QE9aHGp8HVcP9mYLhWiNLA hyA1Tb31p0QotjIyFTXxB6fk34Hlot3gfNT5cbfFoawE4U771YtOX1HzBqKL6Gut3u3XK2IE EYxIFjvRuNkcT0mHchUbMiMxoUcxP04pbSWI2F1OnetE2CX9dS6sSpBNgt5S0xQbnfFaox0T KRG5PbQVCcNQ/Qwk2oBBmF7KderBkt23zRf12gkz5hKTRAVQtXqtxDJW3sAEzWHMc15L0Z5k VMhGqS3L/py2rg8cMAU4hN46CqjVEoWKS8gWJWB15oCWbJkcVYLv058U8P1sGD47UVXj1RAL 7fA6BSwpqip5Vl5UN8i8I+vz4oq8n839Pw9okPwurFZMkHkQtjbzzvJH0w5e9m76KeQGU/i6 ogZAs1x7UpQzz1xzFitqrkJVkFBmcof8vueGRBmoLVRFqX0QKxltc/akHrO6V0/ZZLkIZhRX X+jw/HWW2P72cRUmIWSR5Q6FgWCt1O5Wl//9YrYwWEPjdw/aXbbMw5VQO4/MGf2Yl8FlSKKG JMTdT0nSH6KStN7foHlju+IwHDlAv3txucRif9uykrbufrOuQIllJGUl/fUCm1YZrQsTChmo 03tvOlegM4N1A+f2tbyANAnkxmfeXOwFdPqtVuecgwYZKshhOJygt1U7d75lTQAQ65t8uQrC sG2GKV2x3DRX5mN+LP20M2FpQ2aUjXcfLdd6NPeMWnW/XjOG1iykwxC+QUVt71OT+h0qMGjp HUe0tcZwC5ntVq+i9jTBvOmvb1Dc5SOTHp4GLciKucAZEDo8tm1xfyN7sRKQ5MNo2XCCot5K uvbpbLlLT9KojekkIGyHrnG7UUuBBbxbxc45iFLqCV/gGOkLYipgmgK8K5rNGwspQLzGMeCm Jv26eFuvRjUmcr8KyphXSZpnZPy3GCdXzKtBy0KRLG9bdRHEQph1HaxtNk7LxKV5V9/CPvRP Go3+GkpPVBe1P+L0rW10RiNTl48COCr4KRT4dScgYTfOI48sOI44R5ZJI2cAUD6OTct2z7fH QeC5GoF/61P/+hfNpMH6Ch54gTJ6H6qWAg1oSrJvlkT/ZZIwZZS9CkisyxuL9vzGyrhM0JEJ +yun8k1/f9ghuwHEVRBcoOz+qdk0cOi+ajRa+O9xS7NDr8dW0ezlClnn3/r73Z+SiysEz4Tc SCosHAc8pidSD+f2Uc6cIg2yBSgs8mHePuAUOLUZwBFwLvW4R6cEz8fp7FraTSQ0yZiIwr7p dludkwvxZWmXpTJLP6kHCUuw1G4LkDtgkPsXS0IGdR5KLQKUi1bB/JREvrw1WOrJehKmiUc7 9nqx/9L2yd9ZHr9ALUVCGJ9mq6nyVxYrJX+6XcV7stXQIq262G2VniwxqPJbhJjk+HFB4jQD r3kndmEWMIkbmhYquecWQskNbI8HA32UuDwmvLcM35o5z+ifYNpQ6mkxAeWVQAqkyM96jYm1 f/3lv1MogMew5tVL7jXPD0Er1CwZV3KaSEci2ENNW3zrzvSpTV1U6yNrgjKPyKU10Vdlmsxq 8hTag6iSKPP7pL4rs1Uqi/uhotuc9rvM8NrpadPZL3+4ns6UZGcaXg1brf3e+wPjm2Xcm4/c emc8DwIKHTK/BDM0t7MCw3aJkaj3huCdeCuu+93jRutkCTfVT1qdfjWpd/LcVMaGAD9xIvvG N13MDT2WsIvod2IZ72T91/slM2kd1+unPZ4JSn24piyzPxlB2NTUaaaycu3XX/4n+0xWiVIj L6oRWI5DhXjAu2w6gSe22p5ApuxbG3ttTtArCQkl0zHsIMDxlz0DDgs+oBwT+ADTvnftMT4e meOHOzS1Q/Mo73YJpWu9487RqaC0ng8pYJcu6TMDtEu6xdsTYrkMkSL7IbaCanx6oMgMEkhW bRzXT4+TvOcX2zxQIsqKparH6slBOmKEz6Np8J6lUTPxrAIDL7uoDLctJxpEgKLhsLP0tZD7 QE4ma+jDlDTQeC77yBwA5bqEpBeVnFM7mI9khWVmd/SjxrhWPKaeORKrg7zo1hFtRIIfuMJ5 i/yQCSDukh1ImfYgjj7oDyDOik5UDfta6JLiBxAGZvdid24XptgOcPUG7BYpRkjBI5A1MG6R fyO0JAzNqE6hVJmjcYI3zMMvQNcMBUqPLMtFZzkF1QfGDfAYbQGR/AqMOWH0yHK8J4HUiXmM PR/9gqC9OQkY3nuBJb4OWBWqPWkKEki41lM0sInOdVAKpBoC/kCohYMskvhEXlF2OfbcR8u1 0UnYSjGCtPgkqG7LojHMOzR+3dM9uQiHBd2eyCq+RSYRVidMGYNtGSx6MOzyBkkdcEj/NmpE js5geKB7zrZX+JP3ZKFr817BHpjuM1TnWNTL32fCjTvaBNfLJogFgxQAPPO2b5noHB2ZGqK4 hYwL4lJIkzSZEsX+U/SONu+sdEB1RyuEWIYk7jIxreODsP0q7JGaShn0FcbRUavWQwdXpZx3 AcnqWakJJHD6BSYu3Bjf+i86vy0glJxfOkQCaEvRZ9Pc0iZmvfUcIDG5pwIts0/c4roZqqTq 2fJKTSNAs2M+fwPIJOEVy80x/TaXi312qFEz0CJL5c0w0hMCDaQS6CQRH8Ozw3sOpSx43Mt1 WxtPRNx05lghnC6wVPooV5rEZWR86+L8JiaxcWmukZkFlMd/aEcc07dvnyFjgtMNHDtjZvCB LWRF4TtCWdmej8sISHn1hyySw/7+gMZCMZYEBYFLrizOGlkkTY/C2yWTg4MwGZuPPGEcAZ0G NPDUdu2p/YN4krpB4nIFw8ZFCGNcjpBizW1sDMxOEaGwnUdqTZ4si8Bnl9RQmt+rqZPO0S+k cbQc2mneMgySkOSXi5beBOmEBvdv34sEPUVEzCV79kQXStyY5dfGjRb3rxkubH8bvCfGzVBB nZNMdnUQkRdx1vg/P3rncHVEzkh9GZ4/+IGbYsvSGTYGN0Ys/Y4mTUam5oBWBHcGdxSglx/7 T+6e0ffQZWB5YGS7uz3k86uvud96GvaH70kNTckrZBRESHDCSYQMXyQ3dLlok6dIXcnRgB1N 21/FS5TxzG8DRmcCbQTJ6IoaY+o9ktPuo7EePgWiDwDcxrd7eN9D9BVD6LNP0TRvPJ7D8cY4 g8FehMA4ywvXB9pgjFFwAlHSjVqQ+XOUqk6kPhl7cweeDo3B5LS+m6Tsyas08esAVwwQxpvj MXv8aD35bMzd/Zkzv0Obqzt8aTDImnc5hMoF8zaKo+1bG6GHDB/o5xCH/jY7gz8UnbpOQZNu ckxcTmK5E8u3JgN4yefwrx+4CgxnK9mpBhZCqGHMWN8RfGJDQjD4LTO4Cy7Dfiq3mzDUeEd2 TLrMeueqcS+vlnJsR3C9Ja7TIyXZeXmkHMFWlCJssGWoQAawAXB5QqN7xhsFM2xrCvHnTJvp ZuQrkyOo9o67552KTqriVOQn07mbu8ZHD/GKMfn3uhOnOdB+8Pb/cp0seCnMJmVxKKkLXm6u tUlNMHjSOSdgojJ2GaGfsCThjjEtCXupvynuz6IkFUBTIjHSWNbYRJSUw3nBPcMvfZvNbBEw h2ZL6oG0Bkjtwx8mdTpD2+6AlEhHJL2iBX4QmxJRIJucmo7rWt+NGm0vB9Vkcnn7+P5GvZFL 3BhE8XaALzElxxotAzel+NzJBTbIk/kcGODjJ6D0CLaGISSB7FuCIYgKkXUA5xPvwBR5JucQ WXJcrMReZJQ1TzF22n/OYYJGy4RtfQ5wwyCwhk8rU75H1ZP+xU6jmjo0LgW5OvLqtU1/7rO8 mTBHnwMocew3chbNZr0FxHu0TCfBN1LN0xVKY4QpYHE/Aw3DJ8onkZRSsoMM1USCo1kDF8Ey 912yCuhLfHWRPeNoH6T0xVyjKQeCZko0z8FFS7RxCWKWY0fhz710fnqyy9TDPtv2iDhKV1K5 DttOt7YPDAADdjuBC9g0bFZi+1jgKZkIDgCEcEqLUnG5JEmG3G/CkgBmSTZesIEbsClWVywS TQSVFOnWDKpGCyiy0dhKz7F7ziLbVoSsXYeX+uQJbQ4HgQBEo67rOXVtGJfoxTVHvMB/3iPY gL0lMiA0iO6QyGbLAqIg49KwpColjX7xVg2BgpIBpi72hawEk+LS9lTYCY5HxVkBKiXnHLUO 5rOZw5VdsIzhbYQ2kqb57L3i6BSbJ7B3KctigFI6LsfEhW5F377ja/PIXNkqGuixXpikdbax EPwnGyw7izdINLIKhFefm61uN0ttmc4saY9RFajnOPKquOZkHLL/RVYn4l4p4r2uA/VbEf4O yXYcDGTPyMb93KjnGVOMkShL9hk5xSzweyKYI0KJ7CojAw7dT9+AVUj9pt4BMITboBGrN8jQ EgXqr4sCiIIjTCa3AoSbw12lazRhYyUiZFHd3SLZy6l1rXiNLAQmbNRZp8Qm7Z5FmLy+FINh qMwWfgFiuVxoS7a+hL7ti+wbVbqNA6NDrXbJgsGmc9EIJAh9RBBOtb8b5yRPsFOpQmzPsIWv nrCQuAJNgCO4ZsEOluMF67vlo5rrddIkKuTAMRuFPcB1sisY2EkwVYmc0D6BZSFDbSJBHcwp /AxsAtkETqm1xLGMdDRCtWxdnfdSlosCsl0Y6Jzn1hzPyVk665vrRY/QQscNmNYb/UydcREW IuQv4B9FpBTldFZCkZuCARZAT9Gkc3QptAAXiU4Z8CuagY5seiPwXe/fe9fvk8waLJpU8CPu dVlvpg5OrjIXKv4JqXLNFrWPFMajoN6cTl5wBIYiPkIyIVaRsbUAaRaSa0PT1pMQAImwPSED VVZMAmOEP3JE3BYvrrG08vxJ+wL1j9gKqr69O+SOYZ05c8a6N7kXZCVaxhSVejgzwEGj7DTf +D60QfLslHWIpYOlNVihPFAYYxyxdC2UBbhJi5BypqgoQpWYNw+jzFV2BW+d6AgcU/EC8m/Z mb8N2lP0U9EYNRyk+QCLVAafMM6j5Em+bD5N/9NGrX/U58Bz2J67Dkk3GYKJsZDFlWcO6TQG 6vyAx+QVrG+jbZU5udTJuJ273Cca4SGqjLZ9cZQWU193V6X5upJqSzkbtdpBrUkmijhTcWAM valKc3koroGKs72JzOS+s74fQLzgzZoGchc4TuOrP5HuCu/fQ77ACIiGyYIlYgscKMDBG9o+ UfUlizLpjZxWXd3mXNO8XJVuynDcRtQk7YKV3ko1pdU90tKPoCKxyyxrpkV14+UPRZMrbxMs 9PcWWmGrcgXRh/lY55b+5ujGAW2jJ10VZd1SGjsZoCCRxokDx/6BEr3sGssqozUIrTdtifpX 3viBdDtAbBDXSr27+gKvwVfFpaK803hH5ZTZWb8hjkapDYHnCPdoqjzvl86nhOLA0XBKHkTn z3BkbpI3Cl68omT6axWJxLHY3Gn6F08GA+isySVMVB4w6HwStfPZOF+sTUXKdWx8NtsmY45+ r4IGAa5JxBGRXK/dTNlep9G86DaTtQ2RZth+rKV9O3fQJ8PJbrGOYDuYzZK6hFcllR72hTcw 92d0khq4T2qgDDHXgBGdA9qmmFSsINNWK+yxNOK9Rfp9QvdBKqEROl+FJ+Ml5aj54iWtjYWR u5Ld4BdPaeuACGUucxQocqV4/AzVhHBXyf+zA7hPtwha0XVfqnxJHD4I4hJwSr9P7bt7WDd8 UGEy9/nr4Pf8puVrCnSAsikZuKTSNaTkKQ29Z1x9YWNryAtF8HSEIkg6WMJVcB7VPaAvAokp JSrIj/dw6SzVXOM19Wigf+FrxifL00JVxu8SQfTz7tHx8abOUBeZPjlQ2JEzNlSnfSXVJvmM mGiaMPGsYFGoaIntlFsfeToa026b/EXBOgslNZ4RwBYOcOYzGTM54aAFpOvo+Ki5Lq9IZFZA 8ruLJcS2Q25DEwyrlr+lJFQ8ifIWeVPEy2QBLNfW6lR8eubH9eOjbqpcdalJl1RKi+fZntgI a/q6jiovngUGWADKi+dVYB9Bs8xgBPMJaFVoLOrSyH9H3BGKCErHvrtDcjirWHVSHc9i62dZ qNjRtxzkSfjUP2281IgTC4eKoCveDS8SGcE9qNUgsEdIiX8aQtMEHooHcK0bfoaT3nyGJKoU wGCiOMulo+TU70yYF7KqGmmyKNsOEg4v9kiryUQ7qWs8AICkGhHweSwZ68wr3zRfbDxQFu+I Tq7aX3W7WtB+h0oEllh8u57+dK71jhBvs+mQJh2PI9sICCG65VGIimtDqMhBFNUH1HxEll4R E8nf5Nj9VfdJL79sltPyULwyorYEUUxeNAaEEB+CMeNWgLLEV7fnMrwcYeECqClt7hTWC0zm gBXRgSE7lzSZj09bJzWR4lkz/k0mSQzKJJybRbwN0SnfgChNiI0LVtEm6lBCz31LoGANPYsl LyDnYiTTzxHeB0oZqECMurTAp3LBeZRvvNWcy8my4usqOMIilteklstOMc0kb4LkNO+NT/MP C4wsMBQo4CABn4h17AeG0AcXDnOW3Lti3DY3SZzBS8zO4A3yJbuIohYSFlt2wrsimR6muMIn bzRmJ/mqVM1oqPKhluZ5rVlrrX2wMzr4s/So0Kk8BB/9ImvTxBoEtP6EErB7eVOljHPEny9y hHWsUkpt5QYttI8EK2S3P/Hg5RMmu0c6IAvGKWPuLaBK4QIM9nkomgnFS6ZpVIQs/jZHsM7x Ep2xKM4Jn8x0EM40ECjkqsMAsT6u1OHTKzDaXM/dp/OyOEeBWtm4fn/qTax14zrSplJStWZc JyJhTKe071tSd6lQS3nBuqi1utXG2oKVNqjj2efYVM1s9RKSBYPSTXSFbU/0KHl0YHxGmA/H OdACHSWc1PacA8nZ5mtol35r+tw7Pa5rF2HorCyozZdR4eNa9Vhe31n2DgkStC7HCJJNh5Z2 iMq2/EGo1rvt+ZQUElcZZftYbWamw/44Q4Lcg3lmPXciqqJzH6cbtmxmVtk+NZvtSaDnJqoD FLEu1X5UVAZHiST6QkAliggUNA7QX3AZ4bI7lsDrCCTWVhRtOxuRWLIzG316AQm5mTVgXIYI OXPz7eY6SbnmQQP/f0SON8JrnHbA4Xgq1ES9UCydlK6S5fF/StG5DByuidzLlahCvpdP4qhZ P++J/j+qV2JZgFGT2DD8FgT5jrE7Ll3msn9jDD/WjnDwLMv4SelcTkPCx2t0WZviPpgJlyul 9nc3q+LWbfn++1mUjlLydBmX3LI0wiX2sbT+JAqgbrbWqB3+9aDWOKlnCZB+xMZDPbEW1gV3 2ny0EBFE2dkuO7kd4Mh79Ku3cOAESKJ7OgJ4fL8Iw0vqMG1RrHYHcxaRRJGg1k66ADJhm4h8 uDgcTNYsOsGSjskq5qSYbUB/UNhglYnCag/NByvn2u+AtiKtN0FHZUEZSkZRWMlEV98pwmEz nGck+qvtp9f0eV7AoSNFCQFli+i8u7QexRFaFBmgkl3ZkypZgMGin/FWySZkIIh4NP0YZ7PF 7+LDuMpWoFp51neiVp59+4QpcXxQP2jRjOljQltuFCNtEJHLEkOjSTHWpOV3+rluL1eCJLHI BcNsgumc1Z2zN6HNhT9w2q3WG+cb8rCKIu678rcKFH4rZ9hGWjBFhITcS6VfekFQgHo0PKcT hnS8gySczyZzAZAwyxGvv6XOIlGJsynvOiHuD9BRG2iAOAP6RwIocAZFwqob+lQyBNFJJWnp DeJ4CSkBzptMLXIoqcUw4g/4HEWCieEIMQLc2kPmLX4b4DEGVoyLCihKwU30YdAkoOeBV6F9 jpwK/ZSiGqjumlCD2QEVNQXAfrJ+cQgbzRDRI/GdxI1ff/mbMbTGOUFPWwun/Ua/efJaFaq1 9E1buaJGKUAv4532QfM9cBB1FWwi8G7Y4VzwxROl6jMmDNLxODUpd8cktfBAiK0YCiBLLcF0 4SSlaVSTxOxvEIbS/W51kEuJltrRlyFfaXFMOBTqyanpvHC3PilGlq0xqNlkonUFSL9A52wM WhhWEmoXWplrwYRwLZhBGa1XmtSFyEdAIC4fCVbvtpXaLbWFqzJPFCVfFlevq9vHo1+kzYzS xNgy35379uTOMm5wHfLZ//2vITonG4l3k8KsgXDVrhbcSpaiAn1ygPuyjgSKB5gtLMp3/S9o U8+sTbdNrNM46Y99NPf/PCjVuvjc3r/AQVh1LhaJALri9Kubfps2R3wndx13xqip1ev1Vj2p NtdAHj6GRe21wBdKfefuM1Pymdrsl0Gs3pgSHCsvGBG2j8ihFFPJEOfd2Px4QSLlhWZyhCu/ EyTSb891lL2SzPsZKa34zT9YV+FvknV19NkQ077N7N+WLOgBElTAqWRgIeqLFplpQDGt9/L6 xhLsOJoZd8ZLgm12ZlvAWrTy/UZRmLF35+IwM+YB04EKhbPPTkD6pk3INtqXZR+3haXqcYsz rKQc57iaQtnxpDFgJFEeVrhh8JJx9wy+wbe+B8/oaiwuv1JOl/gaNUV00QYbHvAYJ5SNEQ5k o6Zp4ongHAqxqThPhtbk0EVsiYMmGEC034OPQf1s4T2PbX88n1InM3T7Wdcva9Wr3fNNxX3i 8HthpKdMfknYD28WtVZk/wVEKfSZTiguDIMb/0EoCPdD2mAy2U5/sXjsOKWiFyR2FRINHEXz xkY+/LYDUvIlSVmarf1cXVpJT4MQzaopLuPC2sQuIsQmtT23tNzYhHKCVshTC5ObZXA8ZmQd FdpxkIkqlV5hgQSMpDuTByrVuQEWpLg/MH2N50shSWByqbOB8fp1RN/AacDFDyhgMz57Y5iz GY6L+jbOCDloc45QoZuLpu6A6XET07fNPVdHZj0VsL18eAnxTtgsG+M9LZ+nBRvRedyLZrqW Nw+c5409ufzSowwiAjcCZ6JWyhJ2ReAeJFI32JCZl66tVnVBsG34xk/IEb4vys7YDMRfC9Ym AwqL+bfN81owymoYVJ5ChAtKA6UeX94WqV00Wrg2VFmiqwYg01HEBWRKxA3XltbyhMnf6IPm nikK5Xy0brfRTedgyu09lUpRm//Fo5+cV2vVajJUFfFETLR0ySm2pFShmVaUc+F5tcHCAl1z sXqIIltO1ADTMU5cwibPnErRyxJmB9tPujGScnH5IxL/4sbfREMl9JLGt7iDPoK/8IMwfalp cVMkDgCHdJcTK1L4L/JgKSf7+SIInD6lH+NHDCSZdUJrLa4F3Sgd2uBvA6xYZhI9VRa62eKU AuYg2XhrJ07FWcsMrXZCDfi0dD8DSUn28WkJfRPezgYN6/LYnUaPZf1D3wSdACTZ3dyodBeI lkA2cdGiCSSirs9s2aRDJjlV9yZoVopi29CNemLmDEe+qpK8KXENvYqRwamCC8KkVprfj85u x8JNN4lw4wWpBHFnMQW2kDA2CaYNXAsUINDGPQewc5n4QRnzbeuW2puYRI53Gyetaq+RNKRK mWn6TT/N0D33tItuo1ld4yxJ5ZPpzulmKL5pPL7BjkLQMCmejavh4DCYmW6F640qfd+yflgV 0QaHDBK4K7BYcImkw8FYYZhwqWMHVYtxjwDq2yttFdQ/oZSf4gRTacXYaNmrelxgMrBIqHk6 5ROz5YoUD6fgguioDlOJmDVuYSw7UUqrmtpuJA0f/rL1HfVbdF237JEhHDYOFOPoNtlIvCK6 29wMPbog0+WzBNTTZw/CErdIPmnk4GsXYJoC8DK8Lyzp+kWzddEt6T/1qvVa45SZVx4g+HkM tc/FF+hlCAqK8zrSqxrxqbPgh/pKoy4+TravVu8tlwK9B7b8d09nI8q7iwNNM4CWyvXzriir hYrtE8uTK4icHJ0ns9nlLTyLhitzcYdQaotzsi53siyvbXr2BdWVRro4b0uM2T0/7rZEi8wX nGxRvJCSjLL0LMOIBTSK7q5bdYNf8Ey0oLHHuOErPnNBwahVJ7BQPl4wu7hbzOIZ7dgSxPk3 HPfMnoHLVPWsKIcvoBLpINJ6uSMHaQW0M5krXUODk/hQDZhX9It14nDbF9dlHeXzW11qN9uu LPnmi/hgRJOZThmpmYe6bGqw6QZTe0lX5fyzXy6M7ZVZu9R69car8Tkb7Xk9QVqMMnlSl1p2 +101M+7SmNoyli733L1Sz43DaJt56nvlFGYWvYNd3RLfrt1tRDKMouuqrm6EistqEX8zOMqp fnNVxijF7QXgIo7viOvdZbHeK1g3belNcoqBbAec1XG58MA4X1KkuyboFJCDah1wE+Wdt+oe bECprG4wvWTjoUE92VNhICuxUSeWW/b/CwAAAP//7F3ddtpIEn6VPuyNfY5N+IvtsGtObCfs Znc2w4HMyeWcNjSgWEiMJIw9V/MOe7v7cvMk+1V1t5BAYCkY27GdC8cWQt1dXf1V1VfVrXkz CJ1BtxOcliqV2ofG8YeLUutvuNoJ+L+270WhmDfHjhedlpQMo7PQkaU39KErvRE+shdPS9/k 4T879Nmb+AFR64z+ivQ1fiS+srHNfI8dTBzPCaNARs61EmEkI1W0oWDrwYmbidsMp7KvTkvT QIUquFalltjrnDXbzZ/2i3Yo18jXtCm9gbhUI8cr2uj2UmiFRdvcZqCYci+cOGHo+J7wh0J6 ot0r2oHtB71mGop2JJckWnvVg+q+mKgwlKNHUPMdTXCrnJIWYGJKADG1AEGQdHF+dHHcKNlL KZyyFz+ooZy5gKfl2zuJS/xkDWrebKJ/cdxrFw+5li5u1JiGzz4N7LXqsQGz+BsGFu+eNRqM gVDbzVTfGQn1DXc/jPDzTARq4kdKtP2grwaiN3ei/tjqhOjLWfh8NGPN4vL8gRJnIvLFyBcw SL6VSSeAZPqRA3uUUilYmrukvz0SvFALtyToaeD7w48ByTu6ncIejgI56UUyiPTCeoiJgNHt 5unWR2/wcJ3aP1jq0p2SyAUIa5YIuQFF29t+CWR3xizXot3JNfzWS/J1Ika2z8u6faci7Wpi C2tYvindq7x6OauRkTVgL8HLycaRr2PlFVa5Xem+AbWBIocjLNytfCtBipnnDJyAfBrfk67o OSP6ry0dVyDsicZKwOCyz4M/pzIaF0XZ7eXTelDDpuX+8KPMVklxpdQ0FKHyBuR0fu6KFHgh EmeHXPTahx3hhALT5wfw2mfeQAU8fcxYCCYKCuN6PiV6ja44yNoRycOgJIXr97EuL1wlA9H3 JxPyv2i+w3CG6cbaZL09PzD/iz7dGbIG6K+mwznziAMEOGpX4MKB02c/mKDjT4s3izmsXQ3d cEcPjyItS1cVbTrXUl+DUS/AYVwS59ZBaC5xtw4qedrNH2Xma/X5EYDZeltOO1UvlRa8Bwft fElN7wwY8yniLNLW7Ayso+f5EVi4vkIWpmhr248wW4FEp3dhidGifcolgTXNWqcPSQlt2zc4 8Q4cxz5yV5TDyPTny+Lc+JCeL8BQO4PksMjHMFIfHAj/Gk6lFFMVOD6cjiH8UlyBee8je+d4 M/xmcgfwTLwIWSrphgfaCUFGzzzePs/eS+SqdLxQyOnURWcv3aczw+QpUBC0k+ltmRjPSE8R 4Ww8h4jSTS/AriaIGGhMImCBcumY5ZGii2998CGcsOkr0mTD4+bNpNi0zL0YlXqtXr8oGX5m Ta7pnvqLREbBjJGLhd1FeKoQdnaQNTwPlLzitP3U6SMdf90Mx3KqiKsXzuC09OtNBf9+jY7f lgAbfjAInd/B4teqR5XKAf8sCR+5bqTZ6Ba/OQ3UUAWBcjkDf1qKSsxDnJYm7xvv37r4Ua2+ f6d/vL1RJTF0XFehpWEJYUfgX+nfuSf8p/jmA22iWxfNThwzt9fNISKVGUZDNw6F+s07LTkA WMdTHwI5B/nh3Cj3J/z51RlEY8F5vPjOcDYR7yuimnG5IirifZX0J74b7uNAvK/h9lrG9bpg MegGubG7bvqHckZjzn/ETZgOoUsZXz5a0/Lx5pb5mSfmnvT49YhS31/XqWol+YQ36HFC8MQw Yc7VTRTMKPHuX/E8IsczcLAOWZXoGpTAbwI3PTBXOg0Eq8IS8JuwiVfimp6BQpKBg1tlOMWn VMLh01epcCShlrGOJvXTqVZqUD/97L8kldZozpy0oFk/bpSr0+ivY56B5tvKcfndNEJly3XT mWA1DGQkRdAkxQ8+Dao16nbkRKR6yW6gQ8jj8nrBL1iC94IbqZT2znHD8sdbpZ+zPZ62M5oF Ckr75x//KWyKt/f+Wh93Yv6zx3ojJ1NXkXNVtNHtB5rdI7C/Yw9+mVu4R7mc3NZADZ0+Vnf/ NteIjZ59UFRMUTmuNM4uzrHgsGzyGmdkjrNHuqMBPkat1JoBdi56bNLAIi54/ZTYfzTkebD+ 5lYv6lHOkpztl2zrsz/nCAv4qG5QqIgwKjWfOUpTci3TNQqFArmJpAKhSxXNFfJnFC1dBs5g pN6EyoXZ9aFqfuhQCBo+DqzZOGtvJ4Jp2ZCt6NPvYfIpX1+02W1m+2UEpUsSfSiyt5qn3Xsn e5cavZO6uwetffB65UcYo07HiVfIIc/sFXLMfoY1WxeQ038EFa0UbTPXNLYKr+4niyhLdeM5 PKnth7LGzfpEyY8QxedErAt/Fh36w0PaBuL04fddw++aU/ESnC/4geDsPeXQ7yLU9TxDU88z 94MrqiNhmgWVItjR8FhZsCfqTn+B+0rZCF3oTv4qObRwAZCVmCDfoSYoqvCpBEOJYeBP+OOh 7Ef4RdIPhO7Ij0hye22dxljCKRdjcHSYkSlyJ4ET3dL9HtftHNDcYdpMQ5Hf9+M8igA5lv1Q J4J7PbSZsUtsTSLv2+R4fDwrEGBlv5c9P67Xj44/Ws65u7km8GOlVq2/4xjcBD552Ggm15V3 +EuPmtmwuWttPGU6uRr75370vHlJDo9m+abg65iUYwZu29V+yRx4+Dsez92pM9U7b4a/X9A+ t9S1PMC6nmdfQ2acgRy9WWE0EsLaCFb33f2oVUuZmzxh+2atMzt2aEA23M5LACU0KiGPPLOw RtY/e8zY0QoeOEOkK8Bmoa4qGROfdXrI6enkKlEvtMqpfotXd6h06bWBmz//+G9X/TZTYfSG C6f+/ON/yGooFyVfixxuEibK4pP+gFqxTz8QyF9oUDGQYx6vk8aBboG64PpzwAUDEqOYuc9s BLI3xnlbxj0phjI4BMRwjp4pCN2FladT5h4FjABHpDchoeT3TMfRh74MlU4V3zl6GqTJM1Pv pTuXt6FJ+whsVxojc3ogPnzuCoBnt1sWX8a4je6kRHUIkoR6c6nG8trxZwHkVFZldA13AJ29 vkMELN1O+WhU10Ho0ruFLY1mnEn/DpP5FFW59Q9MO/L3GL+eOSpnWCgPTdViKlZUMFH7ANdk SExPstzQKk3KN1kYv91pIlvMkMwz5hrZH6KdyrSZDfQYU+u8LCQ8pIT6CltmLWGRyYhKkXKV 9lBf+3UfdtohzYhIOYzMIKHOYlPYWXq3MPbn7pPgdA3uYMYZfuSDsjbY7bV7+7HHYMo6jUOR XDB6iaQ7H4sfPoHoz5ArhXrbCTBdX3S3q9f9YkLNXCQnlIAKnQ5oSn1avNgH2BZ7uRiKXmIv VlF0bR3kamJBghRuYD8bhRZLQUNmWsDL2kGLBPpORTXsSZOMO/tQCSCL5MIY0herIvISdTML 7aN1tfR4qsHV9U28jqBh2fPIbTCGZi3MNfO4poIcPqk2DyZg8HUNuR6q+g7H8UlCnEZ+LwH7 A2SbPIaFhHOvfW5UmRm3fx32ZYiYgwEvopABpsPH4kMs4HiU1NZlVxB0OPZRQIA74kQmLbBE QIeGUcOFOhPUUWDlxYbm6blMz8tvW3GP4Znzzije0K3rbgpCTKrqZbmi4OjuioLG25Py0aKi oNaolGtvN5QU1O+zpKDoGs4T5+WL7ApKOWrZpfS6RFInoWwR2sQi3ZOwZdqZI688QU8kPUTD c8B0kSkx2HXAMY6dm73L+EEwmcSgABL77OqTU46YyXNvExFTKmCK5qBZ0Dx77gTIqBVDlAIU hRuGhCObWMJRMr5CwoxZ2yXgN8HBo038uLtzllIRRIt37SAvrIvF94MXbWINLagdy731Huga z7O3X5wYKooN30PwFRVL69PCpkJr2bU3RbXWZ2PtSDruOowlFrTdeyYuLQfkOuMEEcD94F2A egXHi0IvE6yXbIewLM6GqIUkFiBKylEOdBAlXVqqZjcqrT0diSQf/1UMrCeLCISepQN+Qg14 YCi+dEE1jIAAl6bknJZ1TIjCuaLnEvRkEBLUfY0uZoIzhrHzhb778KQsfnKu1NyxZAhLhDfz Mc0PYHNDf0XOEOOKkDcIi8QeSoTIhkU50BtLn4P4UmP4QZ3VDVRv62dN1WiCHxkE7MpIxBUw uMm1m1yu4McCbMHYgIRUi59CElKTNJtnyQTaFMKhqmbH6MZ8EWlKKbMYBuoEYEODWVFMAkBQ V5KY1CGsARukwZBzMJBCelTkRDBgMdtBT1hZTGURMwSrLRAbZPZdW2AzGKV5omfvgaRmNY3L JC1LSZFUY8RhPgmzDcDDkXpEQi7gn/FOkWpHC6iLAmc0glEhKhb5NiJfaOIyrQG1ygC32mQK IHbhDD6EjWBaY6JwQB3baysEqNs88L0RLHWgpn7Ax7mwBYnGgT8bjddyR8AQq/eWWZduNLbf iTkiSiRTKTaET/cnSdLn4VFmO9pfMNbMSscs1MuSJRSV5IW9MeQCUS215WfTpBMxi5zYAQbq PDLFMIZWcm9BZOtS+BpzSpTRCLE/SSKnLKRx37DeKGhb4ZxgG55i4qKojX7Sm6E2kj/Hd5M/ tVqN2R67n6TeeFc+2cT+4MTC+9tQUjTCe3z25wnmlIvqc55NOg8RSmcD3yc+9zSuaJlLOqUX 2ETcNeIHwjSCLJMM0fexZWYwsuGcsefEy7C53rkNzkX5fH8WKVtWB2KMmndIBNA7o1w9nc0C hL5IHdpiZXBOYgT49xWOW+rZzJ+mxdQN7VeDbx3nqMnJ5wQ1YzvsPOfpLxEGsERDfY4Ln7gC k/SLJ69hqGkn9Ur6keLoeCLO2IWiWUQxGJ3Tglr2IXbj2LoxM5JLjImPAUWX0Gu6P2X50zT6 j7oCFvlwGmDSaY2tcsxvWNsM6tNOFpcyWPPM7uzy1FM0oM/riZUgPq+Hz+Hh+UuemEPUKnJD xK4GE+xlhKesk8llnNQF1TELUFEdA8VkXDOC//mYhEEimjsTczzqeeRws1cfAl8dNKaXQoIa pUPNyHfd67Q3ZOUZs3BL82uzi2dSiLEUp6KuRB/ChaWgo4+n6FfZIra8NVFUpb1uJ3fU+oIV wePeOXTvPnwSxDBSun2gXJwmQselxTO5xEzGlo3T/AlyJPENqu6ksAg583QoyweyLZu+M01R YCXyJ4bUu4N9SAa6Wcr4w0/KmiX9PNYVztTuI4LjA/yM9SRawhoVrRAxZj+bVWZ5BLJ6hh3j GnWbmcNlT5gydX3UB5XraeC1Rm6Z54gdHpzOTch8znk/qk+KT0d8rmvBMmeoKsW5SPrIHEvD JFxwAqrvWDZ60/75+VH9CCGlKYIoGg+mw5TcRdjkL5r9ssXzf1yLR/6adcNYL2wdzsJ/Zn/Z MDMBVT3y6zwmlCNG3ikOXPRiXHaGtT8PLziD9qLsOJNh8CzYrrAxWMORGSC33r712Dik0h62 9a+XpnTnWp1m71aK341mJOZnY/V4rlLqle01GPPq0e4mSts+qHi4XQoJKRlB5F4LrxsS1r0E 6P43JNRTiyqPgmmUrFTr7Xb7nlAyX3WUReRUBxJqtv1izPbAflKRQGApEbUy24O4lcpyYG85 8sEnQD0TC4Pw8ABoKWglG023pCS9Ai5GoInx5MMPgvyADg65cxf8agu7khj4nsvUidqbduDp dOp3m+sXpIhf2cimVE/HT2T6OWQPHZzeFUlPgQmh/BediGVzIvpNTnqLzZIqZtqcXqKEffdL r9VrL28Tz+zVgq/cfZ+y4SD5dqjwQCiJMjxmQOwRGKH4+qWbPqGcIMCEt8b9wi3Wv/+gt0TQ JGLI2ICnS6YRmMvbxfZKs19Ct6TpR51DoyvaY3ud1VzvyEtOYHzUJBHNTG3QNCRl/W2GUolL hVJ2TTRqIptXG23riYi+BrwH9GI8XVdCT1hMDfnDmPPFfKdm6dXgZrzSj3EuJaYcJQq7h4On CFGtlDJD1bQmompkSQvDyMcrFOgiaWLkTKjaZIFYn9OApSnfBWLF27W0laH3P9KGbapARpsD 2k2C9QMO0HLGGttI8bvti6P68Uk6tHrhat9iDY+thGU1SJbx/MllugycJxIfPGV6544VuxXy SWNl1ifyKvUVMG8xEBmOgM8sxk1mhxtpiM36GPIKRi6e6iU9CV+nFapsKJ8126I/m7PJFgtP EFt+SScV6NQnWPOkH7FkMHieqJ6MtyASxfcEoRF6kadXD+m9tZIvuAp1TpkjM36XKYRs8hWp fr90YPqC5R9SBpXyqki10nsF7RZBST7QBEYBtQ1A+7jmii0AFf3gIrDI7nv5UaDhXqY8T0FW mhnOx3kUpAM2ll6d3F161ai/paN7beVV7bi+8SRfPpr6fk/y3TKcv7dqrMzgs0hIXJz0XGM/ zHpKwVQO9igPt1OAkY1a1fSCXuOS3y/CF+lgdrQuukTGMeQT3uPwTQ91PQuWxGSge+30a7Xz g8Kjp4vSgc/x0VHjYz15FHCsCAvE+bd0RzNP/B2VU06fONxcL5y/8g//1bVnA+lcFWoiNutl /W3jpKFPRcoNf2tPJoZtQl1X9uxRiddyVxLguVMhZGseTGGeDuUS/Td5+M/UDlfIqMWlcHzA 0XI7j6oS2dJYkUW6j9+pJy1b/o8AhnbKcpEhykqYmUEwBeaGqgNB1WPh9xHX8Mk4mBkKc1bJ NnOyAR5g8/ZMCcHdYbbf1C3gidiBgWei2C2xNYO6ws/N6oluHIev9CPwspRBIEeLdp/ReRlU AJlG1zz4UzQzncc2MuAOg8N2l2BhgRgrCkgdNPnq9Ew2Go2jDxdJAEpaQv1oevfAImxq/br8 L6XPVhQhqkE7mMDE2QSpsuEePqcTCxIpzjEOIlFBl16dwQ6tPeQMkTO9w76UeCnBEQHbHK9h QLVTvm/w6+rXf4N3miVbONEtTEc9Og5tflqqVt9VUA4P9MXvRycNfpkExDr6Nw4mR1f9Ka43 qnwLM/n0lTpXJkCrI3+y+NhVQ4zdfqqHjVeH1Cr0eD2m+M/RLMIQISndHz6BCyeyTWUf72Og r7Ag2KvrjPj3gd//Ow6zxqPoRSAdByddn5bqNRYZZkdPDE/ppT+45V/wFSTLvKj1fwEAAAD/ /wMAUEsDBBQABgAIAAAAIQC+Ne2AugIAAPYIAAAQAAAAd29yZC9oZWFkZXIxLnhtbKRWy27b MBC8F+g/EDwWsCU5TpoIkQI3VtIADWLE7q0XRqIsIRRJkLQV3/oP/cN+SUm9Ylmym8QXS1hx Z2dnZwlfXr1kBKyxkCmjHnSGNgSYhixK6dKDPxc3g3MIpEI0QoRR7MENlvDK//zpMneTSACd TaWb89CDiVLctSwZJjhDcpiloWCSxWoYssxicZyG2MqZiKyR7djFGxcsxFLqUteIrpGEFVzW RWMcU10rZiJDSg6ZWFoZEs8rPtDoHKn0KSWp2mhs+6yGYR5cCepWhAYNIZPiloSqR50hOl30 1C0zpyxcZZiqoqIlMNEcGJVJyl/b+CiabjGpKa0PNbHOSH0u5864U69p+S0zmAqU61G8Anbg esSIyqSMlDqY+b5OdRfRsQ81U03EQDQc3kKhXbNmkqGUNjAfk2ZbXL0Mx/j7VrAVb+jw9Di0 O/rcYJmdfAcz+6zYvO3W5LsAOqs7TxDHEGShe7ekTKAnohnlzhgYR0Jf3xMc5K6+X6JHD9r2 5Nw5+aZXtArN9MrZdmCPnJOLJjjFMVoR1f0y2woVyDNRPOZqQ7CGXCPiwe8YRVhAy7+0dO3y hOitZ3KVuXNcyVGoaXOBJRZrDP0BMNmqwChq7EeISXSdIPO9eltsuMZ6wkvtwJLFfxBSKpVY 4Jc9XMBschsA8OsLuA8eb4Obh8f7yaLg1yQewVNijgRSuJeq0fvi63gytYtJilJNymaCsbjq rYwpf3SsYphGvSRaHjkwMzBoMTDTL9xRz37LPHWoBV0HD9tvS47KXHyP/fLCVvpK1cAoVlhb fTS2jzTm9cM9cE7B399/dh2q710WB8IYURUOlBwTMldIKFNTL1zdYKvrQlD/x7ylnZauFy0o R3QQq3+hdtk2ZHYspvzxyekOl+Zsl/ieYkaeoIVSukH/6n8t/j8AAAD//wMAUEsDBBQABgAI AAAAIQCHOb/HwgEAAJQFAAARAAAAd29yZC9lbmRub3Rlcy54bWyklG1PwyAQx9+b+B0a3m9Q Mx/SrDPGReNbHz4AUroSyx0BurpvL+3abtplUfeGUuB+9z+Ou/ntpy6jtbROIaQknjISSRCY KVil5O31YXJDIuc5ZLxEkCnZSEduF+dn8zqRkAF66aKAAJfURqSk8N4klDpRSM3dVCth0WHu pwI1xTxXQtIabUYvWMzambEopHPB3z2HNXekw+kxDY2E4CtHq7l3U7Qrqrn9qMwk0A336l2V ym8Cm131GExJZSHpBE0GQY1JshXUfXoLO4rigN+t5RJFpSX41iO1sgwaEFyhzC6M/9JCiEUv aX0siLUu+3O1iWcjf0PIv8nB0vI6pGIHHOEOXEa2NdLl9h6a/O6y+pMYs2PBdBlpEIOG30j4 7rNXormCAfO/q9m/3FARp7zvR4uVGeQYdRrtCT4GVlOYf1DGrtrK2w/N/QkwKt2XghtJIi2S pxWg5e9lUFTHs6h5kWSxaxZRnfiNCZtOGm65R0vCkspSMonbcyb8hmaUPaeEsftZfHl33Zxo l5Yy51Xp93Yasm2GAUcXc9quhdG0865NHRIhELyCqq3al5+C2Cl6DpKPaAtq+3a6+AIAAP// AwBQSwMEFAAGAAgAAAAhAGFqFW7CAQAAmgUAABIAAAB3b3JkL2Zvb3Rub3Rlcy54bWyklMlu gzAQQO+V+g/I98SmShehkKpq1KrXLh/gGhOs4BnLNqH5+xoSSFqiqE0uLMZ+88bDeHr/pcto Ja1TCCmJx4xEEgRmChYp+Xh/Gt2RyHkOGS8RZErW0pH72eXFtE5yRA/opYsCA1xSG5GSwnuT UOpEITV3Y62ERYe5HwvUFPNcCUlrtBm9YjFrn4xFIZ0LAR85rLgjW5we0tBICLFytJp7N0a7 oJrbZWVGgW64V5+qVH4d2Oymw2BKKgvJVmjUCzVLko3Q9tatsIMsDsTdrJyjqLQE30akVpbB AcEVyuzSOJUWUiw6pdWxJFa67ObVJp4M4vUp/6UGc8vrUIodcIA7sBnZZpEuN/vQ1HdX1d/E mB1LZluRBtE7/EXhZ8zORHMFPea0rdnf3NAS5/zfzxYr0+sYdR7tBZY9q+nMf5ixm7bz9lNz /wIMWvet4EaSSIvkZQFo+WcZjOp4EjV/JJntnRZRnfi1CV+dNNxyj5aEIZWlZBS3E014DcdR 9poSxh4n8fXDbTOjHZrLnFel3/vSoG1z6XF0NqXtWLia9rk7qA5qCASvoGob9+23EjvH6CD5 mF0Q7lTd7BsAAP//AwBQSwMEFAAGAAgAAAAhAFy1fCj8AQAAJgYAABAAAAB3b3JkL2Zvb3Rl cjEueG1spJTfb5swEMffJ+1/QH4HTJt2KyqpqtBukTY1WtK3vLhgAqp/yTaw/Pez+ZVkpFXS vmDk833ue3c+3979pcSpsFQFZxEIPAgczBKeFmwTgefVo/sdOEojliLCGY7AFitwN/365bYO My0d481UWIskArnWIvR9leSYIuXRIpFc8Ux7Cac+z7IiwX7NZepfwAA2f0LyBCtlQs0Qq5AC HY6OaVxgZmJlXFKklcflxqdIvpbCNXSBdPFSkEJvDRte9xgegVKysBPkDoKsS9gK6pbeQ46y OBK39Yx5UlLMdBPRl5gYDZypvBC7ND5KMynmvaTqvSQqSvpztQgmo3hDyqf0IJaoNq3YAUe4 I8VIWydK2jrY/u66+j8xgO8l03XEIgYNp0g4jNkroahgA+ZjpdkvrhmGz9zvH5KXYpAjis/R 5ux1YNmZPEMZvG4mbz81dRZgNLrLHAkMHJqE8w3jEr0Qo6gOJo69kWBq3gnh1KF5X9I/EYDw AV4Elzeg31qYkRttxjhDJdFjy2JvqyEvZLMs9ZZgg6wQicAj5xpL4FuLbA8QxDa9OZPu7Ke1 +p3ZrKI9Jo+qOpVTh3o6t1Tdshu/nmiF33yb3MewKckpuixo9eyu1rOn3+03uFr/Wq4nl1dv RTmo5jm6H7z4aXZAtVVp8jCv/PQfAAAA//8DAFBLAwQUAAYACAAAACEA8WzePcsDAAD0CwAA EAAAAHdvcmQvZm9vdGVyMi54bWzMVtty2zYQfe9M/wHD51oXx01jTqRMY7epZ9oZT5w0zyAI iohJLAYARctfnwPwYslyFEd5iR5EXHbPXs5igddv7uqKraV1ivQimU9mCZNaUK70apF8/PD3 yauEOc91zivScpFspEveLH/95XWbFt4yaGuXtkYsktJ7k06nTpSy5m5SK2HJUeEnguopFYUS ctqSzaens/ksjowlIZ2DqQuu19wlPVy9j0ZGatgqyNbcuwnZ1bTm9rYxJ0A33KtMVcpvgD17 OcDQImmsTnuHTkaHgkraOdR/Bg27F8UTdjvNSxJNLbWPFqdWVvCBtCuVeQjjWDSEWA4urQ8F sa6rQa4187M9e2PIz+Hg0vIWVDwA7sE9kYy8U6qrLg+B3wdWHyPOZ4eC6RkJEKMPz3Fh1+bg Sc2VHmGOS812cnEYfqS+31lqzOiOUT+GdqVvR6xwJr/Ds9nLePK2Q3PfBbB3dG9KbmTCapFe rTRZnlXwqJ2fsVCRyRJ9wmdV/7m2/eATa9N2kZyfn75IMPQbA6X8jifTIPBZYG3Nq0UicMKk 7VYB8y/fUONHhULdyfxhk+h20JvhF4ALZZ1/TzAVpxXfnsXNC6qaGp1v3N9Z0PTPW/S+flvT /8MMfk5jZGNI76zKg/MrfIEB40OAo+wggr7Zpui4+XsAz/6anc5fnAdv49I1mtC4GNNlOxuC a39j0OW+mqPgUS/sRVQVvXvicMK9eItTh0sgKpGBLzH9oTVXILdN3f0iOYsDwwW4iukSVBG8 5Y2njoVKFoGdo3Qz8p7qY7WtWpVHmg5Z24lf/MdjnfbRgMbf/wihP6rSweTT+xE1AsVRx0NI 7LN4H+QuZcGbym9VRL9zvbUUSDOdAQd2wBmEMom7MhIVy6UvC3ePrUjP/FWgDL7FHXx7BDuY 3qvDHiKLeNmFi9+vASJbyz+9x/HFrZjGs9JZC85+08YB1PBESEOYiM1Y6aRdy2TJbqiWjCzj VcWoYL6UDLeotIpXjHvP8SjJmSdsKMcqxZUjHd41XoZLHLIblknmmuyzFD4IXn34yASZTWR5 wq4g3YiScSa4kx1Mq2AMWkrnSgApxyhaDgtrlTewnffPhAnbyUHId6RtyPYWncPSDgHD4k9Y EAfIWt70ORsSiXxIxzR5Bu7WIfOBqQYZfUwaqpcp75BSFFGO3JrGGnLyN5bhBlAjgIsIVuLV kTciVFuAimVgmeHWhynEQQ0HRlYFqoJUq3wZLpPgADpYSVbddztQAPuTJwiLR7nr/OgQYdZd bT/9ue7qDf94sy+/AAAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA 0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX 7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLX cduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0 NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmv Z4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t 3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq 4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf 46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/ RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJn Js6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGa SwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJ wmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+ VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeR HOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkv I7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHa l1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4 kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCH Qb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNh Ux8YbD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZ fDivGgwW1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA 2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp 2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQW AizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETs Y3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6V shvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4Vp CCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QO CRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9E rNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/ sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+WV9wp1vw PWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74OgtuN+f MCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEAbybbhi48AAAYFQEA FQAAAHdvcmQvbWVkaWEvaW1hZ2U1LmVtZtSdD3wcZZ3/J2lTNtmkXZqmSaBq0FYDRC+FVAOE MrBXiBhxxRYWr/4ISnHRKFEaXTXq+qOVqBXDn8IqVQMnmINyrkC4KDldlUrQykV/VnNade+w GrRqFHvmvL7k9/7M7ITpsNkZ0iT0ntfr0+/M8+fzfOY7z/eZZ2Zn0hLDMLrAcrAInFXKvjLz KRwzDPM0w2jY8NrzDaPEqKspMR46zjAWOxUcW0G9JYZxPSQtcLjTo49WGft3hQwIjCbQAKA7 tcQsMVaxHQGlkexP1W1nHqqbBQ8C1W02S616dr+pc15kLjYqKVN6oVk2vf0C0zBWkBcCkvF2 SEOmUWqy3QLUD8Z4XP+QPvXNnnNUzw3lO/XYfDpklixazUZdPt86PNMwhowa8LYSo6RtTQ3H EqHc1mcYJ7EtDW8G0qljE4dgGKmzLePZFu/loBWovqySY5W7zM561r9ryHH6cbbL6OhS8tXn A6Aa/AvQ+VVfsXCsJBYeWOnU57SmnG2KUy6957KfT6npbXE0AqdfnbNtIAl0zubL7+mSGiNd UtjvLs0L7uNb8at8/Bms4+NUfawkVT+3Pu6nD/nZ8XEH2yZwxuzj9K8049i2i01O8TlOG7Jm HOd3Gtcb95Zcz/B79jg/an8vt+PGlnTkv85Y1OG8DNQBjTl3cuooX77XWNT2WSAETgQR0MD8 lCDjlfn95vx+nP0W4KSn82kJGesqEqHWii7QDXpC6yqSoWbgcIgzCWcxjlXUr6NtHRx1cK2C swFocNJ0Wl/Mo68zgL4t8CTgTMCdoI8t9NXp0idOP30d1G+nbTsc7XB1wBkroC/l0dcfQN9O eNJwpuFO08dO+up36ROnn75e6idpm4QjCVcvnKkC+jIefdkA+vbAMwrnKNyj9LGHvrIufeL0 07eb+oO0HYRjEK7dcGYK6Mt59E0G0HcInik4p+Ceoo9D9DXp0idOP337qT9O23E4xuHaD2eu gL5I+Mj4aMjvFxvba8KJUGO4C3SDntCacDLUAJz4EKefvkrqh2gbgiMEVyWcEeCND9OjLxZA 3yZ44nDG4Y7Txyb6irn0idNPXxv1W2nbCkcrXG1wmgX0dXv0pQLo2w5PH5x9cPfRx3b6Srn0 idNPXxf1E7RNwJGAqwvO7gL6Bjz6MgH0DcEzDOcw3MP0MURfGZc+cfrp20X9NG3TcKTh2gXn QAF9Yx59uQD6DsAzAecE3BP0cYC+ci594vTTt5f6o7QdhWMUrr1wjhXQpwtLggl7emzn94vF R01lIlRX2QW6QU+opjIZigCHQ5x++g6jbwp9U+ibQt9htBnweuOj2aPPDKBvAzzt6GtHXzv6 NqDNdOkTp5++Juo30rYRjka4muBsLqCv06OvO4C+HniScCbhTtJHD311u/SJ00/fZurHaRuH Iw7XZjg7C+jr9+gbCKDvLngG4RyEe5A+7qKvAZc+cfrp20H9Ptr2wdEH1w44+wvoy3r0jQXQ tw+ecTjH4R6nj330NebSJ04/fSPUH6btMBzDcI3AmS2gb9Kjz6iy46VYfJRVJUKhqi7QDXpC ZVWoAU58iNNP30H0TaBvAn0T6DuItskC+hryehzu5gD61qGvFX2t6GtF3zq0Nbv0idNP3yrq 19G2Do46uFbB2QDO9q7/PPo6A+jbAk8CzgTcCfrYQl+dLn2xAPo6qN9O23Y42uHqgDNWQF/K o68/gL6d8KThTMOdpo+d9NXv0idOP//1Uj9J2yQcSbh64UwV0Jfx6MsG0LcHnlE4R+EepY89 9JV16ROnn77d1B+k7SAcg3DthjNTQF/Oo28ygL5D8EzBOQX3FH0coq9Jlz5x+unbT/1x2o7D MQ7XfjhzBfRFlh55fWvI7xeL3zVLWf8tZf23lLl/Keu/paz/gBNj4vTTV0n9EG1DcITgqoQz As72xIfp0RcLoG8TPHE443DH6WMTfcVc+sTpp6+N+q20bYWjFa42OM0C+ro9+lIB9G2Hpw/O Prj76GM7faVc+sTpp6+L+gnaJuBIwNUFZ3cBfQMefZkA+obgGYZzGO5h+hiir4xLnzj99O2i fpq2aTjScO2Cc6CAvjGPvlwAfQfgmYBzAu4J+jhAXzmXPnH66dtL/VHajsIxCtdeOMcK6NOD t4R7/ZffLxYfNctY/y1j/beMuX8Z679lrP+AEx/i9NN3GH1T6JtC3xT6DqPNgNcbH80efWYA fRvgaUdfO/ra0bcBbaZLnzj99DVRv5G2jXA0wtUEZ3MBfZ0efd0B9PXAk4QzCXeSPnroq9ul T5x++jZTP07bOBxxuDbD2VlAX79H30AAfXfBMwjnINyD9HEXfQ249InTT98O6vfRtg+OPrh2 wNlfQF/Wo28sgL598IzDOQ73OH3so68xlz5x+ukbof4wbYfhGIZrBM5sAX2THn166JYgXorF R1mE9V+kCzD3R1j/RVADnPgQp5++g+ibQN8E+ibQdxBtkwX0NeT1ONzNAfStQ18r+lrR14q+ dWhrdukTp5++VdSvo20dHHVwrYKzAXjjN+bR1xlA3xZ4EnAm4E7Qxxb66nTpE6efvg7qt9O2 HY52uDrgjBXQl/Lo6w+gbyc8aTjTcKfpYyd99bv0idNPXy/1k7RNwpGEqxfOVAF9GY++bAB9 e+AZhXMU7lH62ENfWZc+cfrp2039QdoOwjEI1244MwX05Tz6JgPoOwTPFJxTcE/RxyH6mnTp E6efvv3UH6ftOBzjcO2HM1dAX+T4I69vDfn9YvG75njWf8ez/jueuf941n/Hs/4DToyJ009f JfVDtA3BEYKrEs4I8MaH6dEXC6BvEzxxOONwx+ljE33FXPrE6aevjfqttG2FoxWuNjjNAvq6 PfpSAfRth6cPzj64++hjO32lXPrE6aevi/oJ2ibgSMDVBWd3AX0DHn2ZAPqG4BmGcxjuYfoY oq+MS584/fTton6atmk40nDtgnOggL4xj75cAH0H4JmAcwLuCfo4QF85lz5x+unbS/1R2o7C MQrXXjjHCujTD+QJrmfTYzu/Xyw+apaz/lvO+m85c/9y1n/Lk6EIcDjE6afvMPqm0DeFvin0 HUabAa83Ppo9+swA+jbA046+dvS1o28D2kyXPnH66WuifiNtG+FohKsJzuYC+jo9+roD6OuB JwlnEu4kffTQV7dLnzj99G2mfpy2cTjicG2Gs7OAvn6PvoEA+u6CZxDOQbgH6eMu+hpw6ROn n74d1O+jbR8cfXDtgLO/gL6sR99YAH374BmHcxzucfrYR19jLn3i9NM3Qv1h2g7DMQzXCJzZ AvomPfr0Y2yCeCkWH2XVrP+qWf9VM/dXs/6rRg1w4kOcfvoOom8CfRPom0DfQbRNFtDXkNfj cDcH0LcOfa3oa0VfK/rWoa3ZpU+cfvpWUb+OtnVw1MG1Cs4G4I3fmEdfZwB9W+BJwJmAO0Ef W+ir06VPnH76OqjfTtt2ONrh6oAzVkBfyqOvP4C+nfCk4UzDnaaPnfTV79InTj99vdRP0jYJ RxKuXjhTBfRlPPqyAfTtgWcUzlG4R+ljD31lXfrE6advN/UHaTsIxyBcu+HMFNCX8+ibDKDv EDxTcE7BPUUfh+hr0qVPnH769lN/nLbjcIzDtR/OXAF9kRVHXt8a8vvF4nfNCtZ/K1j/rWDu X8H6bwXrP+DEmDj99FVSP0TbEBwhuCrhjABvfJgefbEA+jbBE4czDnecPjbRV8ylT5x++tqo 30rbVjha4WqD0yygr9ujLxVA33Z4+uDsg7uPPrbTV8qlT5x++rqon6BtAo4EXF1wdhfQN+DR lwmgbwieYTiH4R6mjyH6yrj0idNP3y7qp2mbhiMN1y44BwroG/PoywXQdwCeCTgn4J6gjwP0 lXPpE6efvr3UH6XtKByjcO2Fc6yAPl71O3L9l98vFh81Naz/alj/1TD317D+q2H9B5z4EKef vsPom0LfFPqm0HcYbQa83vho9ugzA+jbAE87+trR146+DWgzXfrE6aevifqNtG2EoxGuJjib C+jr9OjrDqCvB54knEm4k/TRQ1/dLn3i9NO3mfpx2sbhiMO1Gc7OAvr6PfoGAui7C55BOAfh HqSPu+hrwKVPnH76dlC/j7Z9cPTBtQPO/gL6sh59YwH07YNnHM5xuMfpYx99jbn0idNP3wj1 h2k7DMcwXCNwZgvom/ToM1YGWP+tZP23kvXfSub+laz/VqIGOPEhTj99B9E3gb4J9E2g7yDa Jgvoa8jrcbibA+hbh75W9LWirxV969DW7NInTj99q6hfR9s6OOrgWgVnA/DGb8yjrzOAvi3w JOBMwJ2gjy301enSJ04/fR3Ub6dtOxztcHXAGSugL+XR1x9A30540nCm4U7Tx0766nfpE6ef vl7qJ2mbhCMJVy+cqQL6Mh592QD69sAzCuco3KP0sYe+si594vTTt5v6g7QdhGMQrt1wZgro y3n0TQbQdwieKTin4J6ij0P0NenSJ04/ffupP07bcTjG4doPZ66Avkjtkde3hvx+sevbmlrW f7Ws/2qZ+2tZ/9Wy/gOvNOx3bsXpp6+S+iHahuAIwVUJZwR448P06IsF0LcJnjiccbjj9LGJ vmIufeL009dG/VbatsLRClcbnGYBfd0efakA+rbD0wdnH9x99LGdvlIufeL009dF/QRtE3Ak 4OqCs7uAvgGPvkwAfUPwDMM5DPcwfQzRV8alT5x++nZRP03bNBxpuHbBOVBA35hHXy6AvgPw TMA5AfcEfRygr5xLnzj99O2l/ihtR+EYhWsvnGMF9Onl80TI9fwvv18sPmrqWP/Vsf6rY+6v Y/1Xx/oPOPEhTj99h9E3hb4p9E2h7zDaDHi98dGc1+NwmwH0bYCnHX3t6GtH3wa0mS594vTT 10T9Rto2wtEIVxOczQX0dXr0dQfQ1wNPEs4k3En66KGvbpc+cfrp20z9OG3jcMTh2gxnZwF9 /R59AwH03QXPIJyDcA/Sx130NeDSJ04/fTuo30fbPjj64NoBZ38BfVmPvrEA+vbBMw7nONzj 9LGPvsZc+sTpp2+E+sO0HYZjGK4ROLMF9E169Bn1AdZ/9az/6ln/1TP317P+q0cNcMawOP30 HUTfBPom0DeBvoNomyygryGvx+FuDqBvHfpa0deKvlb0rUNbs0ufOP30raJ+HW3r4KiDaxWc DcAbvzGPvs4A+rbAk4AzAXeCPrbQV6dLnzj99HVQv5227XC0w9UBZ6yAvpRHX38AfTvhScOZ hjtNHzvpq9+lT5x++nqpn6RtEo4kXL1wpgroy3j0ZQPo2wPPKJyjcI/Sxx76yrr0idNP327q D9J2EI5BuHbDmSmgL+fRNxlA3yF4puCcgnuKPg7R16RLnzj99O2n/jhtx+EYh2s/nLkC+iIn HHl9a8jvx1nLtQAnub+PWnMC678TWP+dwNx/Auu/E1j/ASfGxOmnr5L6IdqG4AjBVQlnBHjj w/ToiwXQtwmeOJxxuOP0sYm+Yi594vTT10b9Vtq2wtEKVxucZgF93R59qQD6tsPTB2cf3H30 sZ2+Ui594vTT10X9BG0TcCTg6oKzu4C+AY++TAB9Q/AMwzkM9zB9DNFXxqVPnH76dlE/Tds0 HGm4dsE54NLXxsAKgXMA070xALaD+0oM42NYHnEbvAZufQ+7Jr+Nmf5O9bhj+DvVIb6OvbHk 8vn5bvIovwV+KU68GR9fgS0FsXCqNFI/Web4WH51tuXv1fwjsHmuZTzb4mgEzrk6n+0U2Ars 71RLFnWyvRHom1OdczvtjRrGN88zjEex3z7v/NMfjb6/7tvnvat5NPrC93/jvLtuHo3+Lvrw eaFzRqOJjUPUG6XeQ9h8u5KSRYsWlXxkhVmSikC42CZ9ejVWQIWmknx6Zlt6nePTtnucncW+ 9J0IIiDFPBtZYhiXsW1zskFy5kK1z9U1L/l13dolcbblByc5dRaRcVx95ZLq+p+WhervLSvG ZdRnylL1kSXOHOjEyHo46sANnLc3YtPYK7Fu7c4xkR3onOk8bQNJ4HxPbLLdApxvgx9nW2nG 74nz39RTZcZviNMljcbD+rqd8+X9Vl4+FYqdK1rOy3fxX4FXsaBvtq/A6lym6lOlmfDzEQvr GNuKhTbsQ+dVb2mzxvz4w2dZMWD+3zYrJm7rXW/FiGGsp963qZ9vtwCxEOObOr9YyIYzZY+G 7y0rFgsj4Z+WPRauXDIRXrukWCzkws1LYuGZY2GI86VY+Dq4EhxtLDQzDlYDxcIppj0uFXP8 NQr87KTseW/5yRujVRc1nBsyS5c0k63xa8XLGUsVptOpjK1zjYuNV/NvB9uvNEtTe7FZQHqa rqxr2zLsG5gtr+AvRnQZW4wG9s7n32utvK3kGEsH1hs9y9anev/NtuufsO2WsnOUnz213rLG 8pMsa4632PYr6y2b6r7Eto1dti1/j2U7J66zbG68z7LGyE12+e7b7H3+SoCk2sm9vZwsZ76X j7SttBJoW3kXg24OUsf5FJMhZjr1K5N0nLEY77zbuJqj77KzZvFvZLFR8ke523ikzPhGyxKu FOw/YkQWdz4dWdxwikqooymd/IFfLDdWb7n6va0l5GFfMPrZraqhOiHxbFtsbETfCnIepO7+ 0yfLVmPFV/fiyGI+LbDqxmhf9/K/32gY5WYT5X1/OPm9DZT8me0cUIc6zEVgB/sR7IdLDWOM beETkye/N0SeUprtD/PMKsK2mT8W9RV7yWTZF258+dZTLjzpLTueiiyW0P3WkVrXKcuLV77H umRNX9OUiShjEPw3qAAXk1mPtRrUVTGeq85TGV0aGn8dwJ2ca5fOic/YNMqpo2Nl3WBBx6tt 5alMx+iUuy3Z05qrDCN1PvuPgGGgGDzVfGZcncL2avLrgDceb/vzBdGXvWr82fF4wxOu679h FIrHjbC1W5zPxKP02xFojC5ZbxwE915s2VTNDnv/qOKiEX7FiM6FO0YOzWuMfHbrYfhv0Zi3 Y4HetV55hXWOfviiSWtUZX++3Dg517b1ZP5aj87dkWmV0W2ePJ31EuL29eyN7DhQFvrxb8pa P3WgrO7sk63jSlCvkjGebLr6vXabikvUUPkbyf/2e27tMay/AMR4ZvtJ8+C3XnphxSWqa964 v8cdIw3UZxRfsvfJ5caaFemeNz2ZeOhvHIva3bvu33vUZvie3y9WjMir2la89fzu33vEJcwU I50w7wMvAE8ATRXuGFGZzpfGxEwxojGUHy/TMUDWs8Z2irytYDZjW9cOk7YtgDR97ZDWtUbq idvnYFyugcsZlzom4QCQb34NvL5RmXwjDTP5JkbZWqDk8DuxniJvPvzRxJ+ienie/PFbNMsf B4HXHyoL4g/0WWmh/IH/N313nvzxe45E/pgEXn+oLIg/Zhoft9C+DzyXeLnlhXdb1wLFi8Zv OyBNx8t8z+3OOVVMqP9OcBk78tFbsV4fqUw+er7mF7e/THS0ANK0v3Qc8zm/XJ33jf5Wm9c3 Kjua8ZNC+1Yw2/Fj0raQP+Zzfrkm74/uAv5QWRB/zOX8Emx8zN/88u68P7YW8IfKgvhjLedR yYlN5/rzCHnD4LmMj4Fru897zcBfztP8so22SUCajpcQO1HrLu4KVkf2nVz2n48/R6vI1Bkv taz5iSbLGm9qs2z2FR22/eIm297wJsumru+2LEvjgndhWhVVAtxgrYu1rbQSaLsOOMesOhtB L7gWfBDcDj4OVGbk7wlU1gd0HB3AnZx7gs1keo9R9UvBkjwWYzWn6T5AydFxNL4//k37os/V 90b/W862VvDLwvYV8JLVtv3sW2z77htte+UXbHvag5ZNveQn9v4c+z6Ds+X7cazX9ypbCN/v pf8seC7j/hO/XxH9QvcLzNk889B4iQHSdJxofFzKkw094zDub7GfZrz3s5Y1Fu+x92+asPeP 4hw00k8l0Bi/GHSzoe35fh4x8L4/ltGNkSk17h+hw8T77ecRer6QOl4l3IeRr3oD3Ku4n0eo VPdGuq8ZpHwFe7rXkn49jzicfx5R5F7rUjH43GtdWuRe69L5uNe6Ek13A80L3wKav3DB9Nyj sgjQ2OgA7uTMPRvJdMYNc0nR+61dlPeD5zLOwz952Brnmt9nGrcbeFZljds3t9vj9PM32+O0 ibsOPaX76s+Petw686X8o2OW7z7Ojnz3j1iv71QWoczPd4523dtrbp5pfm6Drxk8F9+98p6/ O/fkH1RGnzVHBHgOsxctWUCaniP0XOoC4xqjgTlC/16KJy7Gup6LnnHyOUZs+9nGZedYNnvK 62x7/KW2nfo/lk195522/TLPPanfsIfnnbI9N9r5X73dssY/f97e/87d9v7X7rFs7u77Ldv5 mYfs/BlmJPu8VKIb1814TZ5pTprf5z+RxYMftOek00uNtaPMTrEPPTMnpRVMzEkp/lW9YnNS RjyRRdac9Abqa05ynpEWmZPiVPWbk+JF5qT4fMxJg2i6EPSBNNgJdO6c9ZDKbgZ+z0h9xqm1 nloCj+JXcLYr2FYMhvL5umi4y9l91topRd5WMJvYLPYcqckwr/vaHIxv79yl+eszQD7WmtPr Y5XJx/J7B3AnZ96PkdmUL3D4j2Yt6cxVxdbx17I+eSczrzPzZG/50DlG82vW5676qGWzr7vB sgOtt1o2ddLnLGvU3GnZzo98ybZrh+38GWYNzeV+c4ZzzPKR/NkL3gbkS/nvTuAetyobABpX M/l0M2XeYywjT2PTgcZiBZjpOtFP2TbgHYsh0yg1yW8Bc/lb8pDxYd6reIiDLSk5mt+SdVyt QMmx8qDivFBy/K92zja+OuJvrGtdfzMnYRhbCmLhyeMi9Z1hpz4+TDnbFKdW84/A5rmW8WyL oxFobKjf80EKbAXyt/42fSfbG8Gz36tojdrvVZwZ1XsVdX89I6r3Kn57z6uieq/iB59qieq9 ikh6LfX0XsVpQO9V0G4BfkvWexWpsN97FQPhX9cNhOMcn/zgJGdOWETGcfUfCFfXvzocqj8h fBn7tj/tmk49+dGobwin6lPhs9kMgba81Q+2dUDvVXwZq/cqvoqtBvI7u9Pnm81A50znaRtI Avs8GaUm2y1gLmMhXfJh3quwYuGo3quQH1uBkmOPJha+Ao9iQe9VDGPl/1T95HGZ8PMRC3o/ QrGg9ypOi+q9Co15vVehGNB7FYoJvVehGLHfqzgTm2+3ALGg9yr8YiEbbgg/Gj6haCyMhF8d fiz8gfBEeKBoLOQoj4VnjoUhzpdi4etgLmKhD55eoFg4xSz+O+5HnnziPF2TNae1A9L0/cAi dubzd1lnblbMq/9OsA9sBU+AjwCVOWtDlX0YSFcHcCdn7hHPfP426PjLpJ8WW8C0v6R17Tz/ Nijf/Bp4fXOAPPlGGmbyTYyytUDJ8b2zpkuRJ27vuiLo+DFpW8gfTfP826A0HwRef/yWvCD+ QJ+VFsof+H9efxuUPyaB1x/6bTCIP2YaH7fQXvPKcxkf+i3DiZeNtD0W5hf9/icf6bdBr49U 9nzOL25/mWhsAaQFm1/0+598o98Gvb5R2dGMnxS84p7t+DFpW8gf8zm/XJP3R3cBf6gsiD/m cn4JNj7mb37R7386h1sL+ENlQfyxlvZK3vn2EfKGwXMZH/p95Lcfa4oWe6bgfk4U0x3dKS+w n7hceLplsydGbVv6Gts+ebFlUw+/2bZ3vs2y5u0ftCwrx3Ok307PbC8noxLghhmfQzrHrDob QS/Q/dEg2AKGgMqc9Y7KHgAh0AHcyVnvbCbTe4yqvwRonSQ42zM9U0hRR+d1tr43adsCSEfM VWcaAx+8vqjXgj2/9fpNvksA+U3W6zflyW/y5Ux+i1F2JlBy+I9mLeQeiyachfxxqdHwrk/M kz/eRp/yh86j1x9vJy+IPy6lntJC+eNMI/Wz9Dz5o4fjkD9kvf5QXhB/zDQ+RmifAbONl17a dgPSdLwoNj2/tXx/l+WbzpVftGyu/F57/6X32/v19m8j2VL7GbL5X9+w8meaoWYXa0l0CfJl Gnh9qTL5UvpnirXNlHmOzZrTFpFfBmSdOYrNBRt/TUbDLx6bB59pfvoMkM9uB16fqSzI+Gui ntIaUAmc+UkT25/Zn+34y9L2QUCaHn9L2dHvfNcwMp3n7w3sX228g2vTu/kBuWG9nsUbX7zM ttH32XbDLsumJvgtlvLUQ9+18x807GfwK5ZbNvu5l9p2+yts2/VKy6a+xjs5tDO7N1rWOO9K 287hdXaAY9P1WefhH8A3gfs6q7IskA9mGsMJyor5xz2OnbFcQRvFRQhojAulQL8Fq46S99z2 kdcLZntu22nbBkjT51Z9MtYN4+F32L69s2fOfRynj81APr4ceH2ssiyQlg7gTs5aJkamdMpP Sl7fPELeMJitb7bRNglI074JsfPMbzIXWfOU8THWehrr/7HdsrnHPmnZ7P07LTtw+2ct2/Cp Oyyb+iEzM/VzmpHVbg7Hbi/63gzk1x3A61eVZYGOYya/bqbMe4xl5GkMOpDPxSEoeX2fIm8r mK3vTdq2ANK07xWDzUZn1VeLem12162NcN8A5LebgNdvKssCaZjJbzHKmoHSQvmD34R1HS8y imbvj1s4DvljJ/D6Q2VZ4OePJuooLZQ/1hrZJ/fMkz9u4zjkj08Drz9UlgV+/lhLHSWvP/rJ 2wa88RIyjVKT/BYwl79NDTHa9xm3IvjY+512B8f6Y5DWMYNYOMf/e9ZZ7viMa2TK2aY40G9+ jVSsBJq3zlcjsBXI3zP/TvsPUW6uwevBCdF01+ujb9pXH/3DVW+INn+0NnrpyzdGa9++Irpq 2xuim649njobgWy+3QL8NpXRIo8FwmUcy2rgJOcaKf9FqgbKa6s+Vx5nW35wklNnERmvqnpf ebTqgvIzqurKi3GZVZHyTFWqXM8aQqAtb7mIWc8xvo+9EfwUaN1aDeR3xcVzPWc6T9tAEtjn ySg12W4BcxsLNxELqOV8HWvvLPRzrIqFXTpmEAs3lMc4n44vFzYWVjG2FQsvtGLh4K4XWLHw 9deeaMXC3afVWbHwyzNrqKNYkFUs0G6BYiHrGws5YuEnPrEwRCxsIxY2+sRCjFjIFo2FnZwz xcLnQDU49mPhVmIBtcdgLNyC/xQLA8COhU5iIfc8xcKLGNeKhZOsWPjAlSdZsXBRzYusWFj3 1xOtWLi2tJ46igVZxQLtFigWJn1jIVJRW1VbUfy68CdiIUss3OgTC/3EwmTRWPg0502xcCeo BkcTC/2017VB14VTzJnfWbj9v+LRkprl1jP/zdSPAdL0PcVidpz3lqe/Rbkg/w3Ko1fb35j8 N9896CvzObxPu5J+fwY0pv8C7gC6RjrP8n/O5ueB9HUAd3Ku2xvJdLS7nx2ornN9cJ4Bpcjb Crzry6C+M2nbAkjTvpPeZl5iu6+od2Z///FX+G8BfwNe/6hM/pGGmfwTo6wZKC2UP5qM1Nu+ N0/+eJrjkD900F5/qCyIP5rUnrRQ/uD9ltafzZM/SvGD/LG4gD9UFsQfay1vPNsf/eRvA954 CZlGqUl+C5jLNWi65AYjWXLs3Y+9Bz/u4Fj1rmBaxwxS9Tn+FvLzcT/2Fa6f3I+l/hV7QnTD w/9q3Y+d8LUR637sV28cse7HrvvSiH0/lhqhnu7H8u0W4LrbUOt/P5apHSgfri1+P5aufV/5 jtoLym+tLX4/1l8bKW+onfl+7N2ctxs5Z73Yz2CrQSVgd3oOYDPQPfRC3Y+lS24iFlB7jK1B FQv9OEuxsAtrx0JDeYrz6cynC3c/pjHNfZUVCy+0YkH3Y4oF3Y8pFnQ/pliw7sesWND9WL7d AsWC3/1YpjZHLBS/H0vXDhEL24iF4vdj/bUxYmHm+zHFwk7Om2KBO5z/JbFwK7GA2mMwFnTt VSwMYO1Y6CQWno/7MY1p7qusWDjJigXdjykWdD+mWND9mGLBuh+zYqE+HwsLcz+m64Lf/Vim NlIxXFv8fixd+ydiIUssFL8f66/tJxZmvh9TLOh+TLGwkPdj7/nU54Lfjy3+tv23AbZcZK0g U3/6mL2SDD1QdEW5nONyrnF1+W1M0b+7cCXlG/CFxvTl2DuwmOn7sfPZ0XpyMehQvist1P2Y 23cm/bfYGrz3Yz/6ZlHvzP5+7M34QP65CnsHFjPtH5UFWW83qw3JuV4ezf1pEH9wP/a+/5wn fyQ4ZvlD77regcVM+0NlQfzRpDakhfIH92MX/Gme/KH3gOWPd2DvwGKm/aGyIP5YqzYkrz8q RQa892PFnl/o75H8cWip9exnL82zgDQdL8vYcb8L6TxLcX2/rr9Oou/Xrzx+vWXvjdn2gm7L pv54vb2/84u2fcu/2PkrfmdZ8zfH2e8L9ayy7ebVtt15mm17z7Rs9rUX2rblYjt/hidNs4vd QY4zg+8+jv0b9jas3Ok8a1LZTnblj5nmti7KfHxlhKizBCzKw9muYJ91sVWusjJPObvPOt8p 8raC2Z5vk7YtgDR9vnXMzAdL3jwPPt6Y70g+1mLI62OJkI+lYSYfxyhrAkre8f8IecNgtv7Y RtskIE37Q+frmfc87NFvPQPV2wT9/G1O2WVr7fezLmHEs596/Dbb7mLEq/winu7IHpd/f2uG kTuba3Iv+jQ25csc9gtY+c89brV20XHM5NPNlHmPUeNPY9OBxqQzRtl8lu/7yZP/vL4PmUap SX4LmMtnQT81vsZ3o3s42GPrt/mvcJwjQM+tH9Uxg0xVLpwJxyqd8Uqcp5xtigM9V2ikYiXQ eThfjcBWIH/P/Nv8uigzEtDf2X619X3oT6pfbX0vet8j51vfj97yT1Hre9IffNmkThs4F+Tb LcD9r74b7ebALuNYVgMnOetF+S8X7q+cCN9UGWdbfnCSU2cRGY+F31E5Ej6r8tFwZWUxrmw4 UhkLd1eeTRvFRFversfWgSGQBV8H3wHVQH5XTD3Xc6bztA0kgX2ejFKT7RYwt7HwDWLhMcXC MfXbvGJBflQsfFfHDDJVkcoM59Px5cLGwmsY24qF11qxcPVPO6xYaNtxoRULL3nXBVYsXPG+ v6eOYkFWsUC7BYqFjG8sjBELj/vEwj8RC0liod0nFkxiIVM0Fh7hnOkcfg9Ug2M/FvYQC6g9 BmPhW/hPsfBvwI6FGLEw9jzFwusY14qF11uxMHVnzIqF777hIisW7m99jRULk2Y7dRQLsooF 2i1QLEz6xkKkaiIcrorjz0bgpCOvC78iFh4kFrb7xEKKWJgsGgujdKBY+D6oBkcTC/2017VB 14VTzOK/zadzrzpmf5v/KsfwF6C1jnvd+XP294DFoAO4k3N+NpLp3E86a8tQvqJzfahiqeNd 75xq2r5X1aC+o0nBe53mef5tXv75G/D656/kyT/y2Uz+iVHWDJQWyh/z/du8/KGD9vrjabKD +KNJ7UkL5Q+eBc3rb/Pyh36b9/qjlLwg/lhreePZ/pjNs6CPfvz+c0+9p+MongWlnuDLJJ4F pRbZf9PQ3Ndq7Zsjpm3/sd1+rtATt+3mTstmWz5g2c4LP2rvf6rfsuZ1t9j7n7/d3r/Z/tuG Db3293sD19jf7zFJnJN3BMa9vZx9Z56uy2+r5sr8tvKcsYTLDc1Jg+C1YBTcDvYBlTn31Cr7 f2AZmCl2uyhbyGdBj9DfMPDef59iznxtcZ/vbbRNAtIRzz7eMP334/Lf8ezj226eZWS/d4ll U5+/yrLmu95j7590nWWNGr5Spl7nG2+0bFZnUM9Ajjg7z5yp2ZynXsR2Ap2fHeA/gfs8dbKf AyEw03naTJn3GI8jb4kLi9gWh6DkjJejuTa5fW/C2SJil+91HM2GqfFexGuze9apMX4DkN9u Al6/qSwHpGEmv8UoawZKC+WPJsOK+3nxxy0ch/yxE3j9obIc8PNHE3WUFsofaw1r/psXf9zG ccgfnwZef6gsB/z8sZY6Sl5/9JO3DXjnqpBplJrkt4C5fD4yZPycY/kVgo+tZ4UPcJz7wY/B hI4ZxMK5Kr7jWer47DgmTGeb4nl8Vqj3rt8K9L721db72ie2XG29r/37X15lva+977G3WO9r V/+gkzp6X/sKkG+3APeE+o6ne2nxZ4WRqv6ltVW3LI3jrEbgJOeeYxEZr6q6Zmm06uylZ1Qt XXoZ+6udSlinns4F3/EszVR1Lz2bbc39bXnLRWz6O54c23pf+zegGlQCxcVzPWe6x1FMJMF8 PiscMv6DWHhSsXBMPSt8gOP+BVAs/BbYsRBZGuN8Or5c2Fh4O2NbsfAOKxbu+Z8uKxY+uPtt VixceeNbrVi489NXUkexsAUoFmi3QLGQ8Y2FMWJhzCcW7iUW3k8sXOgTCzFiIVM0Fn7JeVMs /A5Ug2M/Fg4QC6g9BmPhCfynWPgDsGMhRiyMPU+xcA3jWrHwLisWzvhWtxULlVvfacXCU/G3 W7Gw9ooEdRQLsooF2i1QLEz6xkJkWW1V1bLi14UJYuEhYuF6n1hIEQuTRWNhgvOmWPgjqAZH Ewt9tO8FQZ4Vfv3aK6z7943Ubwek6fu5Rezk7+K8/6PMmW+ah/ddOunv5+AJ8HswCXRtdO6j VaZ86eoA7uRch3Ucec1zfg+m754cf5n002ILmPaXtDYbxo9658E3Oi6NDfnmEJgEbt+oTL5R 3ky+iVHWDJScayRLpKN6XurnD54PLv3cPPnjLxyH/DEFJoHbHyoL4o8m6iktlD94Prj/vnny x185DvnjMJgEbn+oLIg/1lJPyeuPRshWgfm4BxuhvwzQPdxyrNKlP3xZtOGM06JxbM2+lugP /3hy9KY/vTL62Cebojdjv37y31n7Z12wNrqS8jbsSdTnr+sCxy638nN1y6Oq95veZVa7d15e Ff0OPO/A7oNX++pH5er3F9TnbgA4Fr5FVuKO0NngS2yzZPr/n5Hm1XkQUroFyKdntnVdvhy0 gkV5izmqvz9+Fu1D4EQQAR+qQEfYMOJs5+cntp65T9Fzqg9VXBQeqOgOPwaeAjXhi8Bq6+9n N1q17X+cOVVaI/wtblBeE36x9Z33TNw14anQUxU/Cj0GBsCHKqbAi4t+55qq4HuPioZwG/3o WExQB+4GnwAPgK8AZ0zOxbo+A98XgH3vVLKon+1tQGOQOdFKZzNmsqdWR2X/5y/LolnGnMaM M3Y0JrWvMaNyWdWX3X75SmvMVk/VWfVl1V5WfCp3+PNjyxpY1/HvCrMkFUHBYql42nha56QS aPyszqPYGHsZdeQ/1bfS07Zx/Kf8aiBOzRHOGNrEdgw4yTn/8kdN+HTOvVF+5Lk1yj9UcTq4 qnygor/8MfAUqAlfBU4vd87netpLzxfBJ8H9QM+J3BocbWSnXMd4Lvv5lJreln7d/3aCjWAu 7n+PhVh2/O8e97dzfLP1v+PTuYiXbehIzpGv9f6ZzrE1Rok3a5ya+h3lZuM+/a84zLHHwvm4 FI3SqfNxI/gS2AmkN1XRXD4G/rf5+B6e5B+LPh7EpzuA28cDFbnQXPtYa5gImIs5Q+N4BM0Z 4F67PPW971lrlz9jtXa5f//j1lrlvlPGrLXLF5Pft/a3XP8Da+1yFdZau6R+ELXWLpZdHlW+ 1i6qp7WJ2mmtshseXXfEq331o3L1a69dHodnOfj/7J0PcBTVHcc3ISGJF0Ig3CSXthopVKCx cxFsqaAupiIiaqChIuIUq1Bo/RMxwdShMzctMzJTR8P4L61KM3aqFrCNFWmKTL0qilC1WK1V SzX+QYJKDVM7I7bVfr5vd4/jyN4dl9wldPomv/x239u39/b7ft/3fm/f7lvpU44Z32VLKLXv siV0QWB3qCkwvLopEEbmVl+AJPddGqprAkjJ3Orkvsvc6o+Kw9UvFQ9HdodeKt4S+ghJ7rtE QzUlyBG+i97hk+9yP3owfBfZjHwRafkmsh3ZjGc7D2E72pfNKF1ax0vLN1G6fBUdL6380jqf 0r3zp/Jd1H5KkvkrXhuqdrUCORq/ZG71ZOrVKjm83qySLaHJyNKS3aG2kuHVbaS3cdxS5Ei/ 5C7qSH7Jfej/+yXO2MSrk0Iqbj7YNCDxNu35JZng7537WPFL7s671epAhppfovpYS73ci74d Lf5EQ+ESq/rY80vWsVbHUMT4brCVXxKPcTdrdRyLGLfnvcZ77+8MOTvWGhC7wVj23OPaMeuh jGA9lEGYv9B778xrm/fel5v33jWvrffeNa+t9941r6333s28tnnvXfPabj6f+YsJXJf6NXE0 nT7xJI4z4yN0fPDaTr++8jMcXI7o3fhUc9+dlW1lXZXJ577bK68pu6ny9LI7KpPPfbNmSllN pf/c9wrqtptyrUIfK3Pf7XlvwJd98GVozX2LL6+DpfjyHlq2EAmVl0WoT88+BqJvjXDeZsS7 R7aY7UZEY51itBNk98xhG75cZfiiuW/xRXPf4ovmvsUXM/dt+LLE5Utu5r7FhVRz352Vu+BC 8rnv9soNcOEGuJB87ps1U+CC/9y3uPA24IkL+9EViOfzevVHVNr3wVZzcCsyUGPacZzLtD1x 92ba8/bABUo7BLnwFuUVFz5AO1xogAuDMfctLjCHbbhwreGC5r7FBc19iwua+xYXzNy34YLm vt18Pn2H6kPSnzFUfL+Qau6bNVNGdlUmn/tur+yBC5vhQvK577bKCFzwn/sWF3q4MnHhALq/ XFijcyHiwiTbwU22jGd8llHutta58OYuG4mb5STG5nKHse/OI2+ZYebr0l0pJbNnbBfzexeC wVvob6J70SiIOIJyjzhLaZq/U7nmKD4uePfpdR3ZmvuOx8vmd6Y4vx/DS2UNM/edzXVShM3S PrD5louNyuCHTQNpYUTBa2O5r57x3Hc6eGR7nRThoXVSetG6ds9WtE5KOnO9tcpDyBUedVle J0V4aJ2UXnQ8HlonJR086sinkIhHG3GrEbUpX7Sdvppdq9i28m20uCCfCGU9p3+EWx5vOVN9 Ubwo3juOzU/95kFW5P2O770/qb52SH3vvQkct1Jwfe99u64FqansDpSHBmOtgmfqnbUKtqPP Nd97n191rvne+4QdM8333kf+st587/38zVqr4GlkBuLmy0Ffq++9N5Umf/64u6qtdG9V8rUK ikJXlVaEppUWh5KvVWCFyksjIf+1CvS99yh11o7eia5AKJ7himfz7A4pv3NF3u/hwg5xYUjN CYoLjwGWuPAHtMOF8tLy0GCsVSCbPg8RF843XHj79TmGC79pm224sK7lHMOF3d//GseIC9Ju vhxxoTMlF3bBheRrFRSF1sOFVriQfK0CK2TDBf+1CsSFbdSbuPAsugIZ+lx4Ei5Q2iHIhSfA T1z4I9rhQgNcGIy1CmTTrDlguDDXcOG6+xsMF2YuuMBw4eTTzzNc+O7ZszhOXJB28+WIC70p uVA+Ym9V8rUKikLvwIVNcCH5WgVWKAIX/NcqEBeept7EhefRFUh/uNBGfs9fSjUGS3utgkFY t3IL16GxmHwdVMy/nskO3plVgMxRfFyIH4tlc60CjT887Gx+Xz4oIafjMeGj8VgiPhqPCR9h 5odPA2lhRMHzPfo7HkuFR7bHY8JD47FEPDQeSwePWoNG7vDI9nhMeGg8loiHxmPp4FHng4f6 7S4kcTyWrK3RupVH/Z3yTFeqbGT9Pq1wOcDvrneC2wNc98voR9CoWJuktIfZLUb8OLeItPg1 BvQtdh0/HBnmirddxL7CQHAzHnubc/bVVp1m2cdZZs0GP9Qyu6/WyO/91cVNOhE3xQk3lC9u DaSdhijkCo+LLPtAUZbw+JuLx94+8HgtTTwucuDIGR7gv3NslvDocfGQTrQPxfXHPraCUyeS aVu1irxNCCHWt4ub86wa1uBsti5DlljWQ5MMNtFpZzp67DmOvmS+o8+61OjImKsc/a9moweW a62U6z0XywCDgEQslSYsVf5kbVTCtZk2Su1TISLttVFs5sz+aq2OpT/IAmZqn0aAldr1sj4w U1o69lcrMAjjkVLE86XUsH3Ifqb2FyXvJoQQs78ydpJ9h/uI9W610rNWndBKz9IHb3T09juN jrQ+6+ipvU78/aXOKiY3j3G0VnomX/QpWgB0pJUVntH2bFZ41vkGsJ/t4NrUl8p2D6IfR6MO 62ej7AoDPxteRloyfOLt2LPl48gjXqg/lo1LqHqrBNExCol1u4a4VUimdTuLvNMRQqxu9Zu1 Vo1lP/F1B+P1lww4xgv4jY9djP/TB8ZKi3KMyuKHcQNpKqdwUkjEZhtxXUim2KwmbytCiGFT zM6hdY+dmTZ77eUOTjuvdXB6jjWKsMnuzWuMjv60zUm/lZWpiO94eZ3R1vG/cPQA2q5sQaDJ diehH0cDZcx2lRZlV9fhh+si0hKvUfYqG/REmOscEoVE7CPENSOZYm+TdwpCiGGv6whbkVEP JkUtcx/xZBe3uj5wU1qU31cZ/HBrIC2MKOQKj1pr8cebsoTHKS4ek/vAQ2lRrjMVHrUCg5Ar POqs7v1dWcLjVBePr/SBh9KiXGcqPOoEBiERj1JlRI6WL/1be8/00v8z32F4Ggg/AcM/O1DG 2rxO4l4gbiTix90rSYsfF3v37eL8a9PWqf1T2yfxthP77cKEdHaPqO8IcZm0j1592+Tvq33k /lZWv8MgjNWHJGKsRloYo3wxbiDNrz3YRloXkqn9ryZvK0KI9RfF7CT2Y0f4pam+w/DrXY5f uv2g45cOcF8t2xSWr6LfRAs/7xkOpXWzq+vws9tFpCVeo+xPtumJbFXnkCiMR0oRb3wQYTsb thi2ojsLstQW6/6FcHujD9yU1k0ayhe3BtLCiEKu8ICbd7ujGR8rytx3edPF460+8FBaN9eZ Cg8/bkbImw374N7zD51Rnd/oLXM89rh46P5WIq+Ulg4edVy3QqJ9TCd/GDmaturyVxfWv7dj Q32xnT88zDnHIeY5oK+WMXY9FArZnMGdnXP5L85/2c6PPIOOIoRY26a+bB53fVYiK2gBllvX WFdbNdzNvYztK4mJnMiaKy0jz7BWPW90pJgWjP3IeWVnSkdHMZKW7jnZaKuT+0bs23dw30jH LWLUp/Sx1zh62PeM7r70RqOtGazSSnrNlNuNtk/6sRPfL9uewHWpbQJero/7Xmxo+x9MqqFi oU2RhCKrAKRWcM2XcdWZhvKC8L0HBL11zzDzCUvL+tmBwm1WecHUGw4U9lQppbzAsmxLx3W8 Ptoat2T59VPziEMrlZVRrCZ7ojWVdLW3n6dMK9CbOHbj5N7Cceiq0yeaa1nGcaXst9Yuv155 +ErOxfyzFN9I/FMr72jR+RR2s73Pfv+JL8w+7mIda6/d3bKLYyQ/6p14fQ1a+Z/ZN9oaP6a9 5dJ9yzZ/AlbKt+HUV1qUp2v93wsmzT7xciGp7ZvI07L/lRadS3LFSqdr8Oxc0DYiDyAHkQVE zEO+jSjN65+UtoSIVH5Vcjs99I2gIs4nAWijhWN8nPov7SteouCV2evL2ohbjSRys9i28m3i pyDe83fPsa3Qn+f0HrFOyFub9428ofac3sNc1+eom1sR1V8++w2B3lHlocVBDzOwjHjbJKf1 zJfHT+E/U5mQZkR4+39TSM9VbET0bNKD5nmMDS9tNM9jjPnVBvM8xo0nrjfPY9z38wc4hucx ItJuvhw9jxEJpnpOryO4t+qu4AKuVzh4wZvvH0ZEUWhlsCJ0drA4FAyK1OO8g9DecaoLntML RkKRIBOEhnzTXa3OoArR8xhzkXZkIVJBnNcuHm2dqZ5WI62IU09Wvs32FGQgudCed0Leo5bh wpB6Tu+3XKe48BPE4wLPwozqDAwGF07FrsWF6cbGK5ZMr5fNv/zotHpxwP7B9Hpx4s5VZ9SL I873Vh5Eu/lywAV9XysVF6KB8uD2QDApF7YGzg7uCKwM9gTuSsqF7kBHsCHgz4VHqD9x4TH0 QHChi/NsRMSFSbb/+yF3fnhO/acvrDnSZ7uZb/jFhUK2E322RuJmOcfEfLZh7LvvZqz72PkC 7w0XOu+V/KltANaDm8D5vTZiHttNYMaf9c+s+k73NP+b898mX8j4SPwgYYL1JWs++sUTegWP FX1ttDWxe3rzRO4AKP7w4PhOXpx8pxZ2tt60p7D4L+8WTr1lT2ES32mh8qXwnRYm8Z0WZsN3 WkyZXkQqqIC30TVuXXi+k9KOJ042MQeJD14/0Uhktt7l8Wxb4wub35niFCBmq7KbsBXp6BgA uxzPuTy71DVJ3kGEzbvoRGyUJmxUBj9sGkgLIwre+T0fMEJcM5LoA6bD9WR41PLAdDRLeLxP eYXHfnQiHkpLBw/KZ0Ku8KhjeM7dsfeH47Qc+irH4dujKVEporqscrdRSb+lIvv4ABEeB9CJ eCgtHTwonwmJeNxG7BrkaOzjtuPvM32B7EPlm2XOfGg8nu223bsG4ajfX4zIlxFGy5BEjJQ2 mO1LPF42ZZ2CEHLWvnzHxebqPrBRWjr2EzZFHpj2JR084G/W2pcmF49r+8BDaengMZDtSzp4 1GWxfbnOxaOlDzyUlg4elM8Ej5te//NZYsuRxPZlDnFXIGoTC5Bp+ayawG95+5qvF5cnWutJ 9YJfy+qlH67HsluKyIfQuC++LPm2k0a0eXZljDYI5Yi2/wsAAP//AwBQSwMEFAAGAAgAAAAh AJ+bnPMrKgAALMkAABUAAAB3b3JkL21lZGlhL2ltYWdlMi5lbWbsfQl8FEXedoccJBCcBhQD BiYOR0KIZMIREIF00g2LEjELETkCAiIfKrsggoAcDgYVkRVwUeKCLy4guCwqoOviHREVlXV9 FRXXYxHZFd91BRXWgyPf81R3TSbNzKQZZsa83++rX578q6uq63j6X1X/ruruSVAUZQqQBjQC 1uLffYnwWO6nCsTdqihZAy4fqCgJSt7rinIsSVHwV8f5GitKbwQ+jPPnM9MA996VTZRBbycr yEDJA7IAZNclQUtQMuFXgUZq9Uc8bZwFpt0NPAcwrVdrJNKZ5fqK3FqSko44unZast/fVlOU cxGWCrA9VWhLqqY00uDvAbAcCOUt/oP74+bN/ZkuEAyX6eCtSdUSEmW9Gc60dK8Nfrfkxo83 F1Me2TnRUBLmK+ehTSrizHoqyoXwsy4TANaXbexgQVF8/eC1XK2f+V8N9AaYnpJOSoYmm0Gn /e+IEFmO9COt7yqEs9zJwLnADQCvM8tanTI8YXVKwcUyPS6lT/oR7QuobzGOLefz+5lHDiDL 5bVbCvgAXrtY8d9/T1OD/FOG4j+g7nHnuiuIIdcFkJLro57hCUc9Pw/Xy3bOLOK1CgQOHet6 TuvtJSe/TjNWXdteD6br0eDaxQoFcVIf2R+kP9mm19TxXDTuYUi2cXXKiuR5nl5NZPpo6HUF 8i0DTL1OSOwLvxfguJAESafvSzP0Y+106uXO9R300fPTjEZzs3UZriQkLDxXS/CpSGudU+OE u2ykzwDIQaCT7WN4S0D2QxmeCp6GIzwP6ARi1kJ6IR+BZPmzPEfSjnoGNxnnmd2Efnke+QqW H05xNCZwHNgL7AbIV65mjkEZOFaU6hIhLH/iO3rJhmlttVStUYoXYeRDjMF/zO0vklj/kiGL laHKpfhfCn+h1sg3DXIiAFdDDogUYIgyFeHXKllI60t/qL9y8vz+vi2fCKmsSCnicfXgdkL6 UgqF1D4rFhJNLEIWlqv1t0CI5JftoJ+uFUA/w4YC01AJUKwcqampgfC75awcXGMwX6xMV65T xov51ww98/9v/3euOOnQZzc0paf6TVNOe9uUMsfbJ31+/BQuaNlf6sZ7ZQJLNlLMeM9lZvrJ e8zjwl/+TZyvWOXZTlP2/zI9lWFv91so6tHqwFsi/XIrYRtv5Szhtc6XvMn6+4+t8+caVnk4 iXESy0UmmAtR3sSbxdTqHw/IdzkwDbgC4HElQB0m7ZubNCu5MbNZCeOaA9SRUiDQ4XIJNwKB gfrD8mkjSSRZJ8m+0gwKQ33fCmwAqO9dtFr9yIW/A8KpH7hKJUJY/jeLjuvUfWe6XBJXXZbt C+T2PBzw+FL8s3PLuDPjtkRcW8krZShuqxC3FLBzG86+OJs5j+M357z3eh4oMee8hAS7fcdr SuDy12tfJCJVb5G2VlIzXVaYXUjueZ70J6Ogq3DMMqcC9NO+eBiS1+SoZ0Vyi8bRmfNYLnW6 AigDws15/9j5jxLOcbSFOec9/K8DJZwDZXikc55sN/svdY39kH4Zngo+huM4D7gOWAvcBDwC UI/yG89usjplcJOMxkfS6JfnYSg867ltMfKfB9Q3t5GTFZcvLWH/Lkf6QQCcf64iz0Mwa2Qp yr1/MGenbl+Y8roWYWcjRWmBcyUnGZYfos58JNtM/WD544C7gAHA7wHyR07l+Mg4pmO9SoFA J8dHxlt19o/NTCfLkuOhD2EzAHufzdVCj4eBfCGZuG+D8PPFunqVat2cuXEhixBguUB/JNyw XQ8D5GYLYOeGcUzDOoTipgxxXoAuXnzkKb5TPWOgK2zrYwD52ArY+WCcEz7ykI4uXnx4Fe3D 8JZcZH2Hbd0OkI+nATsfjHPCh1f0itP5WInzOa6cSX9p88WnekMbXz5FByFH/4G0c8Q4cvRz jS+BfGmoRw8ALm7jy48WN5yw7dwwzpn+mJWORn9ywkcsx5dG4IG6khSED8Y54SOa44sTPmI5 vqRYfDQLwgfjnPDhVU4IBbHrRxVClwL28SVWNvT8G9obo6Zepp+3tZmQsAMblA3dE3y+Dj6W Q+6BhFA+ytmUPqX9pnTJHW1F6Ue0rwP+EfAWC2HzM48cIB3gGDcQqADKAPLO9eS+8HuBRgHr Rj2ONTMGvDRErBuRMx7/uu1AIRkeDxs6H5V/FfXqDflXyCRgQft/px/1bEpf0H4C8O86vLRE PNuJYcs/t8PriCPysgZYDpCXcDYh78XuuauXTht6MtKTTzj/mJ2Mg1LcEV1jrqe89Xk/ru4o 75SZqz6frjLlXTtNu7rmG1NG1Xacgjr0AW9/hhwLuRuSvEi7mnHk1qwrPAFO2tUjEBbQDv96 QyrC06z0UhfPxsYO5FNDvj3MvP18st45inZLoxjZlOMsnq4JwhPjyBPrUGrWy/9f8lSGkBwr 1M7HYoTPA+xjXK4W+p4jkI9BOLcvAOfnA1VCPx6m+B5XBSO+F3PDMtMC6dMBtiHD8kOEvS8b gfhrURD1ZzbkbshA/WEceYEIywvr2QRp6Ozc+BA2A4iUGw3nBtOVzorS8xdhGYnc3r7F4mR+ EE4Y50RXUD/h7HxsRegG4Ez56HjlGJ1r1Tk4NxPgOK7Y1qp5nWY8+tzTHLMGwW/qVE0dnSrD KrCy/BpztFrWMeyo1AJ52HWqBmGtrPAMSNaHaVj2UGAaFIj+EOvQC7kOzToiSVTcD2VTxPrv kRJzHVhRLkpmxvut437FVbPMgqjZqGM382hotyZX0Me60j20MQfTLuPN8CQewN123qqTXMdu pPxKlCPTDVlqHh+05PKXZtZZh5bpnvvcfYrny2OzFrXlkDs6dUCeKP+P89uL9LJem681z5f1 UtDTQq1Dj0A+tC8+hRwE+W9IlifnA8Z9hWPmXQoEusBxjjoS7f5M/aVeaijU7M+1esk69lGU T+4Kq43B+7NdH2V/YxvLLXDdmJwMhrRzwjhywjqE4wT1E07mf7ZzYX18DFSUMRtjxMcQi4/h QfhgnBM+BionSH3Uxvv6+Oij+Lp9GCM+Rlh8jArCB+Oc8BFv/ShVfNuPxYiPMRYfnP/t/YVx TviQfcneX6qgM0sB+/yXqimNNIRzbBBzG+RbAN3Z7ql802eazj2Vny59kPc0Dep+cCra9zXA PZV+GIQgsKeS5GrReHNLyR0mhrjcD3Lv5PHytWJPRf3yQbGn8nbz1WJPheHxuB+8Du0vBA83 QRZBch7Ob/yvlqtTXmiZ0fialvQH8nK294M7kP8WgPqYq4W217lGI20wL9J3AILZYMkItz8v wHloEADz3m+Lmffpw5Qsxbdlq+jHvj0Hhaz+6JwI7Fr7PJiD0tIB6tNQoB67LOrPByx2+HyA OfPWscvKUF1Rb0ppN8H+KeMx9YFO2mXy+QCZzoyt/W9/PkCmC2OXldWe7cgus9KHtsvGIcO/ Q5c/gTwKyf4O4bfLGPcVjqkTpUCgk3YZdYj3WVmQTQBhbELKvnA29ojU7XD2WYHie6pNFPRS 1pd6yTYRP6D95OYkpJ0bxpEbiJDclCGuAH0LIm585Cnajd1ixEcCyCEfiZB2PhjnhI88kgEn +Y69fiil/WPER7LFR5MgfDDOCR8FJh2n8VGF8KVAvOyR6Re+X0J7pPHhNGN+A7RHOP9S53LB q7RHtqckueZ54m+PTMdzjUNgf3CtjPaIjucaW8EOkeHxsEc6gQfaI15IaY/M8lzT8qjnhZbj PP9qSb/sY7TTztYeWQzu51n6mKuFtkeoR/KeiWPoIACujn0R72c87kYFOG6tB+zjFuPYT+ub 48w619SkIy1BJ/k9mzEskC8NefZgxgF8cX6J5TMeG5E/uXkUsHPDOHJT3xznRRq6ePERyz3Y x9EO8rENsPPBOCd85CEdXbz48MbwGY8n0Q7y8Sxg54NxTvjwIh2dnY94z3Ecr8cuX6if9+4p fcC22xvcPfcJdLQEgPfczSAhcM/dXf3I/WdVcheve+6RT9XoPz17p35vxnF9dNkd+l1KjX7B nEpdhsdjjuMzM40BEqFCJsH7vfsHdaL7TfUz9zSV/kBeznaOW4r8fQBtrliu+xiJd+s/PXBK H2csE2sXDelZ2uPg+VyAOpgFaerg+OZ73V82D+Ra+klZB/wj4C0WwuZnHjlAOsB5FmvIjp4D aHprjV46ZIWevP8nvfqfy/Q5r5zSXem/0WV4PHTwGDhoA9CAaQ9QB4+4c1tUuE82/9C9rjn9 koto2Fnx0EHaHB+9tVXY+vt/eq/B6SBt/XHgmrb+Y5DUn+0pbVrN81S3CeRa+hEdMx2kTb9t 57vC1p/+u/eFrT87eZ+w9RkeDx2krb8JPHght1k6OMszp81Rz9424zwJF9AvuYiGDi4GofOA +tYeqUfHRm8S+2flSG/a+nXXEqNp69vXEmWbqR8sfxxAe34IOFoPeTUk/vzrWYwbgwCOQaVA oAtczzLr7M7ieEXQybKaQdc4fvmAGYD9/jxXC39vJPlCsqD7jZHa+vVxQ35oz5Mb2vp2bhhH bshXKG7KEOcVI2D8+IjU1nfCB+158rEN0s4H45zwkYd0dPHSj4IIbX0nfDyJdpAPPgRh54Nx TvgoQDo6Ox9VCFsK2PtLrOwsjk0vFT+jV6xpo/e95AWO0w1qf41z3E3g+kHIBZDmHHfp+ZvT dp8vuYuXrZ9a0kZvlvicfnFzj/7Xv72gl76Xob83oFqX4fGY46gfs8EDx+2FkEmQD6ctPN/T 5OPz70lLy6A/kJeWiOfYjKR+XYPXkR3A8Zu66ANiaevz/Z0HLtqlZ9/QRi8t3t3g7KzJaP8d IHAN5L2Q1MHVKXdkbEpLax3ItfQj2hG/OUjIa8N5llxXAGWAyXXwZ37fVdvomWmv6kn7L9Q/ 3b9bP39Dhn5w8Bu6DI+XDi4FD+tQ1/sgqYPr0nZmtGvStvXdaZe1pl9yEQ07Kx46yDUP2vp8 zqDieMOz9aeCY9r6vN98zNLBo542rVo0jr+tz+cMWqTsE88Z0Nbnu5vdX35XPGfA8HjoIOcF 2vo3QUpbP79xwgWrU/a2yWg8pw390dTBxShnHsC+mauFtl25F9vi+o02W7/uur65Dxyd5wZQ pTrPc8o2c4wqB8YBfwdPpQD3rqVtIp8pZNxogGNQKRDoAm19s857psZi71rypaHwHmYFalAl MWdRFkS4d82sWgHpQAZg54b8cH+a3JwE7NwwjtzgLyQ3ZYgrUHavh/Dnfzb3PoH6oyHPYHxE unfNOtbHRwIUh3xw79rOB+Oc8JGnlGgsS/Idaz4KUOVI9q5Zx/r44P40+eDetZ0Pxjnho0CZ MDIYH1UI5NwWL1v/gXu6Fd/z8UHdddGuEsqGZuungYvd4Hoi5B5I0Ks8oazJ9KSsyZS6FC9b v3XSzpKqJw6IOY5c8bgy+QshGR6POW482v8KeLge8q+QSZDNU67KXA0+mqd8BlxVh5eWiOdY h6T+vgevI1uU9ucaYDlQ3xxHPfq4creY4yYjfQUA5x+zk3EQ8E7Srib9lZfP7a88fp0pL99g yh/eEtL3q1PmcdTfreKYvxxk9IX8PSR5kfMe49YiwKwrDgKcnPdGIKy2HfvHUz+JVEtC+Hk+ mzEukE8NeQYb83MU37bUIsFjVHkqR3n9AfJUDGnniXHkCX9h58AcZejrSHIaH4sRNg+wj3G5 WmgbKpCPQTiX1w/Or18cF4bhjqn6n60EI1pF97DMtED6dIBtyLD8EGHH/hGINwDychWknRfG kRfWpRQIdFJ/yhDIeja1IuUYJnVlMcJjwU0fJUvRplxucvKLkTHhhvyQmwpIOzeMc8IN65mE tHR2bg4ibB8Qqd5swLlVAJxfb3gdyvANralYkb4Wb37OwBdgpiq/Ri2U6Yf7KbvxHO8yjFGU 3VYI6dtUbR6P2Sek9mViEeOr+7cW0te6o5Dayq5CKlcMNOPTxprHUe2ry1F/2ivrwftYyCch 8ecf0xi3HQFsZyidnIi44Bxo7/A8jocc43hd5FhHvzxmGJ39eq1B2HIg0utFPSoD4PzXi2VO U8bjOk1WlB2/66+talrku+gNIZX1PwqpbUktYjimOUC6Wn8kfX8isskBngKXBuRrNp4Zx3mZ 9QvFczniZN3JmeQU3tO48yFsBhApdxrO7QHA+blD9ZTOivJ/ssKyE/ydLGZUn138C6QhP5dB 2vlhHPlhHULxU4a4zsrzhyFO42MrwjYAZ8LHH2YeKeaeUdTesex3qfl2ztHfhX1LJ5h+1aDu gfxRX9IBzhVDgWkghv54vWO5bljE71j+EtUUdaWUz97jWX4RnsRAOPksfwzesRTlYL4UzsE7 liJ9fe9YFiC3KxLMvj0WEn/+MZRxvM/j9Qmnu9F+x1Lqb7hn+PEOXdo7YbUxeH+266Mcu9nG cgsDIMkJ+66dE8bJe99wnGA+n4qkp/VnH8JmAJH053B8DFR8d30dIz4Go77kYxiknQ/GOeFj oPLZOiSNGx/QD+trA6Fmw8j1g3pCPoZD2vlgnBM++ig105A0bnwMVXyH28XonYZRaAf5mABp 54NxTvgYqhxoh6Sn8VGFsKWAvb+kakojDeE9gGi+Y8k94A7ffSuec1rpSsd3yRveHvBBcM3n nLoB+MNzTle3m+dJai/HssZQeelHtKM1Dzkvc+17IFABlAHkPdQ3d/ic0/zvmhjcLxpzdbrB dxr2n9vMkOHxWBfic05dAC/QE0hCnWd5nvcc9WS0H+cZ2J5+yQV5Odt1oR3If4vFS64W+r6d etTf96WwwbxI3wE483csa21YXpdoPheF7M7GLmtI71gOZVtw6YULsMtEOPWBTtplMXjHUpRj luLoHUsrffh3LO9Ghu+gn6+H/BwSf367jHGfIYA6EcoGKUecqS9NDqTDT9DJviDXXXwImwHY x1cnul3XHqnVVdY10mfScGodvZT15fVlm4iNALl5FNLODePIDesQipsyxHmVVJp3ceMj0mfS WMdWAK9fBhCMj8cRTj62Qdr5YJwTPvKUpAlI6s8/1voR6TNprGN9fDyJNOTjaUg7H4xzwkeB 0nMukp7Gx1aEbQDOpL/wfob7Jv//fhzE2VxyneNGyqqMRsqpxs2UXuqFFzOqOFsmYI+u8279 MB5zXKALGPdFeJIZ7B/3fdaxTGfmRrvB/MaSFa3Ib+/LdGHerRflbH3G/FaSg/txkd7J/fgb qJyBCn0IyXrKfZoC+PchgG0ON7bF4n6c+lt3vK99Zpt1jPX9ODnhgG3nZIDFCesQjpM+Sser keS0/uxD2Awgkv4cjo9Y34+TDyqUnQ/ej1NH6uMDz7A8hqRx4yPW9+PkY3gQPsod8tFH2fli PPmI9f04+eCEbtcP3o870Y+hyhMvBeOjCoFLAXt/idX9OL+B2/nvnQx+A5eyod2P857zd8By 4EEAf/gG7o7OU9rv6CxtNd53Sj+iY3Y/zm/erv8uW9yPkyseP/ZGRyEZHo/7cX4DdxXQG3gI 4Dy8oP3Jzkc9OzovaH8TcLIOLy0RT9uW49WZcjQQ5+wBqgHqY7h7Fq5RPNXRY0TyG0mTkX8F AFfDehLJgI5fH7pWGY9dVN/Xd4u1V989r5trsIs+FrL6RLJYc/P9uW0Ea28ooo6tm4NjcgVa neydRO0eHcUJ96uZ5u8UlVWaUn6fUrOOw3yfksOwqDeltK2wdyLCqSN08h49wfodJZnuwF7z d5Sq3jNlBN9BEuWkmcU4+T6lSB/OVpuCvPi9xcXAVOABgHohbTXGsR9QT0qtcqWQz0SMQECt Dh2ezWtLLlhPWVfZJ+T92COIWwPYx99cLfRaFHV/dVUXofvUoUwg2FoUquv/5iqys/ZR69p5 QzDUWV9cDbHL7GxdnfVge1nmUGAayKM/XvuAx66MeB/wSlQzmC6L8NN1OerfWhXlQB+Ec3Df IdKH02UqO+exx4H+wAtAoC4z7nkrrNQqVwqpy2UIGKIk8zT/OC51tgphSwG7zsbKZqC+X1n9 T33gPZX6k1NqGtyznWSJz3Ty/QU+R4w/fLPhw8zp6tfujvCzX8TLZlhy4yL9T88qxh2bbtX/ kawYzzxbqS/pcVKX4fGwGWrQ3p/ARxrAZ63Zh5ap+VnHXY2yZqub3PQH8nK2NgN10QdQH2Op g9ee7GnwuyH7mvUWtldD+mbDCXD9PrimDh4A8Acd9F30kTupayDX0k/KOuAfAW+xEDY/85Dj eiL8tM8qgDLA5Dr4e1z8Pkj3lhcb/G7INWN6G/xuyMvfFBoyPB46yO+GiB8nRiP+AVAHv3cP 6DrRndH1M/fzF9EvuWDf/N+ig/ue6mPwuyGTPujb4HTwODj/ElxTB48B+IMOPtZ1r7swP5Br 6Ud0zHSwKb4bUvFxP4PfDbk/p5/B74b0e/YSQ4bHQwePgY+vQQJvMn6ApA4ecc/Or3APzv/Q fbgr/ZKLaOhgFcpZCsi+ORv+KQBtw2yUTffmAzfpj12oGJTasQTj2O1z9MHTEo2s631CDmi+ SMhRje/UixFPyfThZK81J3Se59n4o858KL9HvpR7UA7jZbmH8iv10hMJxiPtF+ql1Y2M1+bM 07cvaWS8et0c/d5FCUZ5r9l623YJxrMrZukP/l4RkuU/h+MFeo3O+FsvO6Uz/cr5J3WZ39ZB c3X3PSd07/hbdXfKcb1i1W16+Y3H9THuRSLd/TsWifMmNL1d5EPJfClZDuNZLtOzHpQrILch 33bIV0ms4yprjxfWehMWGnV/y7imRo6fuAxirLXG237iYoh/tb+Vyf7C65QBMD0d51I6qScM DxyrLsFxKnABoAJ9XJh3sxRlBPyEdNKuQzTSLMh6wPVJ1jnqJ1mVwGfqAiDNhpXuSrWn+xzg AVdPdx/XSiAtixUPLG+Sik6cZZalIU46WR7vezqq27J2u9ZnrXJNyFrkGpR1i6szkAZ86V7k esO9yrXVXYh0KiDzs5fzJ1T8Xnf4cr53jXcPU6e6F6lb3VXqG+516pdAWtY6tXNWlTooa5E6 IWskyjCvATxwsp7knvF/ct3rlmX3RRjb2h/IAL4jcAFcwDk4IfA6yOuDJI7GNM6l8bBb+P75 FdPPNY7hm55fTMjBnJGY2JDslsngoQxc8vmX9QD+8P55247zPK1zJaccG6XfKb85SJgOJAJO 7ZaVH6cZvx1orre5duQYxXPB2aTOhgwPNmfIctgvqVdn2r9xinCyfcwnmF6lgoPhiMsDOoIk rk16gY1AEsJme97BmlzX3Ks9o3Lpl/lFY17Zgfy3AJxXcjWzjRk4xkpdiRCWn7r2VoGKdYnE M/zd8kRfOfIYZGZWQw4IXrv/F5+RMZupKB/cbK67HRlo+30Y6zjM+htVQfQVSrmuhvU3EU59 oJPrb/J3zGW6KKy/iXKamcU4WX8T6cOtWYxDXncBGvT595C/hKQOyPU3xl2BMOpEKRDo5BhO HbL0RfR99n862RdQX99AHPuAGQD1uYtmjhM4VJzodqGW6MMpQd9JiOUzMg+jTHLDfmjnhnHk hnyF4qYMcV6ALl58xPIZGW52ko+tkHY+GOeEjzyko4sXHwURfreJdWwFUJ857sr6ovn+Z6i2 w08+/gxp54NxTvgoQDo6mb/sL1UIWwrY+0ss11rc1V6D631DWvXjfW6D+m4T1/teAtcFwH8A /OE+15s3XR1Y535O8ohoRzZhDhLyGp+JzcJ1vT9c0F+s9314bT+x3nfxT5cYMjyYzdIBZRCo Fk1dy9X62R5Zd44p9dkjNUhzGCdxve9HyCQcL1PvzD/uGpU/W63pSr/MLxr2yGLkPw+ozx7h 9ya2pOQZHLPLkX4QQIufbSKibV+Qh3D9dBziP0XBj4Mjrk9VQ7Ieco5jHNfqf645LpAvDfXq AQTyxbpGOsfVxw2vz48ogNywQ9m5YZzcxyhFkkAn5/8yBHqtCKlvcgzzIXwGYB/DcrXQ9qwT PiKd45zwwd97Jh/8LWg7H4xzwkce2kwXLz68Ec5xTvhIsfhoFoQPxjnhwyvYOJ2PDdAvrp/Z 9YPvSgRbR0t66kZ93cJ+BmWPK4uMrutm6UVva8bsIwuEHO+uFHLWeXfoPRFPyfThpPrYJQbP S+7ex5iDfCi9yJeS5bgQ7y+3/226VlFk7Crw6VqWZtTcd4u+8X+KjFO3z9LvONjfWDrsZr35 gv7Gd4/O1FckmJLlH8XxEwn9RHz32/uK9C+062vU4DzKJCvfLyfO0ZM2XWJcN3++nvg56vPw Qv2/Mi4x5lxUKdJtf7VS5/m3tl4k8qNk/pQsj/Esn+lZH+aXiPxqF8vEelrAOlpCwELaz7+O lulSlPH54dfRMl3v58919fQeBiaqPb0vq+/nv6yOt+GrrhPV33Q97PpN17lApusrYHw+J95U QK7bDVLxHJdVnoZw6eTYloaAxmqad7PreP4c1zP5k1wP5Y92LQTGA8U49iA8NX8k0nWQJ0PK 89E9FMYPUvedVvYqtPV/uoZfW9vnerprT/W1rpPU1Pw5qid/kVoMjAcW4vih/EnqM/mFKEMF ZH6yjX0RxrbKdbRv4D+ECjVDf0vCZBfMvkASRzYT7+d2ATuA+uwBzwvpxonf7sNzr4m+5Ui/ CIDz2wPkeAi+mpCFuyj569lZeN17lvktl9ueNr/l8sMhIauHK+LrE77mGUJqe/KFrL5wgBn+ cYUZftUkIdGgIhZnukB/CwSlA6BD2Pf004WzJVj3y8DhVpy0BPIlSJ4vbQnGvYgAtqkUCHRS J8Yh8PT2/krUheclAZQEr58Mg/e0+WQxwuYB9vEzVws9vwZej0E4ty8A578eaIL4xoiycq75 BYtnveYXK0Iw2QLpyR15yLD8EGF5HIH4i1HQyzipFHIvJM+XPDKO7x5AhOSxDHHhvoXiQ/wM IFJuNJzbA4Dzc8M64rs585eGZST4szvMKJxulSP+couTsiCcMI6csA6hdKsMcTmK0h3iNF05 iLB9QKR8bMC5VQCcn4+mOAj+7Q/l0CMmR+9+JqSvH77JhO+c+D5sZX7f5EmP+T2TqX2E9O26 wgxfO9oMb3OtkNV755nyF0vM8BBaGBnny1H/YRbnq4NwzjhyznaG4nxiaA7EecmIl31Y9ukk hBE8JujstuIahC0HIr1eFTi3DIDzXy+WKb8h4kt92fzuyYJvhaz+URVf9vDtzQz7hY8WyCMd oB5mWH6IsLpNjkaAyw9w0gzIQ5A8X/Z3xv0TAaxfKJ7LESfrLnljejo7dz6EzQAi5U7DuT0A OD93rG9nRVvWIyw7kekh2zbL4ueWIPwwjvywDqH4KRP1wz84Ox+PIGwNcCZ88H2r7xIvL+G+ Qg7OzQTCP+8YuEZbe7/POg9RqhdF8uxuDc4NHDNZj3TWAxgKTEPm9Mfrecf7hlvPO5753sFV qKaoK6XcE8DegQiXeiz3DhKi/9vyohzclwvn4HlHkT7c3gF1diTAfjIB0AFea9mnGVdihYXT 2SHKv44g2Wk660PYDOBMdJbPLFJn6+4X2HUxOs/eyj5G/SMXBJ/xJB/9Ie18MK4EcfX14SFI Qyfzl2spuxC2AzgTPriWcudv/oZ3JqO3NxjLbw2fYf/G851JSjHeHLgO7w9MIWkRurf/O1ec eRa/UTyCGeASCxfQv0V4khUu+3cM3p8X5VjFONkbtNKHf3/+71DWJ4GjwCsA/vz9m3G03xMR Fqp/s0+Y+sKRJPq/UUzdrtvX687XBTH+zjO5OQnYufnB4gYiJDdliCsA6Ox93YewGUAkfT0c H7H+zjP5SEQnsPORgDDqSn185GHlBM2OGx/gP6bfeSYfTYLwkeyQj1C/YV0FjpYG0Y9Y7g1u WHO52Bt899uRDXJvsCcGIu4NXg8Jgb3Byd2nq/MLZd9qrMTneSbuAXb9YZTYGxxbMkrsDb7w /gixN8jwYHuDOahvOsD+0cECqsulPMvV+tm2bCADYPpAJ9vK8JaAzFOGpyLT4QjPA9jRrgFX 3D+cAsk5apn6YuFx14rC2WphIf3yPHIXLD+c4ni9cDESzwM4puVqodenaLMUfD6owe0ftgdH 3D/sAUl+pZ3L/cNuCMNfyLGe86D5jEz0f8c4kC/Qat231rV5Y71/SG7Y6ezccP+Q3JCvUiDQ yfXQMgR6ozzuS/3RkHcPANpe5z4+1vuH5IP7h3Y+uH/ohI9oz4P18eGN8f4h+eD+oZ0P7h86 4SOUfmyAYp3p/mH22FFiP+/pggqxf7hryxixf0jJfUBK7hc+g3hKpg8n71syQpy3xHWV2D+k 5P4hJfcNVyKeUpSLfb5XeleI/cNXT1SI/cMur1WI/cCmL40W+4P3jxot9g9bfTpKSJ7H/cPe n44U8TvGjxTp9eMjxP4hJfcPmS/3++6qHCH2Dxe/iPpg/7D9MUjsBzId9wd5PvcLmR8l86c8 D+Ux/j6Uz/RNUB/mtxj5/W/aP6wqrG//sFmvua4pvQ4DE9UpvV5WmwFVhXXRvnCiuqvnYdeu nnOBTFf7wkxXVaHcWwvcP3T1Cr+H11jVem12des1x/VN4STXB4WjXTuAKmA2jkcWznEVFXKt hPO+dHJsRPfA/mFR4SDV1cteNvf7LrTaqskTIeW5XCPd5zrSs6d6qucktahwjjqycJE6G6gC duD4g8JJ6jeFyMK/f8j8ZDl9EQ57oc7+YQX7MfrcLMiWiEsHOLZLOwFex/bAUiYGaA/Eym59 ZVlT4+MdLuPK8yr1pq7MBvccfhLI64eL7AWmA7zeBz2H21+jJmVLTuNlt1b9UKlPOretse5P C/T7x2Yar5dU6v/5to0hwxuK3XoKHN0AolLB3UzIJBz71IHZX7kysq9Tn+9EfyB3Z6uny1HO IsDU04TEafBPBLgW3gll032xabp+9S2ZBuU3l7czmq+crZ/Y7TZGH7hVyGFVlUJOvucO/VvE UzJ9OPmXjW0MnrezS2ujAvlQtkS+lIdQzh7Ey3L/89Rt+snydsZTm336qQy38fmdc/VrPm9n HJg1W9c/aWtMGzBLf+vmtsYHa2/Wh/yUKSTL34fjaT9dIOKPzL9ApJ97/gUG8zuF/PYMv0V/ aW0bo3TqAr36o9bG9e1u00c3b2PcsLFSZ7oNRYt0njft3kVmPpDM90ZIlsN4lsv0rMdfrPxC zyeBj6P8/M+jdMEY68bN1ghcY0I6OcYiWuniWpm9xPVddg0wQ/0u+x11JeC2YXOnGergTjWu wZ2WAF1cmwF3thxr5Xxylaoo91vlabIwSFkex/RW6mvZT7uezl7smp090zU2+3pXEeAGajrN dO3vtNj1aic5psv87OVsRMUfgfKyTRogXWA5X7hmdTLU2zvNVF/ttFjd3+m3ag3gzv6tWpS9 WB2bPVOdnS3LkfnJcuxzx7coYCL66jnoNz7Is+2Ti5HfPKC+e8mcX3+qz1ybZruXrF0jxDRm rU/G77fzeL/YCRx8B9kLEqLOvST3CVivUiDQyWtTjkBzTXXcsmivqQbypaGcHmYF6tw7FcRw TfV7ixu+V2/nhnHkhnyF4qYMcQWKpkH4bZJmULmBOPYBMwDqTBfNtF1wGPb9Eyd8xHJNlQYB dYX3jXY+GOeEj2jeSzrhowCXJ1a/ncd7avKRFoQPxjnho6GsqT741N6Sc4Z6jS0vpRnND5U0 uDXVyegbL4LTzsA5GJAglI0p5+Xd6HnGG2hfST+iHdn+OUiYDphjr7NvW5z/xzTjxzeLjYP/ 1dT4Wy/dOHRFmjHm37ohwxuKbdoRJDVGw/IhVcgktPMGz03eQ563vOWeE176JV+061taXHBM k+HwOuKRY5rTeZC6xm9XcW+oHOcNAuD84zqvRSzf+ZRtow6x/HHAEuAxBKyDpJ6RA7mmyrjn EcZ6hRrrmU+s1lQD+dJQTg8Azs8X6xrpmiozagWwD2QAdm7Yro0AuXkU0s4N48gN6xCKmzLE eZUhayH8+Z/NPOiEj0jXVFnH+vh4HGnIxzZIOx+Mc8JHHtLRSb5jzQfskA+Lo/C9QllfNF/0 HerHEwD52AFp54NxTvgoQDo6mb/kowphSwG7nRSrNRrq1vb2l4t58Mmnr26Q82B3DEScBxdC 8jpsTLm0+42ew70kd/Fao+F8t+bBsWIenJ82TsyDyovjxDzI8GDzYAfUl8C00k8Im5/tke3g mNIS4NhEvwxPxcnDccw+xDnuFvCQD1kJmYSwGzyP9DrkSexd7vH2pl+eF+85ruh6+75h7ZiN qv4sc9yFKHgdypb7HIFznBdxrFcpEOgC7/Vi9W49+53kS0PhPcwKxHWOIzePolw7N5zjyA11 MBQ3ZUwD0El9k2OYD2EzAPsYlquF3nd2wkes5zjysQ31tvPBOc4JH+yfdPHiI9ZzHPngHGfn 4wmEOeGjgGTA2fnIRJgK2PWDujYR4LoKilbWYoxbCY88vh/H9+K4s7IZsdIFvlUU6JfxdaUH h+kA+/hAyMC6NNLMOAQr5wDn0gOnAvT/XwEAAAD//wMAUEsDBBQABgAIAAAAIQAgOTqUjyAA AHzQAAAVAAAAd29yZC9tZWRpYS9pbWFnZTMuZW1m3F0NeBTVuZ5sstlNWJIlEAiCMbAJhLgR KBEtBZlkt4gYeFahBDBNwQtiLUrQ1FIay0IvSiyW8Cdpi62UoghYL0rlKt6CPKUVayqF1tt7 a1uqYm3rT2/5uU9bHnPfd3bOMgy7s5NkZrK558mX7+w5M2fOvOc73/nONzPnZEiStARETpqa KUn7GVHD+7WSNLpckko+PX0Kj2g+Lkmb3JKUJQ4QPFeSHkf6HJck3aI5n9mHR+ZId5a6JRQg BUElIBR3dYacIQ1F3A9y+Q//hqfNV4nHvgJ6CcRjx8gu5bjYdaOTr5KzJB/yGIpldzx+pSxJ A5DmBaEq0vMo1CtLLhnxKhCvAyb9nP8Q1h/54mQepyWmi+MQ7fDKGZmi3kznsQw/m5Yf/nPR sWrygpntIcAjFeKe/MgT+AxDnHW5HcT68h5LVZKk6CRE1XAxzvI/B7oexOPJGQRnan4s6bL/ ZUgR1xFxNEu0Dum87qdQ+CBw3vRjKJzXOhnYlHEysGewON6D40Uc2VFNfavxWw3ReJxllIPE ddl260BRENvOLvy//YlxCv7kyfDX1N1xrH+mYv26Buv24KaM9mDvw5oyvtg9rKbp4NjwxAdr ayiYelnvSawp1yMgb8fArwUHg1yvcS0NjssUsmyFXNej3AgoJtcZmRMRHwOiXsgCZzj26Njw xjdvqKFcDp0/o+ajprHhVbvm1oh0KSNj1QA5I+rHseo5HWawG4nji0CA/pIg7o/p/UGiH4p0 L7ribKQHQUcBzGjwdvDrwHn9O4IXXO3BCZkNwcWZjIvziFei8nCKKZ3gpB6gbP7tZb8qmxmr uiOblB2hawU3o3N5nsDODYzq8JvtWo0Myib1wLXgPK49uMY1ttQa2WR5xNqMbH7J20+RRfZn yuZ33vUrsirSuyqb4r7NyOAkVJgy+GlwIYOh0sWZJwMTMieUXnAxLsqzQgb34lqP83oYiyrk WJsU4TcskxqFqXExnntlV/YYpLHtFDvgk3k3KIeo/9zg1dKt0k34X4v4eNkVnQo+MZbfQQxI bJcZOE6a0zhJajs/SfrZ8BsULkUnxw7l/4vxAvzygXgu68c4w0AQ40xDaVIjDmDZZzo6OsDi oZUnInikLNTsXunz0gLFtouldvZ/gfSjWe7w8ilnPUNwagloqleSWr/R0fEgrvtSNuxEAME0 EutTdE+GtGaNP4yo1Ha6QHqqYdby6NmzHt4Qq1YOip4762l8t0CSbzzrYdmncNxd89zhocgb Dnoc+T9GGkNRZXjWP4flyO/j97J75y0vQdpenNsG8v/grOcl8KmgtXPdYT/yVsJ2bcVvkiTN W45qKeHoN+ctXzkoZmcyAaaqdORCZvj5scNGVx18IZt1LFex2wVOrBfer5ht8f7M+5sFmgMK 4UcRf4OPBFdOjR6sfvv6g9XMo+zy+FqQNgA2JUSQSLlgPRh4PK/ZF/CwH68FNYMor1fLF+Wg AnHKJK+dTHaNZHEMR6rD/6rIYLR2b7dlUdSb9yqwmY0frN/t4HpsmGcGG9YT/V4J4hrdwebD 34xU7EQjbKzup6LeWmx2qtg8nwAb5pnBxmq5MYONE3Lz7yo2P06ADfPMYGO13Ezxjg8/tGRN jZHcTJFmSpJ7UKwvnb7blj71Lu6/Gr3hHHgEXKtvmDcDaWCG+ob19OIYBiGbok+1IW0dSK9v 7Jy33Tb7RcVeOzrwOOYSGRndsdeg9rtkr/E8gYUburcOv6lfaa/dBk577S5wYtsePOkeW7oq WxwP/RQVcWRHeR4JUTaVGi7GWUY5iHqe1+2Mvfbek2/U0Db5YeYvFHvtr9XHamivMd0pe20h 6kx7bQl4FihU+nz2yUBL9oTSm7MZF1gQl/7I531STkU6oqYwIi7NoEZQKnuNuuutwdtS989f r4/ZX68V29I/nwAu01HfH4LXg2v7J/PmIQ2sy/1zLc4lJvr+WSEntwfMYDNWGitJTz0Qw2TB E7Zgc0DF5uUE2DDPDDasZzJ7wGndxX44/fXzih/kzRuz4fNLL91FP8gKyAr9IJQbMPhBDniW Bhd5RV90SnfR37Hst64Q/SCzfpQdoh/k7tackEh3QncdBQCrgQH9HQ+DU3fdEbzG2x5c4m0I ftPLuBYXp3QX5eiXG39tqLucsEk5X/kCMOFchnKj1V3MW440MEPdZbVNagabMdRdDsxliM38 BNjMNokN65lMd7F/dlav/2ekJjzpp88ayk2E1mLkRGzMc0+1Ra/3hxEzB/UvBV8MrpUb5i1C Wiq5YT1zcByD6IPCJo0irQnUmTFPi42Mc6tACHF/DOs4QZKWbTJERJIKcJwPxOOL1DjYJX4Y UV/e4yyVylRMRiTAhHnEhGXWgrRB6xdA/ZQgyrcbD9hb4560CY9RKh6jE+DBPDN40B5kcAoP 4L/jhE14jFXx+EQCPJhnBo8J0vz5TuIBWV30rk14VKl4TEiAB/PM4CH6kl4+uqJb7yvOCB89 7woZzfdncub2jurPHTjEEJmu6BHq1FwoldXgg8E3gFNnSKp/kXnr8RPMUI+wnlbqVi02Mq6d SLdWStL5ZYaIdF23DsENr8Z1rwTXY8I8YpJKt6J+StDLShSpnR1rzOBRh9lVq014lKh4BBPg wTwzeNRJsecHejzagMc6kH7s9cqSS0Y62155LgJu1XsU7f8oDfHZsus3o9NyTrUD98o51bO8 d9DJQCR3afDjXIGdk3OqrY1BZU614pYxypxqU2CcMqdiulNzqr3AgHOq/eBZoDuCr+S2B7P7 NATH9WFci0t/5PtA7J8iHVHL/UGcN7S+WZhafwt/0LERhr2zQFNvs3Yg9XcYuGwGnwlOudHq b+ZtRxpYl/X3WpzbDNL3zwo5uT/IDDZO+IM+o2LzuQTYMM8MNunkD6JvY8p1oRDfPfjKoBlp p7voy34ZskJf9nFwMPiyq3xjS9/yib7olO6iz9o3/5YQZfHMIzNCfPfA//S0kEh3Qnfx3YNX gcGnwU+AU3eFSgf2PRn4k29C6R4f41pcnNJd9NfmDK4y1F3Ksyahu2z0ZT8HTH4IfI6Aa3UX fdmHkQZmqLuMnjV1RXeZwcYJ3UV/NbGhL/sIuBYb5h1GGpghNka6qyvY0A49dN8CQ7lR5iwn vhvzB/3kGlvGPB9u/BTunbb4R+BabJj3AdJSYWPHnEVgI+P6VSCES/xBmBOcXG2ISNfnLJyr nMIFr0qACfOICXGqBWmD1h9k9ZwlFR4RSVr1LZvwGKbiUZ4AD+aZwSOSRnOWtw+uUuYsH1/9 UNqN+3wO5IJwcc7iBwfDnOV6/9Lgu37t+CbiyDZlj5fjQNrymSD65upBERBtUb4nPxHxMSD9 +7DH7l+jzFkmLH5ImbPceHytMmdhuhPj/lEAkAscOGcpAI/NWZ7xtwc/8DcEh/S7I/jMJbg4 Ne7TFnp4blNq/S3GfRvnLGfQbpyzUG7wB4mIvdPGOQsTyIx0lZH+7srYZgYbJ8Z9zkuIDecs emyYZwYbo3G/DUWsA+nnc3b5WzhnKfnv1tA3vIXhRY9tSTvddSswLYG8cc5Sqcpde3BoQahs f4HQV1bMWZqBeaOKe4WcfO5M+9N1c4thH3XKNu8HPGibEx/8xfsobfNiFSujPmqHbZ4KGyf6 KO1vYkPbXI8N88xgY9RHo4C6CaTvo0Zyw+eR/C6BzxNknJvI/pwhRbc8ZJO9FcAgPRLXrQAf D66VF+axPkwzkpcZSeytrujznUPfCv1t2CkFj6m47kQQQtweRzPBlqiGU/HF2FzluomGyBTg eB+I91CkxsEMn9POQX47TlgK/jvwr4LzfDHWMa8ZP1kXI1xYTyufr2ixkXHtRLKCZ5MPP2KI SNfnKr9XMTmVABPmERMwQ0xQPyUIHd0XqNJGjIKaQJ3pO2bwQNm1223C4y0Vj/cS4ME8M3jw 3hmcwgP4v/SaTXj8RcXj/QR4MM8MHk7Lx63o3qdswuNDFY9zCfBgnhk8UD8lWCUfPTnWUJdy rDkNrh9rmGdurLk3IR67kLoNpNcfXllyyUhn2Z1/HtmhfNc9EeeOUc/PAmeo39QnvPAnuaGy C77w6s/A7AQ/80he6Olf9g3PHtTfdnu5I1aN+H8hHxiy47rEDbVah99BEgarFvBPgm8B532c Hv60Vw6MyJEDf/LeH/hEjijDCru5HuVHQGyPZHP+6g154beO54fem5OnPJO78CtfOPjPASGR fvmcv6OjHGX6QBAX5V36UnDc5iSF6eK4VUXeOO7zeAaBm7hXpvcHiTJFuheFzkY6sRuHgtaD 01/yKDix2xn42Ls10JAzPhDJYVycR+wSlYdTTPlOOB5sA7WCYthJLhnxKpDV8vtb1+cVuf3n hkaFL3l1iSK/r89clpby+0dgQPk9Ax6T3w15ciA3Xw60590fGJivbQMRx6GmcBdyxf7DNqgH RUCp5Pe2vvco8pszuClE+d153X2K/DI9kfxSXkmoVlKZFXU3K5sfojTK5jlw4rIz8Ie8rYGa /PGBqnzGRXlWyOY61hzUfdlMvmZG9nuF4eCpTaEbsgaEDz65VcExnb79mQGsR6Bx5oGPBQeT VpQ1F7jKzlnqe3ACa2JMrM//vjD87a3pi/VcDdYuYL287IylWO9CG1LvWiXXU1HWRBB1thuc gfMVfp+1Pigp32mRf/iKq4bpgjMfeiODfT9dZH4M6nIEFboKPBPtcBc47yk8tCXbV0LyucJD SS2XfOMl9A4O7ZIOdqpNuC4M20JwtoFoK/LYujHp2SaL1TbhOj2xNtkz2FdCaslme4SHWrOO jBgXnWgT+sSkp3bUDFh6S5yzfzBdcOanYz/xACj2E66RNQucbbJlTLG7vorkc20ZQyp2i77B MVnEcWja9hNiz37ANhGcbSDaSuSna5tEAC7bRPSTLWP2DK6vIhW72R78LdrBijZxYuyu+Mf4 8I8f3lzzveeqwluffjztvpH+BcYKjoO/A78VHEw6VLkzq7Iy21L5r0e5EZCRrb5/xrXh4Q/u rFlZWqXolMD8qvDcum/ViPTLbXWp23NNVEkJQq44pvcH+UCMi3Qv+r2Yax4HSNOR9wb4THDa 87MqK925lcXuwZUnsxgX5/UWe57fwnINPHJ1LO3W2kvoxpZ+y78C5Q0CPQCifqCcHvBsyjjg 6X064d6vrQkRa/J0xDoH+BLrvuAC633+TRn7/L0Pa8oz/amlW1aHYuvddW9NMTvkegSw9gDr a8Fjcr3GNdNvzZpirK9ZX8nPb14d4np3lEuuKTbEuzrE9e5EeiL9W4rySVCPlvhKsoDDaJTm A78OnLp1mv+Ca59/Qma1f3Em471NtxJPymAonJGWMrgSGFMG2d+FDO7zr3EVep2Xwc80uBSZ Y7+lDP71jQxFJkW6EzL4FWBBGfwaSMjgCO/izAOeCZnF3gsuxq2UwWZcpxFE26hCjvWnIvzG m8g1ClPjYow2+q7RibUGVqE+rN9G0EgQxAbdP/aOGfOIDfVYLUgbtO/DWr3WgBlsnFj/ajNu mNg8DtJjwzwz2Fi9/tXovZ9V7I2elpu3cf/E5mwCbJhnBhur5cYMNk7Izf+q2GSiM+nlhnlm sLFabo5d8/VQOqybVgZMqoFBFXgEHCyub5jX29ZNoz3AddNoD6Tjumm0B7huGu0B+pGpy/f5 T7oLvc6vm8Zxn+ujUb/T50t7gOumiXSn7IGFwID2wBJQFmiE9/nsA56W7GLvzdmMs3/SZ+CB ZPZX45RTkY6oKb8hbXWz9gB1Vzqsm/YO6kx/yBlQPUjbP5k3D5TKHrD6fVYz2DjxPus53Dux 6QDpsWGeGWyM3mdtQxnrQLQdr5ZjMoiftu2VwH5I4nw6HddNo5+IxPn0WnDK3QHPAc9Mv/Pr pnHezHXTqO+5bhrn01w3TaQ7obs4n14NDDiffhicumua/xrvPv8Sb7X/m17GhY5yUndRhtJh 3bRVwINrg20EUW4AEzT1xbnMcvxMpbustknNYOPEummbce/E5jsgPTbMM4ON1eum/eXQjlA6 rJt2CwRlDjC4HXwxuFZumLcIaankxup3z7XYyLh+FQgh/l4+6zjBxnXT/gUXICYLwfWYMI+Y sA61IG3Q+gVQPyUIndQXvZE2URTUBNKPcxVycn+JGTxQtm3rpi1W8bg7AR7MM4MH753BKTyA v23rpi1V8WhMgAfzzODhtHxAVm1bN+0+FY8vJ8CDeWbwEH1JLx9rITPNoM70F871xXflU3Hu RBBCXH9QnylrENi8bhqvfQpUB/oIBCjiYzLzPgCl0q1G37BGcX5ndYkWGxnnJ9KtlTaumzYX 1zwF4rxcjwnziAlxEvKAqBK0uhX1U4JeVqJItQMPtJ9t66Y1oM6nQHeB9HgwzwwelC8GPR5t SFsH0vcdryy5ZKSz7Tv/nnfyd2lp73ENAs6p0nENghW8XwgX51R+EPveAc/1/pl+59cg4NyJ aw1wTsU1CDin4hoEIt2pORXXIOCcqgCUBTym+Z/x7/N/4K/2D+nHuJApDzSXU/4gylGqNQic ej5EX9BGVW4AUVx/r2IcCan0tx1zqlTYODWnIjacU7FPabHZbBIbq+dU9JWl+vbbie/i38H9 9wMgxKdEhw3zipGWSm7s8COmwsYpPyKxoR9Rj805k9gY+RHXooyu2Ium1tm1ec2qaaj7ahDt oA0gwBTXN8xbD0olN3bYiwIbGdevAiHEbWnWEfaYbWtW0U4kJp8F6TFhHjFhHZy0F1PhEbFx zar5uFfisRikx4N5ZvCI4DgGMbb3hZRxft4T9iLX2aW9mI7r7NJe3AGivfgsOPveAU8kd6bf +XV2aRdyPV3ai1xnl/Yi19kV6U7Zi3uBAe3F/eBZoGn+V3L3+bP7VPvH9WFcyJTT9mKqdXad shc3A5ONIMoN9ZLWB78dPylDRrrKDnsxFTZO2YvEhvaiHhumm8HGyF50WnexH3Kd3ecaCkLH /6PW9m+YAdElQfSzTKSKuBvSRl9AKagV9DKI7z68Dk652+ev8o3Iec3SdXZpazWC6GOokJP7 sGmbp8N6su+grs+BzoCOgABPvI8y7zAoVR+1wzZPhY1Ttjmx6QDpsTmHtMOgVNgY2eZRnN8E 0vujjOSGzz56ch2RBRCQkajzneDjwbXywrwqNc1Yp+MgBNFPhb21FmnsP53B4/uNV8rpsGZV H9R7KWgo6KsgLS7M432lkhWrnxtqsZFxfbYNwiVzlQk2rll1JS5GTIpBekyYR0yIUy1IG7S+ bdRPCXpZiSK1s33HDB6w+21bs2oY6kw82H/0eDDPDB6onxKcwgP427Zm1SjcCfGoAOnxYJ4Z PJyWj1tRVbvWrKpU8WA/1ePBPDN4oH5KsEo+enKsGYo7YV8JgPRjDfO6M9bswvnbQPqxxitL LhnpLLvzz4KSr1n1Rv//qmkIfT505bx3appPNCr8g9y7Q3OL/1IT2Zx+a/58Aff/R9CXQGdB WaBj2VvyAp68/IDnF3lzPVc4vubPedf/1Lw5/Z7QNfJHyvOQE+Vv14xYfl9IpF8+5++ZNauW AasPQV8GnQMRuxbP6bwVnin5V3iuz2dc9E8PrO3+yPeBOBaKdERNv1dMOW4FUZbtlN+31+Qq cptRWKDwe6fnKfL7qzcKbJ/vdeD+tEHglIlEEXcDszr8DoIovy0gyu8WUEx+n/IGPMNzAp7T 3rmeaxxfc41yuqA1X5Hf/G2FIcrvnhcHKPLL9ETyW4q6k3BrkxSmi9OmFPdP+UkkS16cPBt5 xIWyuR5E2XwUFJPNv3tXeOblXOGpzWnx/N3S90bX4RpRUPdlM/lzdvpzGkI3hSiPzSciabdm FTH4KagNdBLENmvI2eI77c27ZC8b0Y7INtX3y3GgD8Q+QLvQCayJMbGOvFQYmvhs78D6tHeL rz7HZynWWvuhezo3JtdT0X4TQbQ5oMeUwPkKv4058eJXlG9kyLkGD9MFT9c1q6iLrgJVg+4C 8Z7KpZbsjzJJPle5ROp9a1YRe67twLYQnG0g2krkQ5dnEIN0WkeM9VkMYps8hh+xNtkz+KNM Uks226NcsnYtCCf6CX1iXA9p4YWX45z9g+mCp+uaVVPQDuwnD4LPAmebLB9Q7JaLSD7X8gGk 3rdmFbFn/2CbCM42EG0l8tOxn7BNImqbiH6yfMCewXIRqdjN9uDvMhzD8deD8VrE8TNtx+4N BY+EuGbVqjVrQ+m4ZlU+cOc4OBScfgzaSTv67czq18/5Nau+f7AlxDWr+C4i5Xb17x4Kcc0q kX65rd4za1blAavpwGkA+Exw2vPX96t0f+Avdl/wn8xiXMgm5TTR/ACnmJJZx2xMPEvk/jd8 lqjuf5NWa1a1ArAS4M1niZUgyuk+/9CCETnW7n/jhD3PuRPXoKVdn47r/RKDEcC4DXysinVD TnPBaW/vW++XGBNrzp3Scb3fRFif9jYX1OdYu95vM9qyEUSfQIWc/Bk598588rHvGe7rFP9u 5c1Bk6SBQ26QyKXoZBSvhovxAqT4QBCjTu1Hk4sOPhEnDQa/GZzni/dYmHcTEsAMn2NZ/R6i FhsZ164CIVzybA/PDM4vM0Sk6/vRcB9RYsJ9MvWYMI+YEKdapVoX/2mf7aF+ShDjU1+gyjEm CmoC6X3zZmVFxrmJ8KiLfbdiICFdx6NExYN7PejxYJ4ZPFA/Jejx2IXUbaCu4nEnzq1XSr4o H278DmHVi0XSAuleSXp//SRpe+QGaQ92nyUPz1B49AffiP3+1PMxnqRndQ23JahDH2BTC0EZ BX6bKjOibzFvLtJY12RyNOfS+5By8Zv+MNg6CoHF/aNCvtqQtg6kx9MKP04Q5ZaA6MdB9ZXA fRL3fPc5ZS/So/kv2O4rVy8bZ0KeiIuIA9P4u1GfQkUXAedj4E3grPfJQNPApcHhg8TxtB1F HNmm7MVyHOgD8brs1/WgCIi4J9uX5NijY8Ot8w4oe5G6bn5B2Ys0b/+Lyl6kTE9kd5eiTBKq NUlhujjvR9Qdt5fSR869SO/BgdyL9H7wLJxzR/D9ge3BikENwbpBjIvyiEt3bepmlN8IIi4V cvLxkHL0iH+vbjzsiOt83qcyHnZjL9IOlDEQxHYrAon7ZNmzQHNAYfyoAy7ci/QOcPwBhYt7 kfI7cR5fy3RN0Op+o/FwLc4hJvr+2V1suvvOmBlsuN8oseFepHpsmGcGG6N3xtqAy7oE2Nil u7gXKX043It096GfpJ3u4l6kq4E39yJdr8pde1AuCpX9ukjIrhW6i/LYqOJuJIfci3TK3S/q +ujFcRfVhC6cKUmij75WbLgDWgGO94Fwa52yWZ/AhfitOfciJT48X/RR5kWRAGbYR61+r9MM Nt3to7zNVPqL+40SG+5FqseGeWawMeqju1CHbSC9/upOHz106JDhfmjjFz2h7CN1NLhb4R9P 3aXsJ/XMI7tt77OoG2GPB9HvEtkbQRwlbORPAmvqSo6vp4e3D5ADUwqxp1Th/YFbC0UZVvTd epQfARnZHdz37It/3qXsJ1X71z3KflLfWrlH2U+K6Xq7g+1RjjJF36T9QYL0JLVBRiK3CKT0 RXCBm7hXpieyJbwodDbyiB33Q7sFB9Jmm6NitzNQXLg1sLJwfKCxkHFRnhW2yTpcMwqKYSe5 ZMSrQLRvwaSf8x/C+iNfnIwqKTpFcKaL4xBV5Jf3UKKm8zgG7jnV6Dqq7DklvfqKgnW6PDdj m3LPqbXAmntObQZnvVeUbS9ylV3R654BcM8pYs09p37/QvpiPRcgb1KxdgHr5WVFlmLdjDZs BFGuK+TkNjfXB0kHH9RU1JX+ljpwvX+BeT3hg9JiAwgT+lwqbfRBzcU1iclt4HpMmGfG54L6 KUHozL5Qd5yrRkFNIP0YblZWZJxLPYkQn5+hqmw/rp1iiw+qAeUTj7vA9XgwzwwelC8GPR67 kLYN1FU87sS59SCEOB5u/EgHH9RNqAd9UIvB9T4o5v1/8EFxDRH6oPhtcTr6oFYAZ/qg+G2x 8EEd8DQNnOl33gfFb4jpa+I3jfRB8dti+qBEut4WRNW7bQuiDCWIfgcYUtqCWTiIfiofSPip pvnfH7jPXzGo2l83iHFRngcqLZFticuY8uVRJ5odMylrl/upLvZ72k9OfX/M+cVGXE/vi1mF NDO+GDu+P06FjVPfHxOb7yTAZrNJbNLt+2P6qfjOQDr6qVqBKX0NfGdA+Kn2+eWiETk946fi 98fp4Kd6B7jQF3NGxQdRaKSYL5l5ZnwxVvupzGDjhJ/qHO6f2NDvrPdTMc8MNunkp+I3UPRT 8Rso+qnI6afiN1Dp6KfiNyS0o78ELvxUx7LbBwQ8UwoDntzCuR7n/VT8hoT+KH4DRT8VvyGh n0qk622TnvJTLQNm9FN9GVz4qVo8xYUrPCsLr/A0FjJupW2yDteJguz0U/FdKfpO+B5POvqp iAH9VG3gwk/VkLO96LS39/mpiDGx5rtS6ein0mIt/FSnvduL6nOs9VN9H23J9kzlp3r6oCfM bw+4F1Qjjl8IQojPtbPxYwa+tl6INz5KpGpJ2r17ktR2fpKUO1F5/hTdsCb2HKr46djv3b+M 8SXvxdKTvPlRgHJ9IIid6edTjTh2JCYBPIfP7/zgjItxn3l5+Mk61zJdE8Qz5DlI095PLn5j jhOnLPUcoWOEX+ffkE5MO+PHeGDH1Z3AtqbHseUzLOL5hwTYMq9z2NYo79TYhS33S+pNcrsI uBLbVpAfpJVb5nUO22pbsV3y6pKQeWx7Xm7PqXheBVD12DKvc9ial9soym4CdUYn0Mdx58cn lOf8Ms6tAiHE9S3lolySjo6arGjZJNqza+/NzULZB0E7cZEfge8H5/WE/mTes2paMv0ZwTGo nxLK8J86XOjIKOJ24LEALuRrbcLjMOpMPI6C6/Fgnhk8UD8lOIXHKEm+/Sab8Pgp7oR4HAPX 48E8M3iMUtC4/FlAFOmdlQ++u9aT/eUBjHvEIwqux4N5ZvCwsr+YweN2G/vLKhWPBxPgwTwz eKB+SrCiv5jBw87+0qLi8fUEeDDPDB7J+stQoOQH6ccX6uaFIBSv0I14YYayKX5Pwe/n8HuU tBtHiHDxewZI82SRmowPRwZ1O+1m+vC1dXHJsTwkK2PrAEYQ/CDG/08AAAAA//8DAFBLAwQK AAAAAAAAACEA26+ii0MXAABDFwAAFQAAAHdvcmQvbWVkaWEvaW1hZ2UxLnBuZ4lQTkcNChoK AAAADUlIRFIAAABrAAAAeAgDAAAAwiP8CwAAAwBQTFRFosTZh5XE7PHyirbSxNbfvNPd3Obp 1eHlmISnZI68rMrakbrVGzeP+vr6pbLP6meF8sXQKESWlqPJ5FR2daXIsc3bd4m78fP4OFOe aXy09PX2xtngrWiOw8vih6PGzd3iapfB77HA0N7kncHZSmCnuNLj6O3vWW6t5Ovs4Ojq7ZGn hLPP5O703ufq6+/ws73Y4ursVX605CZS8p+y2OPm09jpyypXyNrh8/T1wNbfusza3Q0959fe ttDc7/Lz5uvtpLfQlr3X9vf45z9mpAxL4xBA++DmXXWvmq/LLkyaXIW3Q1qhOV2is8bXytTf 6n6XTnWv1uTqvkZwYxxo4uXxmb/YRGKm3+vyfpO+z5mvyKy9rMPWvMfaR26rxoCdy9zj4+bt P2WnUWqpz+Dq2BhHkq/Nzt7mvTdlu8XV7+Pn2d/qssDVydzlyt7rqb3Snq3Mx9zpz9rj8fPz p8fa/fDz0dfnpbDT/e/yp8nd4+zvYFeY4QAzf7HODiuJ////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzblzxAAAAIB0 Uk5T//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////wA4BUtnAAAAAWJLR0R/SL9x5QAAAAxjbVBQSkNtcDA3 MTIAAAADSABzvAAAE01JREFUaEO9mu1D2tgSxgMIVCBqEMOJyItAiYggKi5SCyK9NYZEKl21 3K2sK760V11tcdfKGsK/fuckARLEtveDd7BCA/LLMzNnzpyTEB3Vtia0F8/4RGjfTa5sPSNF /eouq/P6HfncsB6r825WfmZYn7X15tv/jSW/m3xmL/Z1dSberjyvMB1LHn/7vLmoY3W+PTyv F/WszruHlefMRQNra/lZvWhgyfMPb/56vvwwsDpbpw/zz+dFIwsi9vB8RXiA9W35O14kSW/K /MceWCrllUv/s7MHWPLKw8P4MC9ubPhvTAzLcizLNvBvmr7zX/xvuAFWB4Q9DBRhkrxYrEUF lja5i4ef/ZWvlcPPl2Numm4I0Zr/b/KnK9sgqzP78LCsLx+pCzfLs6bL1Y2Yudk0m82xWCyF f1rxTIVuCwJjupj+OX2PWN/ePOjKx94iy7voynSpAN8PtjEHlk7HwZI2WzzOsYeBRpQ7LPwM 7RFLBmFa4pf2TFGqza42mypIpQFOgSXTrZjZJpgK9lfgYdPGj135iNUhQdhbnPirpijDIHep tLbWXGs2m/DUbBYKqRSmtWIx/1jAFKi5XrVsSft2Q3Dv/UjbY1ZnYh1C9i3lRkzlUhi7qNyY ajQHBqlXc4/5v2bM082mPRBFcCoMS1EN+jK8kCk2kHv6+3VgCEseBy9O1tlK7LOLYoUoy9SA USwqTMi9BlsrFgV2LAPykvEwINGByZcMbgsN/3cdOYTV2XoLsJmPtOBquC8rf5AyPEokGLxo xiuf3bTQbtOX9rlUy2ZLbwv2EZOATMGqj0a17zlyGKuJhT38Y6KFObI0DSECg1A1C/hlc7pU KgimQzoqcDfZ1Jwt06i1bMFtdHBdDX8UhMrT0oawyJrrX8Ba3qq7S6mUWeGsKYZTo2BOTV8L G6lm7NDUQFzRZi6iSiYMoqja0clRjV98sng9ZsW4NvUeC/sUrTZVFGCmwbRENJM03YTUNzfj n2kkBL6yNVs4XG1di0wueDKGTN4nEvIR60JoMyNzkPcPD+9Js4KaVkgKDSszy5y7iUd1Oj0X s99EBQGFW8HL7QDXRmyjgdqN2PB8HGRVeOoa6s8s5P3D+koJUFhTSTUNRtK1ZiymDOl0rDR3 g9rRhqDkK08FzgLbrDC8jAywKlRjNTUXb5mV9FifKJl1qC6MdLPTSrmKmdM7Aa5xgNouzmoP np9YBRqerJww1I1G1t88HW/F4+l0+jXO+4fl16SqCmc8SSqwtcLaKgqbUwXz3CUtINZ0/TUs 0A0UOAlnz3eowFXOelUeqszAuuBrsXgSWHNz5nnMeniTKvVRGqxZKLG0nDqkDwRmLJxMpW1z NFd1841Le/YkgKw5ay7HCrHHCaJnxQQmHbcprFZKTY+HcRwnVVVXWLNAVpCJRUwxbYbKYctk Mn60kxxhqJovOCLUzq3WfJ5jH080OhbZQBmbTWXNbXgnFC8+vCtpNUNWWKXpNZK011xt90Wz OQf13gYsu42lbfbqNhI+VgNCLgcsh2B6NKj7LJl2HcYBloRwzc21FtT0gPlFUSSDqTD5gkbc IsuspTAKWACzjSFfOFjNMVTglXANrKl8hFoczPw+67BNp+GvNFYsNV3E1QNsRcciFZKfJDOI SaV6rMxXYawazB6dBHhO2PYBayof4FcHQtZjXVBUBZ9h14epwlcXHmSQ+bNYkSJLLpgQVymR UKcqAptMKbrAh/YWw9mD2WzWvnPQPrvCLMdLBg1kfpdFMi4mbe+zYjHzRuO9GrLTCczBuEXU 8Msl6DpSqUKSQ4fmOegEMCtZFLLA8vmCOy6q6Mvnpxz3DrFmFNZlFQU0ZuuyPpgXoIkhA0uT qhffKjD5Dw4VSXKtCeU3lYoVUjWetpvjCsseFophhbUtMNSZT2Gduf42wDRWAZkOKnaN1Xq9 MjHx+j//+fzPb9DBqcpA1B2iN2RoCHCpxw3IRvOwgUyZmA2zbBxTBR8Gc4g+qfG13JTj9vZ+ NGqo+SpLrnHbDfgL7ENbMp1ZXj9dBls/VZ2IlS1w6LNMTsP0r7E25mB4jUVR7VUmHa/a3AfV c/vJtdDI+bIBV80KLIJAd3phKmuPtwaYMGYBLB5fUIuG3k7/oVOyVnwVF0LtheKbSo6xqFG7 2am84q9fbXMUk/PlrL4AFcoD6j5kKB8KS2aYFs2ALkUYjGWb5js9bQX7T5stsQsBhZvEudgr NydEEXLx0JcWj0ZyVrAAFZgiwA7cOmEKa4/faTE0druWiAvQ1j+yd6WSMi9r0VK6RJyGybTt q/XzK4a15s6DI1A1oGxYa66Ag4gQHqRrQDBLhtJpY+gqOFGDfbCp1dBo4wWYzzAKZEG01JEM brdn7GE7BCx75PNprHx+lLfcRiL7x3f96oFZe+jyqFrj4A/6wpTJctAmX8NMraF6spSMDwft H9FOjwVDeWoX7RORSEjol0VgyXdsMFs1ceGwAlPKb3JBq4ZG3PIEdDtKvivRUlyosU5eoesj VRaUDYfDQaA6Edl3osVexIBljp6Fs3Z3Q2NhWDzeej0kPaBezZu9C9r8b0AFj+yNQBCzcJUH 1u29kxolNvfLjJ61ikZgEO4gqwJT0h7mlSF5r2icfG1Wlg8GVeFg8KjKMMERNVzgQhhd9zVK ijgl1CvBoKtG232+bFDYBrcrEVOLfUsrUINBW15ZWFAXKn0PhoNHWXuNVXRhWcCChL/fRZtO J99zItEho9sQ0+wJFBmdF5PxDxOnQ9JDlaap6gYLo7LhwAEMLk0WZkUiTn4JWFy33BMdv5Cz Qafi/XpYaja9sPrxxjMxL575J1aG2/wEWUolk2atP/UWml6z+SR7jZTRlbcttFqtD4qNjFUJ 0ZXSIkZ0ipxvAc+6fduwN40Hhvxv2mYrGQ5Xfa/QDtQna95rOO44bnerPSFzgVxMduO1vfrw y2l7QX+g+0b/mXXLa5hVw/sC+MFW5OqIDxGYNVUie8cbF/J93dWdxoi9aHFkQWbbPbuR0+GC /kD/rd6rBrAy0zLqHVjELOEsi1uNEsn3jvvlgChyXR+uNqasCzIzyNIdGMpqZoAFyzDN7uRM biTqzuKEL5H944dyw1VGWukg/AdWa0wv4+4ndLFyM2M36rKP+A7c0NXkHSWyr9cvcy5J9KvC CBPjs7aMuuLBgswNUdM/JKgsvS471qWx9Lpol1S/0Vh0yJdvGXXFj8zyDcsyHDwYpu/8NmKU IxxzIxfsg7pyuWgANzX3Rl2NdrlMa6xGIAcsQ7wwC5bG+Af+mfpyTEpHqhxXWAZdVmDloGTc 6uPll+m6WDZprOiZdWpAly04579LwToPmqmSTOtZa4UL902MNBfS4bAxXicay3HrNcSL8PBL rJocBCrmgWXQZTs6QrQtiItjOCbX9Ky4/esNrPntNqidawZdJ1Yr6MKV0JiHhCQeN5QqdUEg YuqRLrtJCMOX4VIcM+qK2+3psBtoIzb7mmF8neSBZYW2kDDGi5CW+KjSCCxiliNu1JUcQW57 ELPC4ZRR1wfcAFXt7gPEfDTG6zxvPQhYYd4ivIbxRUghV0PZaFwFlgNYurpxJ5trgi8IBqjg gK7Z6gk+A1sYWjW/Qdd5Po+28bwVMeqKSJJLUDc1CRRx3CaNurIoYM8eKTRgGeL1ZvxPgAWD 59Xwq6QhXudTU3xx6hZY00ZdHgvFayzqzHE7oIsRRmA+yh4dHQWPNozxevMwWTkJwjvwAa8x XrkickBqPI5XQkQay1WbIgZ0RVEu6AMY4LKtAV2whP58gs8k6/MadF0HaP7sLOCpsXu644cy 4UnUu6x2GbMM8YJFtxWmagWXHtQFmwO//YlXJL6CQRctUpQA2ypifc84viRgqQ0pQR3fRgZ0 XeYEAZRhmO+xLlhI/PvPK4WlrxtXU9xuxFncJ6BG6esh6FqKql0AIbicg7qqvhFQhmE+3xBd 0HGM+658I8Z4fclHRyFYRMQ5UDekRK9uMO0QUTXmod3qgw2Ka+iuMMuYh1q7M/n5C8zmUd38 lSVQ4Baaz31gGXRJUt2k9tkE7apHqsZ4QWnzXXH8WHjEN2LURcI1ENWWf/uin2FpeeFMbeCd 9/KFq3cOF6RTSux26/wd4qUBXVDarCNXNBWAnjlu1JX5vQtb//2Dbgpw7cmXx5uR/U3nvVcO 9FBUrGSB3OjOXxficf2DUReUG7ArN0WP+JLGPLT7fu8tKsZlf78scyXZfAINdlKWD/tHWfmD JElCd15ejYaol8Z4nU8pMN81OthZMOo6yX35rQs73dIld1s4VFu1PVPfg223/FKSPLy2XUR4 Gx7BbdR1NJWH1Vre6stz/KJR1zlsbHUX7A/vZLe+UxBo942JpXSHEElaJEu50e2j5NquZ2yg HkKtwbh8LlcLGHXBvpb1y7W2hFne+kFrtyh/kaSEqKUG3A+weOD806gre+vANEVdxqjrCJ+C dUdbVozLe3oZg+2QSTZDZnj6fS+sKj0DeegDlkqbmrIZdV1h1lTeMaOm44q813iq4XK5ZRIm lMQx1V0yw5qILVdl3V/cyDkCpgaMA6sadWUxH84jr6bjOmwO3OgaLR2XWZVLBKBG20x3QwVY d+gE9vNclGZ3wCIw7V5lmXrvwJn6tFNw3P9bXTGNf5NLhwyvyz3gueBCjizbNiHfJb69qKUG vn9jgX9pXIjkIioMxN1WB96CbSbHPZwHcX/ziwI7nd+Cj1zcwQXGKFiDo91+aPnkDw5MAg/2 dx2AVeIC3gXz+aoX73hd7JnNLyMYhu2W+ALrMVhfwU/Sv9okc8op4EUjcX+tXDGAsj85PzGw arK9hEgpKFSne5sOeM+hgqSEc5TybDo3nWKI2N+PgGk0VR+WSIzyYi0yBaVcMfjEx5nusF5/ +2Z8/k+8uqt+yTn2EwpISkjHvAdpRQPXXvjnFcqJhKXOS05nQgxFNjc391VeD6hodERonl86 u72Hcq6ZpkzV98sLqBHw6JolxCOpfNDfalP2iK75hJRIiHwCs/adTh3NwLuPeA6og5CFuCfg XLZffOoWYvV5/ZOpB5Is0q6rLiX4MeO+TaeERgEmiaIlgTALwzb3QV1EldcziNJZGfHHocS+ e2bI0n39fUD1XkJaoviQJVHWbduo9xHJd7ziXl6UxJDTYgGaysPOHLDIfUTi0K+/9Mq9Udvp TACiFapT/Ch8YQLqaTfju/cskRAxgHkQQpgFNB2vz1TYTvfMsI2xHvJ0hhOp4xDWZimL+k16 bV90kYKzwG5sh5yQJ6op8gy26X7x/ilFfX3rv9Ysairyh31VvXuxZLZuUd1IgZd7tEHc5kx3 U9bouYH/nb7AXwYTMjdkvxcWLFQInwqMc2oUTgrjuvIUjyoPQL94ajNHJ+s9DhkuhbzxSml3 z1wO4PSAyaZcpnaxPzFOJ1Bzq8V5ZhhTj+Wtv38BkVJ95DZe5ehddyg1sBct9bozRIkKDH9c BapM5RmO9KrFED+uvzdpRQNc1Bi4etO/nrJHlWHC3j2GdBT5UcXhfVM5mpnUqvvYTmde9D5k KfPdfShdnddeyn4IGWQplrOEh7yRpgdLw6T98h5qVM8sIcqQg0ov2k9K2c17oIZ5AGLx8CDt aZo0UJ7WP828MJxcwsMHHl2M1V/XK9EgilfzUdql6p4BRxqlGRLyxeCJUf2ppKfGcL3Syxxb xCUtL0IitfQ9RwYMCTljiK6EmCGX6g0s2GYWl0RNTSIxSqEy1OunzPKPviZ+Uquumr5ir8cY Uje6h7wsT/VmIFysYQZ4ImyWJWpUX+tPuzkIA4v+ievLHbnAtJec/Wzy7FJiGZfRQUskllyh RMKky8h11Y8JDzVUlSEPVW0lGipi3x0WzxJMxp7B0CcSuxTMeWCm931P/gIDGTK59sSdDsZ4 KbA7F7QEfR3gSQRzhG4sK50E1c3ShKmfJKcz0i7vfuoOjsesDlypPjaku0UKHVP8bkiCMqWc Ax5+eBh2c0Gn7V//PBrCw3O+e/SCGUiJhMVTPubR7ijgIHqjA2UlIQW0y6jQL7578kbQIbqw H8dAmjEjLIATeUrc9XjqVNmJJWrlXCnMUu2Tdjn6YXniCdpwFsxnNL87MLYSkDKhJbHtaqOl 0VEPHhpQ/KFP84TKdVGkXL++0WbSyYmhd0w+xeqQfhZPZMZsT1hCx3y5vCtCY8KDiaIIvxEv 1ndFnrsiZ8dV2vJQRz7J6sheuKS75MFqujmQ8BzjKonVeEBNaHRpqRwKgcLQrsguluQOSU68 W1bGALT5+pKhvH6ahRviQ04QoffC6uAXZGM/ito8ikM1KoqMv1cptmYnlbK8PDtI+y4LaH/D JujuKMTGA6OsDqNMN/AgJyTPaJ2Pmvb0o5f8tqWIe/tmljTMKz9ggTiyYooeiHwbogfdja4n kELlY/EgaroYcgsKiMNN5OSs/n7yH7MAZ14t0qzIi8e75fJoCOJUXto9hoxg3TcXT91UtrU1 r9wXN2u4NvoohsMOwM0ph3DHKM00otEDlmZMd4cX3pL8vXvlSHJrHkZBfwD8lK6fOpuhH9qC vHw7PqF68plZnc5ff82OL4/P/gVZ8uwsLAgyZR6y5P/CAnVbs7N//Re8cRV0pEeJrQAAAABJ RU5ErkJgglBLAwQUAAYACAAAACEABDhASaMbAAAImwAAFQAAAHdvcmQvbWVkaWEvaW1hZ2U0 LmVtZtRdDXgU1bmebLKZCQYyhAQihJBACBH5iddUuRRwkk0RMfKsBAnBiFChUIUaEBUxvSxY /iyUQPBCLShetEZEvVHaXEELVbFi689FL1dvtUX5qeIPtIj2aXnIfd/ZOcswZGcn2d1hPU/e fGfOOTNzzjvf+eY7P5kkSZI0G6AkluHXDA8iRtjdT5KyhklS/veuG80Syi8kaUCKJOHn3NBJ krZ4JWkSzr2eFzKFPQPSpFmFXgkXkAYB+QAud2mSliTlIq4CHnXPH3naVAMs+xrwAsCyJZpH Lxe8b+CqPlqKlI48hjzNG4r31lBfpCkAmzEdvxRN8miIlwK8D4T0Jn8hrHnpzqtYzgymi3KI tipaUrKoN9NZluG6t74uP5azr4yy+cWcCtAjZaNNKvIEPwWIsy7fB1hftrHQgCQFRiJqhLNx Xv9mALTr5SkZhGRqRjDpvN/9kSLuI+J4LIFqpPO+C4EewI8BPmfeq0VuTGqRS4pEeRnlRRzZ AVN9y3BshEAozmsUA+K+fHargADAZxcv/ufdt9RH/inD8W+qu+tcp+Fhk+vOkILrZrUxqVn9 9nFNHZ/pLSgvfGCJb8SyynIqplXXLyTX1OsiQEa9vgMZ1Oulnir18mShy7HQ61pc2w8E9Top eQTiJQDtQgokw5vXLvGt+2BUOfUyd+q48l7KEt/ipppykS4lJS3O0pICKsoa57Q64W4AyucA aOI5QbSP6d0A0Q9FuoKuOBHpg4AUFBrKMpBX8hgYq572NKvDk8vUmcmMi/PIV1vXwymObIKb doC66atIMnQzaXE0ukndEbZWSCc2l+cJ7rzgqBrHfK6LAOom7cB3IFmuWV3qyVZio5u8Hrl2 ops3TPHousj+TN08cSBJ11WR3lHdFO12ooP3oq7UwfsAoYNFyszkFnl4cp5y2sO4uF4sdHA7 7rMFYJ8dqAWfSQ6OJWlPuS6MuHifK5ontQRpfHa6H/CvXUbpRYxfXsgyabx0DX5XIn6F5gmM gRwRzG8lBwSfyziUkybVjZQ2fj1S+n3fUbqUAlcFi/L32XgmjtIBnsv6Mc7QHWCcabiaVIcC vPbJ1tZWiFBo4IkIspSCms2TfihN0327YGp7f2dKv5ngrVgw2qPk4tR8YIwiSQ0/a21dhvue TpWkr0AE0wjWJ+dHSdLSpWoFotLGI5nSE1MmLAh85VHYIFatGAic8ih1RzMl7WqPwmsfRLlb J3sreiOvH7AF+a8gjSFncMWEfxakaZ/jeO68yQvykbYd524E1Kc9yguQY4AVNd4KFXmLklE/ HBOSNHkBqqWHvT+fvGBRj6CfyYROwEunkytmDC0oKt31fCrrWGxw1wRJrqffpbttof7M9k0A JgGLgRxgHTAA0E8N7Co7NGxXGfOouyxfCZgDaNODH4nUC9aDgeV5z86gh/14BVAPUF8v1c7q wUDEqZO8dzjdtdPFEr6p9vxE18FA5faodVHU28zNetSM9dsCWLlhnhNuWE/0ez2Ie0TDzdDt N+l+oh03se6not5mbg6hReTmK8DKDfOccBNrvXHCjRt6843BTTI6k5Ub5jnhJtZ6s2/IT33L Zy8tt9Ob0VKVJHl7BPvSkTlx6VP9wUkZOCiF9ENCwFIE7Q3zxuEwkr1hPRWehyB0U/SpjUhb BVjtTTzHbTdO3FlOf21v97cxlkhKisZfg9nvkL/G8wQXXjBajWPaV/prNwL0126FJLfN6jve bGVxqigvo7yIIzvA8whEy3RhifMaxQDtPO/bHn/tk8cPlNM3+VXyf+v+2omyfeX015julr82 HXW+D5gNpABFyq9TW+SVqXnKtamMCy7ISzfks53UU5GOqCOOyEs9UAdE8tdouz6+eFPk/vne mqD/9Ye8uPTPw6jrdcBJoBZgu0X/ZN5kIJr+uQLnkxNr/xyohfcHnHBzmXSZJD3x4yAn034Z F25Ood7kho6qlRvmOeGG9YRe6UHo04WyXeyHBOdBPrg61ZdotmshWCI4D0K9od61yC1ylTpD Edy5Zbs43zH3Q4+P8yATfpPq4zzInIY0n0h3w3ZxvmMJOOB8x/2QtF1j1SFKszpbKVN/rjBu 5sUt20Udenfde7a2yw2fdDH4uA1YB1BvQFPIdjFvARDJdsXaJ3XCTQltlwtjGXLzEGDlZr1D bljPcLarI3b9s91bfSN/96yt3vjpLfr3B9953jFxsetc45kEDr4PORMSIqQ3zJuBw0h6w3qm 8TwE0QeFXQ8gbT7QnneemRsN55YCCKH5GNZxuCTNbbRlRJIyUS4dYPkcIw5xzjyMqC/bOMHA LTiBnEyHtHLCPHLCa1YC5mCeF0D99CCuH28+4G9d/nic+Jhp8DGnDT6Y54QP+oMMbvEB/rfu jxMftxt81LXBB/Oc8DFcevhhN/mArs44Gic+7jD4uKcNPpjnhA/Rl6z60RHbyrH+3q89Prvx fhVHboeN+dzuvWyZ6Ygdof0YAywBqoG1AKgI2VbmrQFod0TbEdWD2Y6wnrG0rWZuNNytLds6 WJK+nmvLSMdtaw3uSU44LrdywjxyQp7sOEH99GDVlQBS2/uuccIHnt8TDXHiYwrqTD5uBax8 MM8JH9VScP3AysdGnL8KsL57FU3yaEjns9fXRSDfBBii3Ufxxj8KfRxTef44NCHHVFvRRo6p noVk32uR/Z2q1DOdBHcyeqiII9vRXEcxCqYDyQDfc7WAHyDv3HMyAvESwLq2vKFukD6mWnh9 iT6maux3uT6mYrpbY6rtqBfHVDsgU4Cx6mudmtXUi8rUyy9iXHBBXtwcUzV8kB3Zfov5oH1F tr0zk20EaFdyjDiErR84Cfnsl+sB9kvqDc8X80HMewSgDlUC5uDUfq/ASfWAtX8O1MLPB3FM FYkbN+aDGlFvcrMZsHLDPCfcJNJ8EOc2Rl/p83Eu+94e4xLOdi0Cp78FOJf9NiT1rlktTc9W Pk4391ERR3bcbBfnrNOnXu+jLp5cPc7HvQfqU2N9It0N23UvGvg6cB+wH6DtKlK6d26RP03P U55MZ1xw4abt4nxt2sWltrZLX2sStiuOc9nPgZOTwEsA1CZkuw4jugeIZLvs1po6YruccOOG 7TqFtpObVsDKDfP2AJG4sbNdHeGGfujuO6bZ6o0+Ztn/cHA+6NUhcXnnjUXbDwL0xY8DZr1h 3hdAJG7iMWYR3Gi4fymAcM58EMYE7yyxZaTjYxaOVQ4CNwFWTphHTsiTnR+A+ulB2KTO6I30 FQPAfKA9PoBZVzSc2xYffmxveTBOfEzFPQ8CMwErH1OR5oQPf5j5j404fxVg5SOeY5ZDuxbr Y5Yzly5PuPf+QnDhgXJxzKIC7Hst8jC1Sj2qCl2SoUYijuy4vfe53rPvrqX6mGX4zOX6mOXq t1foYxamu/He5zpQJ4BjlkwgBQ0eqz6jNqtfqGVqr66MCy7ISzfkpwMoKol0RB1xxP5J/7wO oD5G8svvr5kf2X6L934cxyx8568FqDdst3nMwoRo7HdH3m30EyNx48Z7vxFUkJvNgJUb5jnh xu6977bt4pgl//8afM9NyfTN2PxAwtmuBlCaD33jmGWwoXfNam5mUdqOTNEXY2G7nPZR+p+e a1fa9lG3fPOu4IO6SH7wE+qjhxHNM7iqZLopmOcV4uGbR+LGjT56Cu0lN/TNrdwwzwk3dn00 gGu019/ieiT/LoHrCRrOb8vfGicFHlgeJ39rGvgYgPvOgrwCEiKkL8xjfZhmpy/jwswRd8Se P1rXW/tbwUGdjzG47wgAIeSP8/3CNWFpx87gWOXKEbbMZKJ8OsA25BhxiIjzcxehzO1ALvBv AM8X7zrm1QOR3nWsZyzXV8zcaLh/W7oyHFtYVtsy0vGxSm/ck5zkAVZOmEdOIukK6qcHYaM7 g9WOjlWc8IFrVz4SJz4K0BLywf5j5YN5Tvhg2xnc4gP8v/CHOPFxCdpBPgYCVj6Y54QPt/Vj PKp6ME58DDb4YD+18sE8J3ygfnqIlX5cyHdNLlrCvtIPsL5rmOfsXTMPJc/vL01I2wTEdmzf qv9d9whctwQwr7Ed6PZ++fRXO/l6Tz5cvuSGTF2eXN3FV5P3WfnEHt3i7i+3oj7mIPQjGYki 7oVtrcbxIOA2YCVwN/AAkALsS31K6ScXpfWTP1Vq5H9JE+fJOE/EUczReLYYBdMB3p82rRbw A3we4dYpv/b8tfzjtzN8Q7Tj+rrT/uJD5YP+meUT6eeP+VtbxX34nik0gCqORNQIZ+N8P1Pf +N5neQbBm2gf07sBrDvjIl3BRSfimNzNBdYA9wD/DpC7lfIZZaE8Ja2n7E9jXJxH7tq6Hk5x xCO52wQ0AEHuJI+GOPtG+9fT7fX3Q88Pdb3959o6Xc5+fbauv29VzU1I/f0LOLgbOAkE9Xdt l35yp4x+8htdauTuGeZnIOIo6oh3oVft1d8bO/9I19+0i+f7qL+PXXmHrr9Mb0t/neisqLtT 3fwSjaRunjJ4WSl/1GWhXJ7RUy7NYFxcLxa6uYqEAtHrZvhvZnANetDBRt+867r4dj2+Qecx kf72hxwU4eFshLwMknZmSlp95hHlVEznHtzgmhyTa/8L2b5fbPh2cH1Eqc+sTTsZU66b8Axp d2Ol12NwrREAbbYXkoHjFf591v6d9+p/p0X55WuecqYLyXzYjST2/UTR+RLUhfXpA5QBtwJs U7G0MvV4MpHuKZaIlef8jZewOyjaIRvs1jPhd2H4LITkMxDPijL43ZjEfCYzQS6fCb8dE3wm JUXHk4mVqXwexVJJTL7ZI96LbjwTzolJT2wtn376tyHJ/sF0IZmfiP1kNDoK+wm/kTUBks9k QVaeV8sh0j0Lsog8r+gbfCeLOIombD8h99/sPeDjMxGSz0A8K5GfqM/ED3L5TJ4Bgs/k/Z5a DpHn5fNYkPV+T/EcYvFM3Hh3r81c7Xvl/vXli5eu8G14akvC/Y10BrjmezAXcjwk/aStXR9L 6do1Nab6X4vr+gG7seaju1b6+i57rJxry9TbJX9a7qupfrBcpJ/vq0tRjzVRJT0IvQINEcea XVDoOpTLgqyC5DhnWNfB3i/UPO9p9Z0UxsX1YuHP1+P6dQC5G6iF3xvKfSGPb/4P2/Wt0N89 fNBjpMS/e6A0fbvGHM/EPdMBcpJjxCEizstTn0bgpGrIayF5vpiXZ941SKCeVTLdFMzrW/HY QyS40XDP0uB9Q2sWrCPm+/h3DzaMdHxevgbXJyfcL2TlhHnkhHWw4wT104PQrc5glXMRAWA+ QP24VAs+MxxKTnUFp7TJB54f/+4hLnxMwT3JB/1UKx/Mc8IH9YvBykcT0jYBHeVjFs6tBRBC +uHFgQ9fTZghTcMXmaTP8SWCR/yjpCexC4+yYpwuA0//LHj83V8HZZie1TE9mo06XANUgreZ kDcaOiP6FvNqkMa6htOjScgztUP/dhH9RtkAxHl8bkTaKsDKp6JJHg3p7Evtn/cKP7fA/SJP Pvycvidrb8bzcZ/nQvXPCUKfyIuIg9PQd0UWIn0GeOaerPkAbVmLPL97ldq3hygPPqP2GamD foC8h5uf5Z6shskt+p4sz7XP63uyuuzYqe/JYnpb78xCXJNAFWH7RTgbZ3tEO9C8iO9D7snC J8P0PVl3QabgnLHq592b1YE9ytTqHoyL65GXbshPB3htkY6oI7+a9q4eqAPIy0At/PuQerRa 3R75fejCnqxqNHYt6vwDSLZb9NkliE5HAjmvZLopOH0frsA55MTaP6Plxo39Ho2oN7nZDGnl hnlOuLHb7+G27eKeLI6/uCdr2+5XE852NYDTJeCbe7LWGHrXrGo5RWnv5Yi+GAvb5bSPck/W 6Dk7bfuoW3uy+LfKJw1+EA310cOMGlzZ9dF47MmKxI0bffQU2k9uuC5H3TFzwzwn3Nj10SZc YxNgtV/R+Be7d++2XRe+YsYv9fW0vYO26fLMmCZ9Xe2Z1dvi3mdRN7T2bBD9LhlJIu4FrdU4 HgRwXZg+8t2QtJV8v+5LfSOrnzw6G2tr2TXy+GxxXiz6bi2u7wfs/A6u/955rMnHdeHKE0/q 62oPLnpSX1djutXv4PMoxjXTAeoP/Q8CzQzrgwxAbg6g6xuk4E20lendAHFNka7gohORTu7m Atej4D2QkyDJ3Uo5L3uhvCi7p1yXzbg4j9y1dT2c4tg3WcXCQJA7yaMhXgrE0j/m2ludZ6++ 9ia9/prOdaKsQ/CZkoMV4Hoj5HpI+jZT0h7JOaL0vNjMtYgj2xG/Qn/YT+gHusE1197INdfe /vx8YnPdaHB9RHkkpzYtJ6ZcPwq++Typ1wO18D43vwfJ9Rjula1D+ekAQmgcnYqDcdiBNh0j 6XyuimzbFtwj2im4RzSwdmlwp1feU7oMbHs3KGd/YrsDLBPXTQdAgeO5qjqUnWGc0wCpGnHh mzOvC8A6VwLmIHzzSUg0t6cTjmFHQkgxThK6LuZs/hPp5NT6zrPjlns/nHNbfsG5PYX28Xn0 wS/ViAtumdc+bsv1uQon3Dbh2puA9nDLb8S+WPy27ofOwrm1AEJIb704MM2bcP6HXwLn/A8l 538g9fkfHnP+hzLm8z+9weXDwHeBpwH84CbBb8gybzvAutrpq6kdCTn/wzWTko/f9XHN5Mix /427P0YKzaE/DtKBtvyxQqRngGN+XzwXeBbg+21r1809u3Y9E9P1KeqgHwj6Em1/R4RrI3LB +z6umex+4j0f10xuuOGAT6Rb/TBcLmo/DNfQg+AJFET0w7hmQt3MAp4DaBeHde3f6wu1e6/T 6u97Mi6u923xwzjWHzf3A32s31j6UcL5YQ3guAVcc6z/CkA9bVbX9CpKG5Br5lrEkd0hP6we J9YBkXwDjvXZr+2+y+XGtzIPoa7sv19Bkh/8hGwo835lcBXOhvpRJtbfynTCjRvfyvwGbSM3 3Nxk5YZ5Trix+1bmRlxjFWB9N0cz1sflwv5vL46VJt/9Z32s9OmoQwn3LiEXL4Jr8vKaoXdT 0o73OqLMimkf5X0CQPBdInk0xEuBWI5LOVYi1xwr7Rvy7eD6iHK8V23aD2LKdT14rQMi2UPu x5ktHba1h36OdCc0Br3N5cW2XmVHxkCTUM9x0LvfATcBBwD8hOwh894F+O6oZLopiDGQH2ms Z5qRJ94nYqwTQPp8wNrnB2rhx5FmblBM11WIkD/OOg7HMugiW0Y6ts46Ade+GTcgJ1MBKyfM Iyf4seUE9dODW3xUS4E74/lNXPJxO2Dl4xakOeGj2mU+wP/6A3HSjzq0mXzMbYMP5jnhw239 GC9JE4/FiQ+uD5CPhW3wwTwnfKB+bfaXHUhtAqz2Q9Ekj4b0aN5jY3D+CIDvQS8kA20P9xNz HU/ID4cd9DFdyETdbzwaXO8GlgFiv/GCrJIiLYdQchdkEbHdb+yGb8G1/J+u+UzfE/JY64mE 8+MWQm/+B5zLwGGA78sWeV7vKjU/T9h/jmtFHNkdGmvV4kQ/EPTj2p4T4J6QurHH9T0hHw3/ q74n5Mutf9P3hDC9rTmBQlyTQLXCrseIuqN5Ecf7KSj0JyAdOAqk4Jyx6rHezWpxXpl6Qx7j 4nrkpRvy0wEUDa2BIeqII64F1AN1QCSfi3oUyefS90i6sCeE9nIt6mx9ny5BGu0ldagSMAez z2W3R3IFTiInVptp53M54caN9eZG1JvcbIa0csM8J9zYrTd3hBvurdWO/d3WV9f1ht/n445J fp/PZudkJtoh9D3HiENE3Fs7FmU+ATc1kN9A4ge9JDj/y7xTSIhGbwK4xnygPXpj5kbDuaUA QivrJjA4+H0+G0Y67qtzTy05uQnSygnzyAnrYdeXUD89CJvUGazSrgSAePDhD36fLy58TEWd ycdMSCsfzHPChx/lGKx8NCFtE9BR/ZiFc2sBhJB+eHFgWpO4oHtr/27wJqMTUWdE3+LeWi/S WNdwejQJeaZ2OFpbCcdnNL5tpL0vbzWf1ve8PDNCquC3ETY8cEbf+1I4R6qAbxDX/+En9nCA Kj0I/UrGkYiD43P2vvCZ3I38FPCfArkvdUOffrKa309+p0+NnJsvzqMfIeIo5sh3KEbBdID3 Z3+nbvoB6ne4Pbfc+9LlylYf977ckZdUwb8p73lUqhDpVv/qQu59OQPuuPeFukvuVsp/6bNQ HpPfUx6ez7jgi9x1Qz65oN6LdEQd8UjuVrEwEORO8miIlwKxnGOkj+I5mlLB/zGQ8ZBMfY3q f4TzuQ8DGIQkAxnBpPN+C17a0tdClOY4IBNcyyAxHxI/GAcML6hSPykQ57qlpxwHzH85tYLr VE/tkiv4f9sur1MqRLpVT1HVC7I2yLFCLxDFsUJfSOrpWLW5oFk9XlCm9u7LuJm7aPW0Htev A6inA7Xwc5DUNfbvC71etRh1TQYv6yCpW6AJHe3s/6lWkYafsO8lP/JivV7lhBs31qvWo23k 5iFIKzfMc8JNIq1Xsa82Dulawf9DsOVot7i/j0HROUH0s3D2bRFK+8A315THG3rXrFYWZiv/ KBTnumXf+P8G9v5XVgV1cVRKVsUJ/B+C1PRuFSK9LftGG02gA43UhSXOfiTawX7Wlq1RcPJE 5A0C7gUqcdJ9kFWQKZBFytD+LbKnf57yciHj4nqxeMc6tV1cT06Z2dliu1pDPjfbGe1aO/eD dwfSgRxAtJPXngBMAg4BpUj4CpJ6Y7ZdzCtDGstXAuZgnueIte1ywk20tssJN9+gweSGa+1W bpjnhJtEs130zWi7DN8srmMJs74wLvQv2RT3oq9W45h9nraL7wjarnxD75rV4QXZivu+GW0U fTHaLvpmtF301US6W7aLfhdtV1/IoO3q3bdFPl6QpzQXFCm9+wpO3bZdieB30T4lgxfaLqtv wTwnvkU8bFckbqK1XWhaRLtO+0RuaLus3DDPCTeJZLvYD+l3cVyZiH4Xx5V8R3BcOR4SPxhX VhZWqe77XRw/0s+ir0q/i+NK+mEi3Q3bxTEj/S6OGasgabvGqi8XNque/mXq0P6MXwjbRT1K BL9rMfigb7HO0BvQhDfh2TGjE98i1rbLCTfR2i4nftd6gxuOGdmnzNwwzwk3drZrB67RBFjn yKOZ08Xl9D2OYxAZAVj3K3BfAvcrCMnvP3G/gpBMR7+kuU6ob9aNRoW4L3wZ8BIAfw3f4lJy uVeB337iN594bO7LIo6ijuYmi1GQYxT6hZynnA/MAiLN/wj+7L77j2u/dfMo6c6MUajMVbio EczxTKTx/mie479NmoCytTjhaeBmgHtE8RPqw8zbZaTZjZ3YdgbBWTTrWk74MP4PQlz4mIb2 ko9ZgJUP5jnhY1yQDtf4uESSTuyMk37cZvAxpw0+mOeED9RPD1b9yEWqClhtGHVtOgCzqWMp 7jMdB+L4Jzi+BQeXSNtQQgRzbzDHRf65si8O2V84B8D+aq6LRwvmIVn/+7EsRhBUgPH/FwAA AP//AwBQSwMEFAAGAAgAAAAhAIMGjxjzAAAAcwEAABwAAAB3b3JkL19yZWxzL3NldHRpbmdz LnhtbC5yZWxzhNA9a8MwEAbgvdD/IG6P5XQoJUQO/cZDl9ali5dDOtuisiSks0n+fbUEGih0 PI573pfbH46zEyulbINXsK1qEOR1MNaPCj67l80diMzoDbrgScGJMhya66v9OznkcpQnG7Mo is8KJua4kzLriWbMVYjky2YIaUYuYxplRP2NI8mbur6V6bcBzYUpWqMgtWYLojvFkvy/HYbB anoKepnJ8x8REpmxdDMdzbHUp2JjGokVDNZRaS4fd32XcEXr+q+QTP+By0qvmAz19350aHPf 8sIPmK3enJnKBD5Tb8GUss9HpuTRgWz28uJVzQ8AAAD//wMAUEsDBBQABgAIAAAAIQBMvYw4 uAYAAIsSAAARAAAAd29yZC9zZXR0aW5ncy54bWycWN2P0zgQfz/p/ocqz1caJ3HSRBTUfB17 x8KKwiHdm5t4txZJHDluS/nrb+zElOwaDvFUZ8bz83zaM33+8nPbLE5UDIx3Gwc9c50F7Spe s+5h43x4Xy7XzmKQpKtJwzu6cS50cF6++P235+dkoFLCtmEBEN2QtNXGOUjZJ6vVUB1oS4Zn vKcdMO+5aImET/Gwaon4dOyXFW97ItmeNUxeVp7rhs4EwzfOUXTJBLFsWSX4wO+lEkn4/T2r 6PRjJMTPnDtK5rw6trST+sSVoA3owLvhwPrBoLW/igYmHgzI6UdGnNrG7Dsj90c7J3PPXNRf JX5GPSXQC17RYYAAtc1obktY9xUGBU+Avrr6Gbh6NZ69UlAgjly9umo+NE/kLdEeo/ia7QUR Y5ghAZQWbZXcPHRckH0DSXVGgfMCMuoL5+3inPRUVBCkjROHzkrRe8E6WQpSqWiRJjsQtabi I6vlQe+g7Z7Wu8sgaVvyTg6aqPaf6EfBVJru5KWhAE76/g1p4dDb3Uft13PSEJXsNV3mhQM7 TrSrubjJ4Xz1WTfNP6Y+MPIUCdK7+qQBN45rVOT8fieJVGcMPW0aXUFVQwmYe04eBGkh9zfO SBn1k5IAVP2etj1kIl2IhNUbR9zUaAQdlM53pKOlrqCSNWA0gJ0IeN8vXaSQSdNoVQYoX63c cZC8NSSoZ2WgBH/OSBp6uOk+DOAKvelAiar62a7uCH4F58+pUkVttq9mglZy1FI5+2337tgZ hZ4y7yB+4JD+8P0tb8zJk1VPQd4rLQyA8qq4nj8JSd77r+ZmaRed2MAem0CUbztwlDZMpQhg T8Gt6T05NhJO3AGkCQAOozFMh0t/oCAKyfkvXJKGH3h45Nf8DZevpk00I/2YnrUgZ/DVn4LV r7hgXyBvSbPrSQVEg4E8owIbIEcu1435VbqA+/tiJOb7IXMlq0jzf7uVhrsDqXWm5UQSnaAd vzt2lTxq0/4G94BmmlGZCpzUzUB3wRujgzY4gytewA00+agWgN/TfHTl8OI5TwZFmHw7LE4J /Qw1T2sm4cnpWd2Sz5DlcexrN6/OyeEJxjm551x2XNI7oS4K8wWKqEpaTnX0iKxdBHiGPMpC 1V+Bpo9HOHOqgZkJjg+b0mVc7cZHEoA6feuM1Onhu+U1VfV5FOzJbfrd21gJ6AsA7iIIBthx PROe8Rpce07U4h24xux13Sj0CrcYg6G4V44bRKW/tnK2QeZnNg6KQw9N3p2joSxI14FNxnNx FFllvLUb5aVVpsRhtrVxfIQ8PBXgXAO4GHHk22QCF5Wx1Z7AR/F6em3maEEQhLldBqMotGod YC8urL4OyijNc5tu2EOZPxXvXAMcoLCwaoADLy2s3sEYl6n9nG0YBzpzxiy55gFOUZbaObnr lVZ7cOFFuTWmuMBFGdssDWMv3lotDQs/TK3nRD7aImu0v5/XUYiLyKpBtEZ5atV6jYPQt2qw DsPYt3p0HQduZPUbcHLPzsldd22N3Dr309RaP+vCj0xHNM+Q2I3KzFrBMfKy0qpBjKIysHoH 0gOvrfkWR8E2t0Yu3oYlTm3Rjku8tcd06yIoYpvMdo381FqN2wLKEVtlCuzbPZrC5ZdadUs9 N86saGkQrHNrfDLf8+13YuZHUWi1JwsQ3lqzN8Noa78psjTMImseZDmK7HdV7iJsmo55huQR Su0Zn8P7iq0xzWPs2/MtTyPXfofkeRS61twpXA/51nwrtqhwrfEpSoRya/aWYejlVo+WUZiu rbdymXs+slZJCfdOoKseXlPlOHhD20QNdKo1GFdqrFi048ubkXYvGFncqpEP3uA22YtPKesM f09h5KXfcnbHvWEulyNjaKFzV0ONYeggtEkNnR50SRq2uSXi4Yo77RBWKjRSf33FUvMTFX8K fuzH087Qbt90NZDNcSgIJjwYrl6z1tCH435npDoY275hHbv67UkowNXVPedEwrQPjSOgwCBl 3hPaLT/sVK9CySC3AyMb58thmb1RpD2roeEhYrmbSqxqxE79Z0BvYTwb29/9A9o4DXs4SN2y S/iq4b8D/bF/8CaeHsckfCme/iCVsh12Twt13riEXdPiSvMNzb/SAkMLrjRsaPhKCw0N/ruA 5vQCYysMfZ+gkzNLRb/nTcPPtIb+3/CfkJRHYdBUTfhNVzXHmkK+1LyC+UyNlOO4oLvlX26f p24bRgh+lLNeW3XiqtnuZ9RFDUOAGqNUsGfCuuV8pAwoTysGCb27tPvrHPBsNKxhg9zRHoY+ yQW4RHevf2jk679IL/4DAAD//wMAUEsDBBQABgAIAAAAIQCTMNizvQMAAIEOAAASAAAAd29y ZC9mb250VGFibGUueG1svJZBb9s2FMfvBfYdBN0bUbISy0acInHjoYfk0HjomZZpm6hICqQc x+cdC/SyDdih/QgdBuyafpstl2HIV+gjKTlOTCVSsVaGE/tZfCZ//r//e4cvrljmXRKpqOAD P9xDvkd4KqaUzwf+T+PR88T3VIH5FGeCk4G/Jsp/cfTDs8NVfyZ4oTxYz1WfpQN/URR5PwhU uiAMqz2REw4fzoRkuIC3ch4wLN8u8+epYDku6IRmtFgHEUIHfplGNskiZjOakpciXTLCC7M+ kCSDjIKrBc1VlW3VJNtKyGkuRUqUgjOzzOZjmPJNmjDeScRoKoUSs2IPDhPYHQU6FSwPkXnF Mt9jaf/VnAuJJxmwW4Wxf1SC81Z9jhkEx5QR5Z2TlfdaMMzNDTnmQpEQ7rnE2cBHETwOUAft oxieEbyK/UBnShdYKlJsbkQ2PMOMZusqKk1ec39Oi3RRxS+xpHpjdo2ic/hgqSZo4J8ihKLj 0ci3kXDgDyHSTeKwjESwKXv1ykhnEwEFwcZMHnNLaPNABPKUq8w+AyuhHSIXazYRmRPEPhw/ BAAh6gKQCN513SCi/wfEZrsbEGEZ2gFhjg34nCCSrVXNQQzFUlIitTicNCKg0EE94KBJRCCO NrJgYkokt5zu6WJGr8i0hSg6Oyy+gSjeQHFqU1JOEvvVD3X3v4Uu8LIQDg719VF9S3lw0PX3 lMUJBj+eGw44K87BRUCdxij+/fPX/37+rTzKjod0oGT0FVYPJ6IktOH7HnKHiItiLJdkvM7J rqXUSKfkVbmH9oGe3cxD6YSPlhHkMZWkVzUvozFegAM6dROhE9hHXFprrGvICQU5jVWtqFL2 /kepPCmkqoK2DdI6zp3RPgXG/LLtwJxdeGeUpwvh0tLt9afb67+8m9/f33z4aA/pbks94Kf9 J6ltS4mT3lZbepRec00l4IdwtdYUTCB2VXNNXVB2sbTN+kEN/vPHu78//1IHLDSy71QViMpi e9DHkwO7vq4G79l1G3VFSTKqDgu9aqOuECYw0/yd3QtWxPA05dsc0RBndCJpTd2NTMfSnUtX 31fXXUMSp9qfo+2BRh/oeLiJbEigBr2rZwaj5iSOYc5yzzOV/2gO9vGV/tOUg8bgGuwqB2rF oe1gd4az+ZJ7P4piQdMaXZyALrQe9KX/unm4m9SWHzfk0TNfc7w16KLey253ODrZMZHoiQrR jal1hTAokLrOpEd9O/Lr0b9dhWx5a0MSeuTfrRAUOyqkMtg6rwAOT1ZIOfuroy8AAAD//wMA UEsDBBQABgAIAAAAIQDJph+nuAEAAHsJAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVsFu 2zAMvQ/YPxi6N5LsLHGNOgWCosCAnbbuA2RZToRKoiAp8dKvH2O3XbruUAMr0ENOpkm+Z5JP MHV1/cuabK9C1OBqwmeMZMpJaLXb1OTn3e1FSbKYhGuFAadqclCRXK8+f7rqq141P1RKmBkz ZHGxsrIm25R8RWmUW2VFnIFXDoMdBCsSvoYNtSLc7/yFBOtF0o02Oh1oztiCPNKEt7BA12mp bkDurHJpwNOgDDKCi1vt4xNb/xa2HkLrA0gVI/ZjzchnhXbPNHz+ishqGSBCl2bYDB0rokcq hHM2WNaQzMrq68ZBEI3BCfZ8TlY4vlbv4+Mz6yvd1qRc4BQQOYQbaA83eo+hvTCoDKHHZJzd N9WlJy979n7Xm+0/3HfgX+euISWwf/mxnHUbjt9IfzAONSeYGB9qgicDDS8k9jDYEgygVGKX YCzDnFQ2Ddm8qGgaNpx2PgVKBw2GpkfzpRqccV6WvMjPckw5BO8lR8HKYlHmy8uzHB9BjiXP 2XJefCnOcnwEOXLOl4xfLs7LY8oG6Kv/+bcal8iw08EnbfWDuoWwDtBHFXB7Y/zkyrT6DQAA //8DAFBLAwQUAAYACAAAACEAi0LsCAwXAADerwAADwAAAHdvcmQvc3R5bGVzLnhtbOw9y3Lj xnb7VOUfWFqk7l2Mh6REiZpc+ZZGGtlTNZbHoqa8VIEkJOIOCNAAOJrx/iZ/kGyTqiyyyS7L /I5v5TNy+vQDDZzuBpoEJTq2F9YQjT7o8370QeNPf/68jHufwiyP0uTsYPBV/6AXJrN0HiUP Zwcfbq9ejA96eREk8yBOk/Ds4EuYH/z567//uz89vsqLL3GY9wBAkr9azs4OFkWxevXyZT5b hMsg/ypdhQkM3qfZMijgZ/bwchlkH9erF7N0uQqKaBrFUfHl5bDfPz4QYLI2UNL7+2gWXqaz 9TJMCpz/MgtjgJgm+SJa5RLaYxtoj2k2X2XpLMxzQHoZc3jLIEoUmMERAbSMZlmap/fFV4DM S76ilwwUTB/08V/L+KC3nL16+5CkWTCNgXiPg6ODr4Fy83R2Gd4H67jI2c/sfSZ+il/45ypN irz3+CrIZ1F0dnAbLYHY1+Fj7yZdBrC2x1dhkBfneRQYBxfnSW6eNsvphJfskXGQPADYT0F8 dhAmLz5Mqg/5efHi4ppdmkZzgBxkLybnBzDxJWIg/2qYrBRe/K4a2sAwYN+ESxEQJbx/l84+ hvNJAQNnByCJePHD2/dZlGYgKeW1SbiMvo3m8xBkVt2XLKJ5+OMiTD7k4by8/sMVCqC4MEvX SXF2MDw+QU7E+fzN51m4YqIDj0uCJTz5mk0A5j2++knOHTBEgUKm2xdhwNSlN/CeMfSeceg9 48h7xsh7BqivJ61OvGeAHfJ8xmnrGbMABYDdn2uShQxd18SqPZdvoyIOW69hsp4WfhOKLE0e WsN/s1wtgjwC29iSjFwLen/4MZz+kU1aR6Uenp469OF9HMzCRRrPw6x3G34u2GRK1rbQrtPe ZBXMQMHqi2jPiXfRw6LoTRaop3Uwx30HLnzmuyhHLHQSHLtMAp/2TRbNydOGjqd9F86j9VIu lBuUyjMP209G21KZfNQ8mSFqeOyo5Uz6zOPmmYxKhmeetJxJnzluORNtaYVCLqm+hNClZxKE E5f8XKRxmt2vY8nTujicuKRITTY+1iVIaqZJBE9cUlRRld75bAYu2sAdF86lztjnu9Aulcc+ 34V8XYvsUFyEqEEZ2qG01is7CJeC3YSfIhadM9HZ3IyiZr8PsuAhC1aLuhiCPW/rFn5YpwV6 NV1zhu3nv00g6svDnhHOIQZzraIuwR/Ey8Gc1gbIzpzWlsgOorVJsoNoZZus072MlB2KS22V zUGW2CzHiUtzFQj0CVYQLrU12i/qI/zsF53vIgS1X3S+iwo1yzOQ7KBQXISoQVEqQqF42y8K wmW/jIpKQXgrKgXhragUhLeiUhBeikqmb6SoFIpLPpWW6YpKQbhEVIHQFZWCcMmnUVFpSOan qHS+ixBUUel8FxVqKqYUlUJxEaIGRSkqheKtqBSEt6JSEN6KSkF4KyoF4a2oFISXopLpGykq heKST6VluqJSEC4RVSB0RaUgXPJpVFSsKukRYMssWvoyOt9FCKqodL6LCjUVU4pKobgIUYOi FJVC8VZUCsJbUSkIb0WlILwVlYLwVlQKwktRyfSNFJVCccmn0jJdUSkIl4gqELqiUhAu+TQq KhZzt1BUOt9FCKqodL6LCjUVU4pKobgIUYOiFJVC8VZUCsJbUSkIb0WlILwVlYLwVlQKwktR yfSNFJVCccmn0jJdUSkIl4gqELqiUhAu+TQqKu6hbKGodL6LEFRR6XwXFWoqphSVQnERogZF KSqF4q2oFIS3olIQ3opKQXgrKgXhragUhJeikukbKSqF4pJPpWW6olIQLhFVIHRFpSBc8sn2 5OKwp2+d6Ro68K962kAN229miUXdhPdhBq0aYb2We9gelKzF2mFhTt+qHvs6TT/21JanTqZD zDfaAYmmcZRiifpLY737EDeR6f6sfaf+9vuL3rd8t74ZOjKXQid1cmh/0DsZWJsAdsbAjcWX FbQTrPSqO3Q5sL4PaLXBFbDmh7fQrCBaDthk1oMAc7ELQ1xGjAQB8d/QrjOX9/T7l6eHJyNR KIGeCwakCKbYWgJ/5X1xeF+wZ65S6P84ORUW1XbDYHAq9NN6x2gsLJH1jtMxGl2gENyC60mh 1eg+Th/fr5NZIVcmlh6si5Rt9YaXb6wj1/WR+V/WeXHD9nffJiVJ+A5gzveNYco0hC4kYMVg KJ5VwL70eRw9JKyDSMKcBnkYR0nIZsOaBSmhOwd5+rO8bSidUbVd5pvXjLplTw7voOGgEAaA RMFokBC8h8mEkNQBNqroUlE2nKAwsGXPv2ftK0RmEkDTdN1Llj6G4eoaAOHD2I93QKMcf1EK H8pCQITsYELHpQ2WsQCCYV+Zkr50XTCCv/sUy1Uifwjxp9uTcWglo3AiNTIq6iOinRCSUmt4 JOSREgK1TxJiQ9E5tOIsvN5z4DyQEkJxRk5siTPvsDOpi1BbM86CIJ3wWRo7zS7O4jDIPKxv HwICLvMSmK5PAzasKxReQEGlREXMtiTqyCpIIqo2E1VQvBOiUsQQ+paIHVsRE7H+7hGTDLZK S8lc+y3CWwM1JLiKvDBXXZEX5bspWaXLRvcHADfxWby50qSEIv8xk1XQfEfygtC3lJexVV5E LPQciCFNt0Ts1IqYyBWfAzGkaTNiswVE2LMiRANrCbBFW7LqgGHd1QRlcVNP3dXD29CwlhmN DFVEfFz25PD7Kv2i3IZbVAhUlTeIWtZ8y8admUEPb+HRLl2g7NJsWiEYjWks8oZpzONoaJ3H Xhyewsw/B/whcONFGMffBRlmGekKiGG5lYV+fHTQR+tTAzVNiyJd2udn2LSJ4E0AQCz0xfCf DAn4l4XeyXo5DTPRSWqh+XXKKg5EMqALFa9bRKEtpe1rqySJM8hp0uWEJYf1RPE8Aet4nfJW YcYD3cji4B2s9R+C5eofe/wmXHJNe/W80mZtG3NMr7zgaCwi3b/MpP6w1kLQWa4i1WRriovO y5RLWoKGRKpiCVxUXK2A/4TL56vVHbtuItklT9yVaSgtg51QInXMml/lsLytwRfCKdQd6pkF dXa9G9Q7kPMVvD00j+yiLsbbSHtFZxBBX5m349Na4rLCKHFZ8auVuNYmKytExYIqHKAvx0yS 14mdomn30xgjD/pcp0bSwOWdUWWH1htepxHlod0Z8KwwWjGQp72yYllh8dSw0H1yz6oQtVP3 3FojJte06nk+uf5KhNyOaMbujO2V8ebiTPUOY228dotKsCHIVwFPpQg0ENVxTNnlLZUi/Qhe UkT912BUbhgMDkWJxXrHSV/QzHbHcHjcUMYfjg9FlccG4/CoL4qo1jtOj0UeabvjaHQo0n/b HaNBX1TprHcc861JcNdwC244UONvrjDXY7SLdJ1F8AIbvHCLlRP+Nq1+lVtm/H+Svs/S9B7/ rQWt8kkNkVtbrbgI4pi4CbzIl+K/DdCoLF5OQhV29dKTKPUDR6oRfgRrhotdkWYRrAw+9AIu Q4D4q3SiU2TqFq60tVgBkcxOCsn32/NSlZAeSwlsN+5NMk/gzacbte1eT74hXWE39CD+EBvz JrW0p5G1Ko1dN0VWCTupfAtT+o58vYJzHGZZtCqYxHenXSEUTuLwE3XJasCEqR6725ERVoGa aVkvqBsTwLa+jyiNC/y1VH7a6oJAiO4VqgETplUyNOKqY4ShhI7S4ekm1VxHqUMsjm4FqgEH SsKr+6EkQp/uuPLmpzWe7UGcnxowoeAlfzJc0CKLWkBn6oeo3bJhzCfqYCAF2JpxNFZNCmXo iMVQFojgLafHhxhNAYn5wrundRw+gEGzUvxOjO+e8KpXoHPWVGk6GMPhLICOoikYE9I/YjJK GMfrKiwD++6YchU9rLOQMENcbuKBb7FLhWpe0R/LIIEKwT3UdLVGG1c+CQTa0l5zClhklQ92 JqkOajRaj90Jcc0E0Y4rKsRgXkpGcVsjRVUE5MAXVbkZtCy9t3WxnCu2HQzBs6fcwnB1M20g 1IqELIAHunaU4Uiyvb6xmAHIc+5gcD+MASuwljKmuu5cxkDRTaQ83ZHulm2jYhpjIB4O8lLc /pBvc+LtQuhspBO6isM22lVoj7K5tTcCucI+R7GfWNo34XpEcV+aNPjbiZN5jIoFNMvwdLie +wlSiHueorLbsdVqSSWVDV+lkOpmxBTd88tNRqgxn9g7h+oo0p6OaA22GlqScN0UWspiYbVM puo/5hLjQPY0deZlsryw8PYqKsdMDBbTcGh7Bo9MZK0GOwayVtrLcSVaU3nt9zX/XWkgx0ul RZmKtnHZpWvsGmdPEIkD5V3NWAkuVq525+g4B354T9SSD9zBCCL4G9k+Oe3T7ZOqYo5PxnRX onqLQciofJh1l/liPZIeYjWlmd3m+iPjobsAeS/ueLIKJNQiInFwJnpksX+zu9wBsgaaBePF reWaMpXn+sAu1OpNHCRjFx6AWA8XFKeYQbHoJGDK5UcdSIk/Gy0rS1PL4MDgSCs7iMORbPeV d+rVSTYKtkrVW8u7fWjiKE7i8ap0U0tcNjEVdoHFhqadEqJAPt3GzKpIh70HYoh0WNcKb16D t4vsO2/2RQpfIckOf+Vyq15ur0oHIuZulcftzgwwlkAX55T4OTFwN7XoFB7ri1K1dRbCdZMU CMUeqLQaKqllvqDZ8retoQg8IysBor0jwAb7vUoF3ybz8DPdfQJLFX6GsylNZkIv/tt43XLD zdfy42rpDhJfrdhQcViMLVerirfwPDAozNjDadfjrV4CQozoBhLHSLRkPDFGo2OZ+XTkibjA YAnBnOLzG+7wjl0n+DQYEa9VSrtil0lz8Pg+eAivsfudmIwVDPV4Z7xRk+wb1jbfZl9cW/v2 PsgKQzsHu7xf7RygYaLqJHeGWrlGldWXPnLYcZmd0Yp1QtZDT6QhG9jUatq4rgyPY5+EyvWw Dd26ESizWiM9+JA/RTRzgZM7pk1lR60VpSrxRiX37Fi8bsLZHL7SQMQLrt/hwPMSc5+j6tJC 8EoDUEqadcU+Fi1V2NeydLDSj5pw5F0/rMOcZe5GHspBOyMl93GVNGBpqxbb6zUsxOAnmBDu Tddfy9pQx/opeWigjhyykYjT1MJa7jZsdq4jhhq26ThLbbtMbaJ925o381t+b5A8gb+XXL1O DdSTg449YuS63D+mKv0EfDdFK4ztvsEKzCk90DZc/3U4EcdblBvk3C18holPSsBszAKmqCFd uuTEZo51YlvMMSCTsv0MAdVpOmXQ4OD3tB417MipmKkoWekgJRBao7NJDpSQ2BTXLgaVzNch x8w+GBIjJgTsOtKwVs3wz4FVJMd4AmvuaH/2Bso5bMugntXB9TvHXkJZ97SRVXlBvWzESs+Q 4aryvyhFAzodFV0YOvjNKyM+OGJih83dS+rgnEZMaTLq59S75uzKGIzfhPBKOsu0TIRgoqzG dHUi1SwnSew61TafgFUaIk22dkscDiuXI3TdHFcbAztarSFM4uu1BZm45OeMkFaZ0WytrBES rJhNQd7rVAY8S7HZKZlt2r3ayEnAuhU+u1x2btHE/Bk1sb13y83eDRYvZaE771Z/a9LwkdLt T7Zob4RyoxHK99QIwWqNRoitd2+NUG42QvkGRoir2c49ExS62Hc4aYiRb2iEkAQ7XvaERcpp Qjc9xcDd5tueNsupQsB9zntp0HYsj2NtnSJ1F44LZtDNXsmlzbd7/59xye98iW4LF4IZBt8g 2SRD0ZpjtOUZ+vVGPnlth1Xfm2izN6YSzSeoMQpyme2ppCUfRfPoRc62mwbKTG1B2P3aS5vA URNwjHvdQYnLT0BJalTH1a3Hvk/fF8uLK3tXHVehJqtwFgUx72mmVOOjcHAjvqBgop4+1Ki+ BmdYaaDcszNawLfJFZf+EE5aXLAsEAZF16HokGQ2Q3YdChZv1qHeNju5Za9i3WfhT4RvOHKH QyaebVmBe3w1Yx9ilrhqLfsdFeZw+awn1IIYDpkQ032JnqPr1xuFtGIKJf/hr8T3qTpKK5ox HNP3Yio3NKrOeNRwdlGL84+O+Pur9vd3Bl2ckDQaiUhPI3oF1xZnKMFRELxUY4PR4pSl4zG2 xdmxPRTnMGl2wmD99fcPvYIQYvs77lu4ZfbD8ro3jnX2tjcwof4Bjd+1yC5Xv2uRagUXDYH8 nTHicrWOv13oBrwMY6x2cOXY4rV6BFB6MT+XxPxT+U4KNThsmxN8laCc3+vizOQAlbv048a6 nKSgrTKnO2zdkeM8ZIrcO/CjHaXWaAtqiSyxY4KZaoKcXqpe3zIX7J5a3pIFtNnyhXGOhGmf lhOlm53a4ncPVX7PavB7nFeJN1vFeZUk/+n9FXNUtMB9yy5b3urRSyK6jdVtb6N1fUa9qUaQ 8pwoe1TVmCG1SIC6SG/EAbBgGSXxqFeqHpVj6XqVCakoNnTvjZjw0HI8lylzMR7HRJ7pK1Md uAq2YPpqFV+w+dUqHBO4+C64Ui2uMKPDiIChdETrIKjXoiRQiwYQJYGtjpJ4z1Fwx67ZopzV bShYpLM+wQIu9oTw1nDQbZCOA3xzsnH9+/oucMUyNZyLAAJULS5uwA31xicSrV4QZ7QXpHTQ vuVbnWq11dxE2jf4K9WjarSf+nXsCgsqLv702F5fg4PG4e30s4N5WoZIXR12obby9FbBYygT AcFQRs4OWOEOfqnGQTaq1Z9bmk1dGqhNZ9JgsehK43xlgXo1Wf3ScR2M+Cd2FXqiTik1YAP0 qAdg6Fns//cXAu+W6G2wHmq+2Xosxvv7C7HQ3a1nZDTE4lT6mjEA2yEWurv10M8GMvqI2usz rId+b4+tRxx/8wzroZ/JY+vBjUByXMau+OVoAX83uQQDGbNP/dadjDbUtF1TjUdOr0bnr98w M6eCLOYBAd0L9jEUUMKOSlTvJnA8yjm2BxlWX47t7fIt+93vJnp6VxNaPbp6NrpjmGqgOb++ t/QGkXib3NMvDKEg4Yhp6bqY4biN7C3di1MdYYkX6ZJ9i9tAXm1wRwutbF+rsONb+Hp7Bkbi I1lTOWJaUNu96tdHR+PL84rFqOxS9+G/qys+vpbRaA4H30A3IzzX06IotNh3DOGt9+AhC1YL ghobLb9/yR/u0EX7RyftnxiH7puTS4GXSBn08OqEH0nMtuzh+4Cfi3UQT/jmCkcap7QUOoU0 tx8/hlOCMB/p/QHG/rgFuuv6Zz/B3ucRO4KFH1baH50fnx6JwG1f8z2gqkyAdnSS4gBaiYAm UzxY8RxOThQht/jMpdwB4nfhr9pNqHBMLM7j6CFhFkOSWGvqqCai+c8XqstFNovG8Cl6OTFM XnyYbKNRr+HDPGma3Joq/mKsh4Mma6F7NmZs5Ko0oBfwfVsumlWRGl/2+2NhQATKNIOpZF4q NCGN+8EiXQaYtPEvHd2qC7P87ED8wvWXO5j89FHW61USuO2JpBWT6/ANdTLU4zWdvr2SUDWT ZTfJFpI3kVtUnHZMRji/qSqn37xmLAqDvDjPo+DswEN0KwRXdlF43Rv1zZo6fYMETjHEr29s fKxkVWgPr/qjE5EwCip2I1GV10TqCBp1U8ONWZRG66/LiiAcg1tKXSOmSl5KFn436X0XJbOF +EpVSQt1Mn9D3lBhrEOT6iuuc1qMo6XaVpO0Z5k0ySADzZTpThUqkuKgWECChf/99//85T/+ +2//8s+//Ne/NopLVRouT0ewKccn/Xb9P3p/0CP4rvUhd/Lsx82afeg6KN4xteAkKrtXyxfe IToxOf7yBohfqq7fIFWTaDlZJ4J56NA+hlkiva6srKnPXwxFxbkmfRAwVAzxz4sXF9cMqGdU 7pI+uvsA4ve3f/ufX/7pr79LILNeLOJjqUF46XGW9wYSKPunLfJnDTwbpM98pPv2Aidzo/zr /xMAAAD//wMAUEsDBBQABgAIAAAAIQA8QG0DxgcAAGE9AAAaAAAAd29yZC9zdHlsZXNXaXRo RWZmZWN0cy54bWy0m1FzmzgQx99v5r4Dw3vi2Enja6ZuJ03aa2baXlonc88yyEETQBzgOOmn v5UEMgEDu4Y+NcZof7va1X+VVHr34TkKnSeeZkLGC3d6fOI6PPakL+KHhXt/9/noL9fJchb7 LJQxX7gvPHM/vP/zj3fbiyx/CXnmgIE4u9gm3sIN8jy5mEwyL+ARy44j4aUyk+v82JPRRK7X wuOTrUz9yexkeqJ/SlLp8SwD2hWLn1jmFuaipjWZ8BhYa5lGLM+OZfowiVj6uEmOwHrCcrES ochfwPbJeWlGLtxNGl8UDh1Zh9SQC+NQ8U85Im1EsYdrRl5LbxPxONfEScpD8EHGWSCSXRiH WoMQg9Klp64gnqKwfG+bTM8aPBsyJgfXKdtCKnYGG+b2TIZvBkWhmQeV311W6xanJ13BFBlR JqwPGBdeM0tPIiZia+awqalOLqyHIfX9dyo3iXUnEcOs3cSP1pZalgTPTs71yquGlpEMNJbu MmAJd53Iu7h5iGXKViF4tJ2eOaoi3fcgFb70rvmabcI8Ux/T27T4WHzS/3yWcZ452wuWeULc gYSAlUiAwS+XcSZc+IazLL/MBKt++al4pr4P1IvVL+1IL8srBj8KX7gTBc1+wbAnFi7c2ax8 cqWcePUsZPFD+YzHR/fLqjML91dwdPVdPVqB3YXL0qPlpTI20ZGW/1YiTl7FD5+0KwnzYPGB GbbOOegQCJkyGgqV4NkcRM18+LlR88s2uSwg2gDAqmbhY23SQZ5ArJZGtOFbvv4qvUfuL3P4 YuFqFjy8v7lNhUxBSRfu27eKCQ+XPBJfhO9z1SOKZ/dxIHz+b8Dj+4z7u+c/PmuFLix6chPn 4P75XBdCmPmfnj2eKKUE0zFTSf6uBoCMQToqHO3QRuy8MQ9qVP3wvxI5NTncSwk4U13N0f53 gnTUm8GgmYqoGoC2S/L1dLiJs+Em3gw3oYt32FzMh3sBe5mhGTG1UalKfFJz6Zniq87D6duO klUjGlXUO6JRNL0jGjXSO6JREr0jGhXQO6KR8N4Rjfz2jmiks3OEx7Rw1avoVM8GamHfiTyE VtmjdNOBUle0GueWpewhZUngqN5ad7tLLJebVY5zVcvp4WK5zFOpdpw9MwLdWS3dgzX5U5QE LBOwMe8DDZz6O7X7cf5OBexge1BvTPE1YtIbk70t7DZkHg9k6PPUuePPJqOE8d+lszS7jF7n Bqb1q3gIcgc2hqrl9sLOWya9fSaM/a8i03PQ2c3PW0LpM47K4XlLXbYb/8Z9sYnKqUHsRs6N nhPSXENoF7un6EylqLm6eqNQCcCEYNoFPQRtH+G/aS50+yrHGP9NKzrQPsJ/07gOtK/rozu/ ZKW5hr+sOKjlNSev3SsZynS9Ccs10CsPc/IKtghcCORFbO2jRGJOXsGv5NO59Dz4zQ1Tp+Rc 7HSUQCGnw1D0YsPHQk5KTfamhIjICaqxZgTWMK0lgMii+5M/CfV3YGoz0Cpt95q9y/m0ZQag BaH20D82Mu/fQ89aNA9LuYnhzyUZd3C005aVh6UV9WT6HSHHwxofATSsAxJAw1ohAdRSH+17 HtsT8ZDhzZHAIsuy7WK67NDKPCcrswXRWsBIfROx/2pZve210OybCAo5Qc2+iaCQs1PrZbZv Ilij9U0Eq6VrtOeoqqmUoMh9swqyOwFEROOINwI0jngjQOOINwI0XLz7IeOJN4JF1garqVXx RoD0K5Rf9S2oKt4IEFkbjNoVfzMq+5620v3L7QjijaCQE9QUbwSFnJ028Uaw9CuUSqixrNQh WOOINwI0jngjQOOINwI0jngjQOOINwI0XLz7IeOJN4JF1garqVXxRoDI8mBBVfFGgPQrFG3Y K9561f928UZQyAlqijeCQs5OTVDtJhXBIieoxrLijWDpVyjFULB0cVOCGke8ERGNI94I0Dji jQCNI94I0HDx7oeMJ94IFlkbrKZWxRsBIsuDBVXFGwEia8Ne8daL8beLN4JCTlBTvBEUcnZq gmp1DsEiJ6jGsuKNYOl6GSzeCJB+5VAQJaJxxBsR0TjijQCNI94I0HDx7oeMJ94IFlkbrKZW xRsBIsuDBVXFGwEia8Ne8dZr5LeLN4JCTlBTvBEUcnZqgmrFG8EiJ6jGslKHYI0j3giQLszB 4o0A6VcOAOlVREnTOOKNiGgc8UaAhot3P2Q88UawyNpgNbUq3ggQWR4sqCreCBBZG9Q5Wzgv ij6eOm0pAuw5g/JUAxo4a0kSFlgE+JOveQoXC3n/6ZCBwDJCArGlPLAhfpTy0cEd7D5tKRA0 SqxCIfWR7hd9SqdyEeF03nGT4O6fK+eLuQDTGKdL6vXJG7g9VL0upK8nqYtD4Gf+ksCVnaQ8 Wa6swQUhdbWruAKkr4XewIWg4lqPGqzu+cCL+lJV8Vj/v21BhZ+BqAc2UV4ALA9uRHWgigPv 9gySPu5eB7eciteO7K5klG4Wp+N3eyjz3qszmp1+5+okeIfP+qR45xw5+hWT1aaDcDlLu9Tn IaRsFZorZvDDTexDhNvidpZJpv/MjCn4/oqH4TemL6TlMml/NeTr3Hw7PdEdsGZqJfNcRu3j U31AXHuyzwCUQ9UZ81EF0V4n8SZa8bQ4bt5akqpz6Jtor0vSnHVtKQXsTO98K3/K3v8PAAD/ /wMAUEsDBBQABgAIAAAAIQBZNqjCgwEAAHAEAAATALMBZG9jUHJvcHMvY3VzdG9tLnhtbCCi rwEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ALyU0U7CMBSG7018h6b3Y+vIlC0bRMYwJipGwFtTtzIau3ZpO2AxJr6Db+iTWAQJu/BGM+/a nub//v/ktOFgUzCwIlJRwSOIOg4EhKciozyP4Hw2tnoQKI15hpngJII1UXDQPz0J76QoidSU KGAkuIrgUusysG2VLkmBVceUuakshCywNluZ22KxoCkZibQqCNe26zhndlopLQqrPMjBnV6w 0r+VzES6daceZnVp7PbDvXgNFoWmWQRfRl48GnmOZ7mJH1vIQUPL7/rnltNzHHfoxmP/InmF oNxe7kLAcWGiP96S9T1ZUbKO65QRo7vSASvXSst+aB+vv3l/JJvW78imY7wqGsB4cgOQBz7e 3sH1FGw2m69l0ooP/8hHhvU/JEdmDA/RhWSY5430Cc8ZVUsgOKvBRNKccswCsD9upQkIHVl6 YhUpKX9umPJt5LWDdo/QGVG6gW0HeZh6M3u40kshG9Cr2dyagamushpcSlGVZhh/MmJvH+Pu q+h/AgAA//8DAFBLAwQUAAYACAAAACEAga3+MxsCAAA0BAAAEAAIAWRvY1Byb3BzL2FwcC54 bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVF1v 2jAUfZ+0/xDlaXsAJ4DSDhlXG9VUpFVFIrTPnnMD1hzbsg0q+/W7ThoI656Wp/vl45N7TkLv XhuVHMF5afQizcdZmoAWppJ6t0i35ffRbZr4wHXFldGwSE/g0zv28QNdO2PBBQk+QQjtF+k+ BDsnxIs9NNyPsa2xUxvX8ICp2xFT11LAvRGHBnQgkywrCLwG0BVUI3sGTDvE+TH8L2hlROTn n8uTRcKMltBYxQOwVTiEb9xLMepL48oESvoMR03gqpQNsPx2io1zStd8B559oaQL6ItxlWeT m+KGki6myz13XATcJ8unRVFQMqjQr9YqKXjAXbNHKZzxpg7JU7uVJCJQMhyhuKkNiIOT4cQy SoYp/SE1kslzpNiFSM/xneN279l0EkmeU7oRXMESN8JqrjxQcinQB+BR7TWXSJoew/wIIhiX ePkb9Z6kyU/uIe5xkR65k1wH3Gcc65I2VtYHx0oZFGJjr8vbcDg2jOWM5e0ABteDEaDjgI1r du0N/qnGdwv/IJsPybYcOqoDOoPwfMdfqI9co9COrcrtqKSkT+nSNJbrE1tp1Fe3KnKVlKBA mKY56Ddlk61GfZNPePwzyv92KOr1y29tae6jDd9kuC4O3PMiw35juYgSF7MMN3Xx0aBHN+g3 qNAYPeKlQB9QM6fitXhW76DqZ943ojOfu58Ay2fjDJ/Win0N3XT+OtkfAAAA//8DAFBLAwQU AAYACAAAACEAXwcZSiECAADQAwAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhJNLbtswEIb3BXqHgfYySStJ bcFWgDp1UCBGDVtBi24ClpzYRKwHSPq1yx16w56kI9pSnaJAAS1Ezq9v/nlodHsoNrBD60xV jiPR4xFgqSptytU4esyn8SAC52Wp5aYqcRwd0UW32ft3I1WnqrI4t1WN1ht0QKTSpaoeR2vv 65Qxp9ZYSNcjRUnB58oW0tPRrlgt1YtcIetzfsMK9FJLL1kDjOuOGJ2RWnXIems3AaAVww0W WHrHRE+wP1qPtnD//CBELpSF8ceaajrbvWRrdQp26oMznXC/3/f2SbBB/gX7NntYhlJjUza9 UhhlI61Sb/wGswWqqiCjVCH1GD7nj3EO972BSARY3Jmm8/Dr9Sc8mBKlBarfowpatzderWkU QL2D2fxhGedzKNHvK/viRqzL0WRTFqWvbHZKsPRbfYR7W21rENdB2gqa0b3gkRjaZUPWRC9v GpZGp6ypGxPZ5MuMCCeHSzgcDuH1E8C0sik8HTjn+umuUttmGEBVYne7lDvU8OMIi0l8LTi/ 6t8MQXoQScp5miRAlfcTxoe0B6IfTF5mboxupPMzWsdng/rjMVtMgtm/bhth28osGQZJd24p c2tKjzqjkfVjPoi5yPmHNOFk5XsHbUXUhLAtp65SETT/9LQtbeRrMrnLpxHxBPGGsbjKxTDl 9DS8VhWaTlk7YHEu5n9EwWOe5OIqTfpviS0gC6bf/oPZbwAAAP//AwBQSwMEFAAGAAgAAAAh ABZ+ae/+DwAAg7gAABIAAAB3b3JkL251bWJlcmluZy54bWzsXcuO3LgV3QfIPzQKaCBZuFvv R2N6BvUMHEwmQcbBrKurZLcw9YKqunu8i52fyB9kk2QRIMgm/+RfyBUpqShRokiKUtETe+Hq KlGUeHTv1eF9kF9989N2c/UcJcd4v7sfmTfG6CrarfbrePfufvSnN4tXwejqeFru1svNfhfd j95Hx9E3X//yF1+93O2etg9RAg2voI/d8e7lsLofPZ5Oh7vb2+PqMdoujzfbeJXsj/u3p5vV fnu7f/s2XkW3L/tkfWsZpoH+OiT7VXQ8Qj/T5e55eRxl3W3p3vaHaAfXertPtsvT8WafvLvd LpMfnw6voPfD8hQ/xJv49B76Nry8m/396CnZ3WU39Kq4ofSUO3xD2Ud+RkKNoua6+MzZfvW0 jXYndMXbJNrAPex3x8f4cB6GbG8wxMf8lp5Zg3jebvJ2LwfToa5XDJnnGcyS5Qs8inOHVHc1 YKzxSdsNxiF9vuenWu3RNFiDyZ5I2kVxDzy3UL5mfifbZbwrupGDhgQXVKKLfP8m2T8dits5 xN16e737segr1UyBOzM8pHnk0I5CHVCq+/3j8hCNrraru9fvdvtk+bCBO3oxnatUIkdfg7VY PhxPyXJ1+u5pe1X69np9PzJQk90xXsOx5+XmfrTA/yaj2/Tk7dPmFH8bPUebN+8PUd4G/bpJ f8WtTtvDJj82H3vTqWHN8ZHNc3ogho/8WmDTklPe2MStwKAttsWP62gVb5dZ13Dmm+in4th1 dgb8/NtV3ssmenvCHR3+kKR3fYIxZ595G7jECP4+7AFvx7bS5rfnhvEuHX/aDz4KXx6Xu3fI Fp9bZ70n+CLJYr87HdOW8Q5OW0dvlwBW1jFqAxeA+0xvBD6gIYbBRJB3heHmGo0BdS2PhOt7 DCTSoyQS59ZqkLBUIXFzbePn30ksfMtggJEeJcE4t1YDhq0QjJtrRwEegYd6aVCT9CiJx7m1 Gjyw8VKgJiAcgMfNtasAEtMwAoaMoMMkKER7Nai4aqUEULm5RiagoyExTZdlU9HhEjDn9mqA 8foA5ubaVyE0VsiysmZ6uITNub0abPyesLm5RsrQVXQch2V3zfRwCZ5zezXwBP3Bc3MdqhAg N2BZYjM9XELo3F4WITD6BG9MKQzxFa5FfEtpJOY0JI00zIntTCbZ8Otp5OP7hyRe/y6lmA1k 0jPmjheYZwsFl87JJPx5Omxgrmo4RmgYBi+venjabCLE05Dgkuzy08f/8Dwuki1WaYHt5cLc AP3yuIphAvL9++3DHqaPQB/HgFvpB1E+WUXCTrs9wewYJsXPMB1QgMxeFBdKbXmBme6fkjhK rr6LXgh0qr+KQWQhQEhhcdVD9Onj30RBskyQllQE8rkGL0g/wMwk9RSBs6MQoPJvYgBhiSEB MvsASFi7rCCQA0ideiHTWjI0OqgXCIocMFVFwsan+quY9GBlIqVHD/WCmbscSGVVwhCVfxMD CPG7kgzpoV4uvDql7I869fKRnSFlRwf1Ak+HHDBVRVKhXhAIqFAdPdTLcySNc1mVZNRLkJ5i R1OJnlrBxDadzJsoS09DZxbMTOwSQGQSHlSf9PTD30UZhlOxgOl37Ppk09Puj6iMB7Z3Pav5 pw//FMUnqBjAS+EzDEP98G9RfEyrYggvBdAwDFVcwUyvYgQvBdAgPFVCwyzwgZY4xqUAGoal iquY5Wpio4dhqeIqZoWaGOlBuKqEitmp24B0I1xKxYZhquIqZvsXM9KCTBVHAUmmahoLy1lM skCELFM1Q3MahLPaqHwxu7DC0Jt4jppQyq95qEZLoP7sDssbkq7XqtSfWzdwW+FAfYEMdjGb 2ACIO1aX8VO0X4Df+Yd4DblFKLMCQtWk6/lX15YKxFI+25za0MJ2QVZr8hUoamrKOi+yxI75 brXZH6P1NE5Wm6gWDSXxfMRdm8Foo7b1aNA8dIGm5+JCwUxzcW4KXOSzOxA3ZQDQQl3rAaB4 Zr9a4arQCsRBm4Foo6j1QFB8cgi9OEfC5MUCEU4GGi18tB4Nmjz2ohe+Cr1AhJIBQAvfrAeA Iof96kWgQi8QcWwGoo1X1gNBkcAh9CJUYC4RS2Sg0UIiczTgk4iOt4bOcZ5TifEFgWl7PnqR N2VgtofOrcnEMebuOUOjzjcJc/PLhc4hKaict9BK4PqMnWdQ6BB9MANfDhiu6MMKMmCrDcXC WQQjzFDTIyBhuaEcbqq93QRJLDQsnUuIk0S1ySo2hDxKjoLhNQ5dH4dCNdI4x7DlgKkqUm28 r7vGEVxTK41zfEkTrlrjCPqplca5jqQp7yXCrpHGeaakrR5I4wgWq5XGeaGkCe+ucYLEFqeq l4jtJJzYNlhaINnyxNaw/GARBNOC8dcRW991p3MvxOVN7UUErNfsn/9RXEl+zn1+0SrxZPZJ hLN0WiX1KJaK6TpKJW2el7VlmubzsnJCAsFhswErKa2wVQwYpYU2D7gta7R+wAQnzQbMmxbc v6MSpXkyBtySBVo/YIJpqhRpV8UTBnPA8tOjw2DWmvKC6wdMkESVIu2pGDBKxWx+wm2ZmvUD JkifSpFW4mNEqZXNA27LvKwfMOVjNJRY6UDFE0Ypk4wBt2RU1g+YYGEqRTpUMWCU/tg84Lbs yHzA8CniLsTBWZJVWY5jmmHYMZVxMQmd+dgZF1ynjlVlz2ChpmCquBSDVpHxXuFSm67x3guV FLURmpe7agW6cjpYx456cGB9KZi5H7GmHuLlaF8KZtKpZZb/QRqPNkrVqFQD+RvqyJsOGtfG zBpx6+5vKE/Y6sheDwAJl6i1MblGgHrx8GVvaB2iWP3W0HT3qddxyx4ESvgd10YcGwWqu8YJ clG8rkCZi4Yzx/WyLBXpZEV3bHkzix26ziQ95OSirNfsX/4rSkXTBFuQlWJ+fqmEW7qsZiKZ jcbE56+i+LQkGvYowuWXBs1jZz3g8/Ffovi05R4OBlCdV1C9ERTP+de4rEYPDWvLWRxMgmji qoeKfSmruR9RC+ORMyKNy2r0ULG29MfBVIxmqnqo2OdTVoOXeCox1TGsKzSbZRxTlqmOXT9w 5xN2LDpjqrzhNhYTE3cICTtNlfsSaY6qw+xU2snK5Q8S9DzTNBW/VRXnCwpPRdsizYNZwGFo qrh2fXG3XsTdKqheNEXVQ72++FZbKOoX32qDevXrWxVUL5qe6qFen48jFTsxy/TUn7hzf4Id S7L0dObNjfl8wXakzsbB3AoWc05H6mb/EiXfRqdTlBReL7KQ+drkSq4gZ6KmZSKJ4XenCkoo RUH7rc3jq+QuIeDZTATyZJEW7+YQlXZcK62TY7MMV2JsNOPrpZ6Ur866NByoeWD5/usfFZWM 2K8E8lVNl4YVhBLDQqeQCxsOIYFcNdDk2KDsSWJsdMC5FwnkyzYsDceXMRZU7mC/EshXn0wO yzFl7ARFPoaQQK5q49LYXD6jIRiANentW6y5A2thB3434jBeQJWFsWBnA06nTgDVw7zLxbQT B66SdhJWv7IwlF2sfsJcASZaHk/jY7xMMQLEmXu1pMEwYtlCM5SMHz4dDmzaxFcqQY4eFo+u RKGLpHI0/Po3EeVrMmW97eiB/nG/Xe7qiWBtLUQSv3vMFl+vydKC/cMkhqQxV5AZDs0VehM6 vmIGUuisQGZINE/oS+hqqxXYQgerREsInb70QMos0PSgN6HjKzcghS59pZU5N3zHxpth6Whq 0JfQ1dYTsIUONjHhGpIoI8BRJtKVYE/DieNMs6XfZF0JQWgF1tRpjXT5g+7EkRdTwie8qNH+ deRGb2nwq7lCQ7fQWAodfpUpjftwbd3RAmTHEszGOBFXMK17qmeZ86Q44xeSUpw59/9oQbpj 7Wcj0t2TQ8u+pzLnwlqvPnGMLyLXBmlaPtpsBrSL4WlsBzrWrTZK50B2oExDtbYDHQtmG5FW bQfKNFhrO9CxJLcR0r4KOTS2Ax2LfRuhHMgOlGcGWtuBjlXGjUh3twOiMxN6ExbHtQLHH6OX s/x6MO7MCeYwNymcUEBDqE1YLhPkbCEmiqcnHYKihhmmWYqSvs1Wzy6fb7MFrY5zkHZvKGxZ 2RWE7t7QFhBEpwdmQX0ZjhKSyxvGogMIP4OlYnpWBT6Pa4sUdKTh9apAkuN+VYHTR9sCgihD 5lIFks72qAp8Qd8WADry2XopIP3APasCnx+4DYR0XZnmyX1bolw9CCQ/7FcVOD3HLSCIksQG VQAwRJaiMenNSpypb7rTccbFZH3N1tyz5rMJ2lC+7HVCLnMcj/Xd2TiczcacaWuMqopXBXPk XIhGdt/DN/E2OqYbG19hngBENQ9F348myxPsAoyiHHgR2ZrWqSe05ucOxA9vnd2D11liG6Ow WlRdDvL0OJUpC1nZW5yuj96Ht1h8FyOzup1tGkIiomCDAUTyxXzvdfW+X4mi4WpE51IAURH8 PuI6EhpmmZqoGMk1sQTpoWJ00fCFVIzkoTqpmKWLkSZ5qk4vMVsXI01yWJ1UzL6ckRblt/TW LF7oW/7UX2DGKMtvZ9bccC2fzW8v47Eks25CyCKF1/r/cVWGYzARqJ88UvRxiIxk4aoMM7Ak xkYzv4Wkz1iBp5CUVctyJIZD8bR+c+IlqjI8T2JYFLsaQgLFqzLSLHWGfanXLpoY9SKBfA46 UgJtV8ZYIARKCeb4F/HMJK49RsWrMuxQxk5Q5GMICRSvyrD5jIYob6B3vvDdwLRgabxuvMGe 2p43a9n5otj+Ji0d7rbzBV/2FakEVW4HgQouD4W6FAqi1FOj3W76XW1EaYKkVrvd6LgASaFg 6l1e4gqnV/KiRhr3Ga33rJXG6bgmiVYap9eaJBppXFuotTE8MXzSn1Ya9/ksU2LSm4/4c2dm uvOOxUXzwHEW82lGjzfPG3i1Uil8lrOAzYpDnEbYidgKB3xTGkvOVHlpbV2s9ucQ3OUqKSLn BaYBeWgyCA5kGyifXS8h34/CC/BBooYcbt3Te8sxcdrxhyda4n4KRiLGJwn+61YimryqqW7G STkR+wj2CmucbVXXRuCcig+kcZSPUhONs0NJW69a42hHpx4a53iSplydxlFOUy00zq1WdPOa ooE0jvLJaqJxXjUphRe37hpHO3ahehxoCvz/en0/wrX0RErk6zUcRFXmuVsTWqZ+1tJpmKEK n4azKYVPw0Fq4dOwj1r4NDwDqD0NsXdAtA4SvFNM7WmwNBfOYas7D6/bXXseijc1XA6vp1h7 GtomseG0bDml+vOYJzIkBQ0PkanfP0dJEq8jkKF8cgMjrz+EO0SzHOI0JHr5jcA0KT/U1Asx V8qb5gIs0Auxx2iHXrCcdh0RsUlzh3shlqzq0AsW6q4jwiLO30uT7DKsDkoOaDqPYXZgvt+s mrANfSp29crCMo+g8I0nopSYpjtl2B4U+ms6j2V8mNAwrA+MngENw/6ghdka7hSmMo3ImCxo LIb9QYu/5hfEnw9REu/eff0/AAAA//8DAFBLAQItABQABgAIAAAAIQCubbwv3QEAAH4JAAAT AAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAJlV fgUEAQAA4QIAAAsAAAAAAAAAAAAAAAAAFgQAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAh AF+F/3kUAgAAjQsAABwAAAAAAAAAAAAAAAAASwcAAHdvcmQvX3JlbHMvZG9jdW1lbnQueG1s LnJlbHNQSwECLQAUAAYACAAAACEARq+n8hM8AADBdwEAEQAAAAAAAAAAAAAAAAChCgAAd29y ZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAvjXtgLoCAAD2CAAAEAAAAAAAAAAAAAAA AADjRgAAd29yZC9oZWFkZXIxLnhtbFBLAQItABQABgAIAAAAIQCHOb/HwgEAAJQFAAARAAAA AAAAAAAAAAAAAMtJAAB3b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQBhahVuwgEA AJoFAAASAAAAAAAAAAAAAAAAALxLAAB3b3JkL2Zvb3Rub3Rlcy54bWxQSwECLQAUAAYACAAA ACEAXLV8KPwBAAAmBgAAEAAAAAAAAAAAAAAAAACuTQAAd29yZC9mb290ZXIxLnhtbFBLAQIt ABQABgAIAAAAIQDxbN49ywMAAPQLAAAQAAAAAAAAAAAAAAAAANhPAAB3b3JkL2Zvb3RlcjIu eG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAAAAAAAAAAAAAA0VMAAHdvcmQv dGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQBvJtuGLjwAABgVAQAVAAAAAAAAAAAA AAAAAJpaAAB3b3JkL21lZGlhL2ltYWdlNS5lbWZQSwECLQAUAAYACAAAACEAn5uc8ysqAAAs yQAAFQAAAAAAAAAAAAAAAAD7lgAAd29yZC9tZWRpYS9pbWFnZTIuZW1mUEsBAi0AFAAGAAgA AAAhACA5OpSPIAAAfNAAABUAAAAAAAAAAAAAAAAAWcEAAHdvcmQvbWVkaWEvaW1hZ2UzLmVt ZlBLAQItAAoAAAAAAAAAIQDbr6KLQxcAAEMXAAAVAAAAAAAAAAAAAAAAABviAAB3b3JkL21l ZGlhL2ltYWdlMS5wbmdQSwECLQAUAAYACAAAACEABDhASaMbAAAImwAAFQAAAAAAAAAAAAAA AACR+QAAd29yZC9tZWRpYS9pbWFnZTQuZW1mUEsBAi0AFAAGAAgAAAAhAIMGjxjzAAAAcwEA ABwAAAAAAAAAAAAAAAAAZxUBAHdvcmQvX3JlbHMvc2V0dGluZ3MueG1sLnJlbHNQSwECLQAU AAYACAAAACEATL2MOLgGAACLEgAAEQAAAAAAAAAAAAAAAACUFgEAd29yZC9zZXR0aW5ncy54 bWxQSwECLQAUAAYACAAAACEAkzDYs70DAACBDgAAEgAAAAAAAAAAAAAAAAB7HQEAd29yZC9m b250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAMmmH6e4AQAAewkAABQAAAAAAAAAAAAAAAAA aCEBAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAhAItC7AgMFwAA3q8AAA8A AAAAAAAAAAAAAAAAUiMBAHdvcmQvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQA8QG0DxgcA AGE9AAAaAAAAAAAAAAAAAAAAAIs6AQB3b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQIt ABQABgAIAAAAIQBZNqjCgwEAAHAEAAATAAAAAAAAAAAAAAAAAIlCAQBkb2NQcm9wcy9jdXN0 b20ueG1sUEsBAi0AFAAGAAgAAAAhAIGt/jMbAgAANAQAABAAAAAAAAAAAAAAAAAA8EUBAGRv Y1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEAXwcZSiECAADQAwAAEQAAAAAAAAAAAAAA AABBSQEAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYACAAAACEAFn5p7/4PAACDuAAAEgAA AAAAAAAAAAAAAACZTAEAd29yZC9udW1iZXJpbmcueG1sUEsFBgAAAAAZABkAXAYAAMdcAQAA AA== --------------010301040806040506000103 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="LS435 response v4.docx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="LS435 response v4.docx" UEsDBBQABgAIAAAAIQAJJIeCgQEAAI4FAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lE1Pg0AQhu8m/geyVwPbejDGlPag9ahN rPG8LkPZyH5kZ/v17x1KS6qhpVq9kMAy7/vMCzOD0UqX0QI8KmtS1k96LAIjbabMLGWv08f4 lkUYhMlEaQ2kbA3IRsPLi8F07QAjqjaYsiIEd8c5ygK0wMQ6MHSSW69FoFs/407IDzEDft3r 3XBpTQAT4lBpsOHgAXIxL0M0XtHjmsRDiSy6r1+svFImnCuVFIFI+cJk31zirUNClZt3sFAO rwiD8VaH6uSwwbbumaLxKoNoInx4Epow+NL6jGdWzjX1kByXaeG0ea4kNPWVmvNWAiJlrsuk OdFCmR3/QQ4M6xLw7ylq3RPt31QoxnkOkj52dx4a46rppLbYq+12gxAopFNMvv6CcVfouFXu RFjC+8u/UeyJd4LkNBpT8V7CCYn/MIxGuhMi0LwD31z7Z3NsZI5Z0mRMvHVI+8P/ou3dgqiq Yxo5Bz4oaFZE24g1jrR7zu4Pqu2WQdbizTfbdPgJAAD//wMAUEsDBBQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Y y4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANa Xg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQAfBa+pZwEAAOEF AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANSUwU7DMAyG70i8Q5U7TTvYBmjdLgxpBy4w xDlLnTZam1Sxge3tyTaVdbB1lwqJSyQ7iv3p/x2PJquyCD7AobYmYXEYsQCMtKk2WcJe549X tyxAEiYVhTWQsDUgm4wvL0bPUAjyjzDXFQa+isGE5UTVPecocygFhrYC42+UdaUgH7qMV0Iu RQa8F0UD7po12PigZjBLE+Zmqe8/X1e+8/naVikt4cHK9xIMHWnBlTU0F4sCfFHhMqCEfadC T8r4cYjrLiEQiLy8uGeoM20Iwy4Rcq+oK7RZ7hk28qL3LhUkyHmXwIUaSG1dK7TQaA2Pe1Gf 12+ebOptma4InBEnpeud4C61dBatolDaku+s21g2PJwKjrQuAN805VOlQFJTtp9XbfrFJziO zOj5OdpB1UIkbBe3tR902f4P7ev/U+6bLrk/YfHy69M2km3G33UJQn6vNnbXNuTbM64Z+MFi Hn8BAAD//wMAUEsDBBQABgAIAAAAIQAbSGh3QBEAAHQ7AAARAAAAd29yZC9kb2N1bWVudC54 bWzsW9tu40YSfV9g/6EhA7sewBfdfE2sQGNbiYE4MSwHs4sgWNBkSyJMsZkmZY3ylH/IywbI vu6H5Uv2VHVTYlMULY+Tt32ZkUV2dXVdT1W1Pv/i4zQSz1KnoYovGq2DZkPI2FdBGI8vGt89 DPZPGyLNvDjwIhXLi8ZCpo0ven/9y+fz80D5s6mMMwEScXo+T/yLxiTLkvPDw9SfyKmXHkxD X6tUjbIDX00P1WgU+vJwrnRw2G62mvwp0cqXaYr9Lr342Usbltx0nZpKZIy9RkpPvSw9UHp8 OPX00yzZB/XEy8LHMAqzBWg3j3My6qIx0/G5ZWh/yRAtOTcM2f/yFXrtFBX7mpVXVgK846GW EXhQcToJk9UxPpUajjjJWXquO8TzNMrfmyet7tp+yyNvo4Mr7c2hihXBNXIVwgjMomlk5ED6 XWm1TLHVrDuM1QiRWPKwDQvunjknUy+Ml2Q+TTRF4cIj3mLfX2o1S5bsJOHbqN3ET0ta5Jiv 4Kx5zJ5XPFr6KgJrrjuceIlsiKl/fjOOlfYeI3A0b3UFWWSjh2DxqIIF/Z+I+TmCTXB/0Wg2 Oyeto6tuI//qSo68WZTRk6vmyfHZ+/zJXeErIqLpn6x3L9ME7iZFpsTXw27n6PND+pr+5Td0 TpiWH79vH7cGzAtHrPM08XxwmWiZSv0sGz3x3HUIgEyyxvJxv9k6auWM3RdYthvYPTew3D5z tgCjRR5P3p+cHi1PfX+HUNRs2i/53Hd8LoTrrB+F4xhrn73oopHOEkRwX4dJ1jg05zdvZr1s ssWGLE6KuxVC+UY9CwTrtkOmUjSbtek+2SCaax364tv0UelYit3+LJso/e5P3/VSTSmHpWKk 1VT80/N8nPeDRAz0dCbjP3v/aqG7TPUDHXqxcFiBaWqlRtea7CdbJDDkNJFRNMzANtnA0kkG nkZi2mrxdRxY81m3e1eFRbt3n2xSbhBmkKl4XIihr7JM3HpxOgplFDicVdrV5VmndXld5XJb RYmd1rmzR8nn+medfrtVGxec5ZUsuowUpXN53e32l/Fig3QenB1qGOxNpPBnUChQVyozoUbi 5vphIHIolgotf5yFWorBUPxtnH0mhoP9uwMh7geXR8dHXRHGfjQLZCruD047e2I+Cf0J4bsM X/3+829b8JHHKxOcXpbeA1iWHzOpYy8SvoozraJUeKkI5CiMZVC2aycgFsn3wlh8j3N0u+2T H8Ttd8MH8SgFQl+i4KnBwe8//4fPSc+FH0lPl0/DYa4XLcrf50eiaFvcsdo5cxGnjow/Ewm2 RC5KJfIRzvz10IQU+gwd1e15ctrtD46MCfYGlM140cN3IoBiAg6/+83T/ebxgUOm0hQtsfxM hQS1jaNWH/kmZo58Ol828bJanVmLN8Im8zOGCIMMSekprDPYE5lzkpLJFwVSzdEEtNKJmkUB GYEXBMjiKUSVTQCyxhNmF0BkCptjB7F4FJ7wQEvtI/vt9sfx67juX55cDwzayXpL1sR+ac2L gXvthbH2psXAnuuW7NWR9mOYbrWZDfQVSYS2Wj51XLG4UbVO8jKSopIe+Rxv2FqoMPqIAENW HUgUcQFKzIVQMYUldle4tpbIuAFeUsVwMZ2i9BSJDpVGZbeF+b8qWdiXV9my+mA77XPXRCod b3MOOGt3j86u8gTGOWDLnR8gsdSXsQcBkO8A4j3CyiGukp4dVb0MdftxLD+KdgWhCbCEjsL4 SejzMLho6JvgiDiH12RKL9Ai4DhVtV9uliYzFJjQBozqYbaIJN5izPpVvlEZsX7dajddJA9x L9liXeU7bYnrd7cQVk5yjfmsd/ntrWgdIT3+QkEdZQZ/vN6CqImBLogthbot3Kq8kaEaxkHo c972xMgLoxmSPhyPfAwBJFEUDfEhU74qoz9HeQVL3FAXIWheUjqNFiLMxNR7givHConOll6U 1MN4xmUYvlzL6K+LZwbsmTMOB2XVVdLaELAKlKr9urXXeif2BbC1FSaaNxAg8tsHMQFCIbFC iqT4+UTG9ls438jzM4ggs29AQGUd5eZEFtq5PLrsv69DmOTmvgKs86l/JOacPIDxsH8tZSfj +Fqi/QSM7b0+5TgWUeS39+qUspFUtQ7IZu8Hx52TUyN5MiZ0bUyyGKkoUtSPKsXfkg9ZhnOZ GxcunMLGn0k4nqBqnmR4kUPQAgWTmpfjz/c3sGudFRUykVr+8DYVu3p8ZQJxU8uGImKn49Y5 lXucXB93+xzQuQlTQIfuE97DfsUh1zgkDBVhhgGUgdg5GOY+MBqzHH+u/3F9L0azmK3Zo5as GKkZAgNcxxYiDMQsLS9KFQUUokHmD4twKNhlqWCoAG+FtbRB4Cs1l2iF7ImQwh6YGsEBKAzi oy2DADTB0wp0ws+KcJAqH43afx5mBjIaHzI82LDwHAYzoMgwphIGJReanaMMMSMQQZj6M3Su 8fouTkaRlxDyOwI29Aft9PdU3N4ha6ATiaQ6FhHSKEEc+CoKL4NVYfIUS2eMfabq2dQPvpd4 pp8N4ek5sBGtQ5/zieiMqZdoecFesZA4gtTw/VjOSch0bk9M0chHz53b0iRXnEl+BAtEAi9t gaeuOsf9QWXxDeTWPek3rNcZozztdJoGAWtjMDvdLYzSpVSsnq8Mwfo9GNGnNnZqL0wJas6V SBSURmXtL2J4xRq7He5/WFrexIOkHyXJbgQJ402rxMQzOjIFKtbuiccZVJ6a/ArrmgOMkghJ 5Lk78Nv42hjP8KouXFhAyCLaEBbBC5TFtiPj51CrmNxjjyoXMVFzsoUp6k0y93QGU/JEGmYz VnR5Z6MJnBtSmOMUtgeQuyPH3jScJsjveOqhkEVjdKKiQGpahHoWpsJvDa2QOwetc8j1twdY eSDhGNMwNjZGfoHkCCnAHcEqCR4s0sfRTLOJptkswE54cerh/yQBtCDR4wQy8TQgzbKdge37 UQRnGUHOMcZEdGyQDOOEFALCBV7NhhwIqN8Qk2NSU6AsjjxNUGq21l2nCHEzcmN3Kfm8rEtC YVZwJIe38YPT1xF4mZulmaS1hIqS6TkBNe9zzB6ngINulDTB0bgC/IO0T4HSFC7kMWS6+HYe Qq2PUswIpbLu0Yx/QnRFhKUQV3fE06Oj1tm17Zbs1b1ZPMMGN4M9wSjFzd3dLbPKDucG2WLo Tt2ISWMN9UQzSC7PYVlUMmGEOj+PvSl6sv/6Ur3HwUxDNn8XcHX5punWr7db3cD3Qkg8O+m0 r85MXUamHCGA3QOIw2mCO28s3yPbPHFPOOv1CdYiNZCjowdLqW2I9IcIAlF8sNlllwLlOzRp CvHNZtQ80dfJ/eS42zk9qQO8VEhA7RYM1NF62aAp04EQgYM6QoNmp39c2+dFtKkjUDxVrx8E ZM4UoiGqumVbGGEOlUgFd8PLvLGlfLR6GZtAVHVbFDmrtnMQIDOvI/Iyn+wbdSSKfPRyW+Kp JxKARfLMR1VnziFciV2tBvP4XcCu7hOGIq3BcffocuUTWW9nramw7nabkYj7pHqLatnXSr3A 5obq+3I4yA2CKk4ETQzG0OLk5j+7cabD8ZhwsEUppGktASTh24T5hH0B9o1cBoSoAsn17RTD 1hDhXHiRp6eICEjcz5Ldfklgl0t/YFrTWqAaSgIe5R05YF1CvYjjFFCYMoxYS4nNgUYAjoCr 8okFp228ZzACtkPNS24ULXLWcFbkGscUNjQpN/VDiwLtMe8y2IZedQ+hSG2Dduk0Jk4SHkEZ o+gvK0uDVNJcpCkJnHCjxvTLYEVAVCW+MZ1qzopWWeLDw/2eQC+OWqkGokn/QHQOjtwU9EpP qTDjcvaApxy/CbQTWLxqO4XB+h45pDQg25T7FPtQJREeLGAm+khNLAaRMDRKHBSK9h/uSopF sFzdLfikeF8HBJccK9g6uaJtVcDu8+ID2N9ic4LTknOl1BoJSkuaUrHuDeLANRpAXUUIm50S yDcL/RkcURAIDsLxlA9cXr47/Ob2jlIem9kcxc67wlyFl1jhkFVS2IdDrSYldRIrptpesdlc XlQnJVOAWhyYXxCz6WdTSvij08E2Rl7tzTsnpU5TpXu59IvgrNlu91cXWjhLrJl+9c4PCNqY 4PtUrqOyQ4zHZGthB7SAGbm9kLK9CP0pAGdEDpT4YYqrYsBveICLdlB5JNGgwDPo/8VQuuHS wNJ8VXmICm+suHZQHT1fdkGxq2YZbgMtW9epj4PmyWbp+blguMZca6fXmOMeJxv2AWrowg/m cAnFM0Ou+6kuQxsAVahW1JGhAu3m7pChjq1F0jIurLQJV/OvtYneA3WdUy/cKlcVcx8fvlcu g9a05M71aiRmWvwLkhCncNzkym3JdV+SImQWoGtgYjhs8fef/43PdIfr959/tSaLKhw4BI02 gAGSLgV5xAPvET0vn1XtxYuV6SOojsLxDLGRync7rjUN8Sh8ktgNF3SQFSuM2wn/rXare2Xw 3wZghVExWhtL96HWXSqo4MkU+ESawZQygzvC0XYfdRiMIQjMrPbQ97ONem5t7r3ex4ppqshn T1M/kwyyFHHX1MluW+10DsHDWMWvnj9vlOMfzl91KHzHTmtzFjeHjcrJTkYz7vAaZcGjp9z7 StHrQyMWtgqL6du2aKHrQMZim8AwbDT+ME7+lKSYcs8Dobekn40Sqz4g2T+x5DrUyyXSen1a 58gOj5Uxyy2bijHLfVKdx3o7p2+CiRZuWGeo3qNafg+UK/0/ayreIfU4wiuMn1dTcdww//9U /NOn4tWafVcWvDb5zVwOAXwu6eW1juchDCBlKf9pZUArcLy6RvQcomqGlVUhUyFuKehQNgLm SjH33mlXs119xq2s66TOutbuKPzhFyzq4kp5JL/UwRpbW1+dMEpeA3ab8mS1XNcS8ZIx6vQ7 o/K3TsidHPu2CXmRVPW5XmNbgA88j0S3xpSr3bXVm4Tao2kMUB9DYbR3eA7Dl7WoarUjzTT8 CW+g47HE6ZSUAU/MfRN/4sWASfQCFpgpDd+rXst2WzQxrGRyfgvtPrf+qs4cvZ0zNzuVxjZb yN2ZK9phIsoVBAZgdUy/bPs85fb5PqNSArgAh/R5gctCd4f4kUFMF1NJJFgyAOT8SfIX3CxC FzxvFJhBCNAxg17AUCro6JpNXhSWGvD5xBe/Y6I7clgFjfOdO7raCy74HjA1VsAtyb9wCZdX 8LwTa3iqDsUXOAExJ9BWogdXC0X04Gpug37ynfMGEGqHXDq/0ngC0upTi2VVDXBPTUGc/+Uz JYSWacDL9UNBCWb+aG7fPtJNfpHhzhKpgUULsVINLZAFUJgs4SAM1jYwdyGtlfjxMwvU2xhW 4oIpZilmcoLbpihyDFDNJjNQhCZNV4gaOXkBS7UOnOPFO1hOcHqTa1SIvmDpnE3rpkPrStl4 JdxE+wLxrLetQzi2Bb804Z+9wuq96FNGnbjlEaNjiqgULC05WlBjlQpn1j635fjKL/qr9FPD vHCd27FW7pB7YhZHUCcUzsUqmRn9PgEmwLcj0EgxAL28kC9V4KUfaWwGV+duODUrzfVUy4cJ BdYvySyQ8XHFAK0GY4If6NpBFMJ6c+fEO8sZED7DZHDrBAdFAwgmhFqa75pTDLnFVRJjiNSW QOdwaasEbehuNRfZaEmySDgoLU3c3PbHjZAR0oTxj8GQzgGqoIOIDVEuL1XzTYrA2Lvp521f tuAEmNaXpqV5FKFu6Z2TnAtWlIyHPyHkz3HRtN3u8ih1gs9Hp/jMI8xkfIseKX70ohJ83zWv YAIywe/G8j8f8QsTNV39TR2x1V8TQECJn1adtJn8SGE8v/pzPMv4T7sdGs+475H/LoqWMBf4 wcWX6AngCTWs72iAetHoHPNTnNMcsUeGbn74hg9Ywj+X7f1PAAAAAP//AwBQSwMEFAAGAAgA AAAhADDdQymoBgAApBsAABUAAAB3b3JkL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0 b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Q r7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgq nASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI 6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i 1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sF fQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n02xlslii BmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fUC8iY s+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk7 5Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/H H6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvk CO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4 EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx 9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sH dTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXm lgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobo d/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+Hi CjeUyhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8 KJ8vviTPqjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHCh wGYNElx9RFU0iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81 CjJGqtAcaHNGK5rAWZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFoh sPIqnPk1azjsYEYCbXfro9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz64HiK1UrcWprs G3A7i5PK7BoL2OXeexMv5RE88xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6GxzgFr0vdR2IW wmWTr4QN+1OT2WT5zJutXDE3Cepw9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3ITzHpRClRU o7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPadvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqg X+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ieyRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/ z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsCGgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdp mLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFVElemVuwROSRsqGvgqt7bPRRBqJtq kpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01Dk9u/ELFoD2a7ql1vlud7b1kR PTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCncISH9B/Y/Knxmv3boDXXI 96G2Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQLvieMrSU7i7/Paeyi OXPZObl4kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJE0zwnUpg6KEH Jg8g+S1Hs3TjLwAAAP//AwBQSwMEFAAGAAgAAAAhAGGr0C9/BAAAjAwAABEAAAB3b3JkL3Nl dHRpbmdzLnhtbLRX247bNhB9L9B/MPRcr3WXLMQbyJLVJthtimrzAZRE20R4ESjKXufrO9Rl HXeZRdCgT6bmzJwZzgzJ8bv3z4wuTlh2RPCN5dzZ1gLzWjSEHzbW56diGVuLTiHeICo43lgX 3Fnv73/95d056bBSoNYtgIJ3Cas31lGpNlmtuvqIGeruRIs5gHshGVLwKQ8rhuSXvl3WgrVI kYpQoi4r17ZDa6IRG6uXPJkolozUUnRir7RJIvZ7UuPpZ7aQP+J3tMxF3TPM1eBxJTGFGATv jqTtZjb2X9lgi8eZ5PTWJk6Mznpnx35Lc9ruWcjmxeJHwtMGrRQ17jooEKPjdhki/IXG8V8R vaT6DlK9Gn2vNBWYO/awukbe0Vf2hmqPVXwglURyLDM0gI6C1cmHAxcSVRSa6uz41j101Fch 2OKctFjWUKSNtQ6tlZbDXsS+VEhhQLsWUzq0Z00xAq5zcpCIQWNtrFEy2DR4j3qqnlBVKtGC 0glByJFrj5T1EUlUKyzLFtXAlgmupKCzXiP+FCqDJpWQw8liaFkdzti85dj+YMERg02M0qml H0WDdWS9JK/y9N08a4MhSkjHsAezIwHHVZIGw9YoLtWF4gKCL8lXnPLmY98pAodkaOyfiOCt ADDXnj/B4X66tLjASPWQpv/J2VCJgpL2kUgp5AfeQGv8rLPVXERdTrj7mm5e/C2Emstg21vX C/J8zIVWuyK266b5VKZ/IYEX76Yuu0Uc1/HzzMTmFKEfGBEvcgKzHy8LsnRrYvN2gVMY2fxd WBSpySYI7CIIjEjue6FrQsLIjvPIiKS2EzhGZOuGTmFCotD3YiNbFPtpYYwt2jrbyJjraBvF gTE70S70UyNbHATOemeKLQ5DLzJGHWe2fryG43pb7bXrB2tj76wjz83XJpt07aWuMW9pFu0K Y79tbd+Pzch3u3cbBLu1MQdbyFtkrHbm+35k7J0sjHaRMeps7TmZMaPZzvdTs80uKEJj3nI7 CtfGmuZemBZGP3nsebYxO5CAXWi0KWwvDY2xFaltp8bsFFno5QMCd4tuBLhRWKJngr/kvNLX 9IKNV3yGWCUJWjzqqQG6hyWV/LIlfMYrDFMT/hYp+2oGl8sR6BiitIB3bAaGo8CShnRtjvcD LX1E8nDlnTSkUQpv5scXLv0EY/m7FH07ejtL1I7X7+zO8f2Jj3D1QNgs7/qqnK04vPzfQD1v Pp2kJlxd03NOFAyMwzP2gPhhvmUxX34utSrc1lSWeqjEj6ht4bkGlergbCxKDkfl6KdHwVcD w+XwUR3cCXMHDL40NnygWu8MtKeFVhiXoDUtrjJvlnlXGYxOo55/lQWzLLjKwlkGw+05OcJb KWFw+QIDwbzU8r2gVJxx88cs3FivRGMSuiNqMdRVzzXQXiIZBNOg0y1OCX6GoQk3RMHM3pKG oWcY6W13uJ4mbYouolc3uppJK7c30kWDFALzoVQ3xlA6mMJuYzknDa4JtGN5YdV1jLobA6ek UyVuYeJSQsKWhyHnt4H5+jfi/h8AAAD//wMAUEsDBBQABgAIAAAAIQDzDYbz1gEAABgLAAAU AAAAd29yZC93ZWJTZXR0aW5ncy54bWzsVs1u2zAMvg/YOxi6N/6R7ThGnQJB0WHAMAxr9wCK LCdCJdGQlHjp04+x2y5dd4iBFujBJ1MU+ZnkJ0q8vPqtVbAX1kkwFYlnEQmE4VBLs6nIr7ub i4IEzjNTMwVGVOQgHLlafv502ZWdWN8K79HSBYhiXKl5Rbbet2UYOr4VmrkZtMLgZgNWM49L uwk1s/e79oKDbpmXa6mkP4RJFOXkEcaegwJNI7m4Br7TwvjeP7RCISIYt5Wte0LrzkHrwNat BS6cw3y0GvA0k+YZJk5fAWnJLTho/AyTCYeIwiMUusdRL2lFAs3LrxsDlq0VVrCLU7LE8tVy 7x6/QVfKuiLzaE7pIk367TXUh2u5x609U8gMCY/GWLtvovFP2uhZ+1Nutv9R30H72nYF3oP+ R4/hrGp7/If/62OQc4KG7qEieDJQaBnHHHqZgwKkiu08DGGok8jGea5fRDTO155mPsY17Dno kx7El2ykcZIvFkk00THqELwbHXlUZLRYxFN3jOnJ96JjUcxzSrOUTnR8BDriOMsozdNiao8P cVslUZZQOqfJ8NZPj/mZI8RbXlfDo97PWNB6qeWDuAG7stA5YftpiikF3Y/vX3CBxifz7PIP AAAA//8DAFBLAwQUAAYACAAAACEA3xUsB6oIAACPQQAAGgAAAHdvcmQvc3R5bGVzV2l0aEVm ZmVjdHMueG1szFxbc9u2En4/M+c/cPju6GJXajxVOrFdN55J2zSyp88QBVkckwQPL3acX9/F goQoUiR3TWbmPMkEgf12sbvfQgo2v/z6LQycZ5mkvopW7uzd1HVk5KmtHz2u3If727OfXSfN RLQVgYrkyn2Vqfvrh//+55eXyzR7DWTqgIAovXyJvZW7z7L4cjJJvb0MRfou9L1EpWqXvfNU OFG7ne/JyYtKtpP5dDbFv+JEeTJNAe1aRM8idQtxYVOaimUEWDuVhCJL36nkcRKK5CmPz0B6 LDJ/4wd+9gqyp4tSjFq5eRJdFgqdWYX0kkujUPFRrkgaVpzANStvlJeHMsoQcZLIAHRQUbr3 44MZb5UGJu5LlZ67jHgOg3LeSzy7aOBZkyk+uEnEC7jiILAh7sRmbM2iMDD7oP178Gpd4mza ZUzhES3C6kBR4Riz1CQUfmTFvG1rqpsL+TAkvn9PVB5bdWJ/mLS76MnK0mnJ0Gy6wMyrmpay BDRSd70XsXSd0Lu8e4xUIjYBaPQyu3B0RLofgCq2yruRO5EHWaofky9J8Vg84cetirLUebkU qef790AhICX0QeCnj1Hqu/BGijT7mPri5Mu9nnXyjZdmFWlX/tZ3Jxox/Q4yn0WwcufzcuRa a3A0FojosRyT0dnDuqrJyrVDG5C7ckVytv6ohU3QzPKzYm58ZDw8oSqx8CDzAEfsMgkkBCym cQJfe3e+BEYzD19zvbkiz1QBggIArCoWHms7DtwETLU2jA1v5e6z8p7kdp3Bi5WLWDD4cPcl 8VUCNLpy37/XmDC4lqH/yd9upS4QxdhDtPe38p+9jB5SuT2M/32L9FxI9FQeZaD+YolREKTb 3755MtY0CaIjoT38p14AHAbuqOCgQrl/0MYM1FBx8H8l5Mz48CTKXgpd0hzUvxMIrc4HA821 RVUDUC5L1/PhIi6Gi/hpuAgM3mF7sRyuBRxkhnrExEYlKulOzZRngq+6D+fvO0JWr2hEUe+K RtD0rmjESO+KRkj0rmhEQO+KhsN7VzT827ui4c7OFZ5A4qpH0TnuBimx7/0sgDrZw3SzgVRX lBrni0jEYyLivaMLa13tLrJc55uMpirS6dvJcp0lSh83e3YEqrNO3Tdz8m9hvBepD6fyPqCB W3+vjz7O74kPx9ceqJ9M8DVswoPJyRL2JRCe3KtgKxPnXn4zHmWs/1M5a3PK6FVuoFs/+4/7 zIFToS65vWCLlk1v3wkj/7Of4h50VvNFiyl9wkk+XLTEZbvwP+TWz8NyawinkYXhc4abaxCo YvcWXWgXNbOr1wrtAIoJplzwTUD5BP1NceHL1z6m6G9K0RvlE/Q3heuN8jE+uv3LZpob+FnF IaXXkp271ypQyS4PyhzopYclO4MtBM0EdhJb+SSSWLIz+Ig+nY+eB9/cKHHK9sWBRxkobHcY FEw2ui1sp9Rob8awiO2gGtacgTWMaxlAbNL9Kp99/SMwtxggS9uzZm86n7fsAJQg0hn671xl /WfoeQvnUVHuIvi5JJUODe28JfOoaEU8mXrH8PGwwscAGlYBGUDDSiEDqCU+2s88tibSQYYX RwYWm5ZtFcOwIzPzks3MFohXAkaqm4TzV0v2tsdCs24SUNgOatZNAgrbO7VaZusmAWu0uknA aqka7T6qcirHKHbdrALZkwDBonHImwA0DnkTgMYhbwLQcPLuBxmPvAlYbG6wnFolbwIQTuF8 1bdAVfImALG5wbBd8ZtRWfdQSveX2xHIm4DCdlCTvAkobO+0kTcBC6dwIqGGZamOgDUOeROA xiFvAtA45E0AGoe8CUDjkDcBaDh594OMR94ELDY3WE6tkjcBiE0PFqhK3gQgnMLhhpPkjVn/ w8mbgMJ2UJO8CShs79QI1R5SCVhsB9WwLHkTsHAKJxgKLAxujlHjkDfBonHImwA0DnkTgMYh bwLQcPLuBxmPvAlYbG6wnFolbwIQmx4sUJW8CUBsbjhJ3piMP5y8CShsBzXJm4DC9k6NUC3P EbDYDqphWfImYGG8DCZvAhBOeSsQx6JxyJtg0TjkTQAah7wJQMPJux9kPPImYLG5wXJqlbwJ QGx6sEBV8iYAsbnhJHljjvxw8iagsB3UJG8CCts7NUK15E3AYjuohmWpjoA1DnkTgDAwB5M3 AQinvAEIs4jjpnHIm2DROORNABpO3v0g45E3AYvNDZZTq+RNAGLTgwWqkjcBiM0N+p4t3Bcl X0+dtQQB9Z5BeauBDDhvcRIVsDDwq9zJBLoKZf/tkIGApYUMxJbwoJp4pdSTQ7vYfd4SIGQo fxP4Cq90v+ItnUojwvmyo5Pg/q9r55NpgGmsw5A6vnkD3UPVdiFsT9KNQ6Bn9hpDy05c3izX 0qBBSPd1FS1A2BN6Bw1BRVuPXqz7fGAiNlUVw/jvtgUq/A2IuLAJ5e0By4OOqA6o4sK7vYOE 193rwC234lGRQ0tGqWZxO/5whjLzju5oduqd6ZvgHTrjTfHOPXJwivFqU0FozkKV+jQEl20C 02IGf9xFW7DwpejOMs7cfhNGFLy/lkHwh8CGtEzF7VMDucvM29kUK2BN1EZlmQrb1yd4QRw1 OSUAwqGqjHnURrTHSZSHG5kU181bQ1JXDuxEOw5Jc9e1JRSoO92u21G62AS5EkGgVIQ3+evB Wrwz1/xRr42ANru/dNdcI42gRfCpHK8IvYbMGR490BeuQwZBp9Ob6XLx/spIbWtcxH+QLdoW L+zD6bbFokUSPo56P1fuvdirUOj8wa7O6oAHzarFa5MBtolztihy4vuhidOMgW+g5bQrfo54 xstTCF9slqzTWn2DuzznHFxQc99JxkJrWpzJdGS713Ab/t/22+bEJygvid6CRpIe3pxKh/b9 bGfO468hKPV42xZX88Xs1ux8sW2evrx+SIfp9PZWxyh2F+OpEfqorQkoMi9n6//iACoCDDaD saSO9MO/AAAA//8DAFBLAwQUAAYACAAAACEArpL2Y4QBAADvAgAAEQAIAWRvY1Byb3BzL2Nv cmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA hJLBTsMwDIbvSLxDlXuXpkMIqq1IgDgxCWlDIG5ZYkagTaLE0O3tcdutrAiJW2z//mL/yexq W1fJF4RonJ0zMclYAlY5bexmzh5Xd+kFSyJKq2XlLMzZDiK7Kk9PZsoXygV4CM5DQAMxIZKN hfJz9oboC86jeoNaxgkpLBVfXaglUhg23Ev1ITfA8yw75zWg1BIlb4GpH4hsj9RqQPrPUHUA rThUUIPFyMVE8B8tQqjjnw1d5UhZG9x52mk/7jFbq744qLfRDMKmaSbNtBuD5hf8eXG/7FZN jW29UsDKmVYFGqygnPGfI53i5/odFPbpIaCCCiDRhRJcXLtgoes7JFu7P2DXuKAjtY4i6tUQ VTAe6RF78ChB6kpGXNCrvhrQ17tyqRxispA2UqLSHfCXpL0xwJdpP0aZZ51kiGm7zsx+aNAJ 2VP0Zh4qT9Ob29Udo1aRpyJLp2IlzgqRFVn20q426m/t6hP1fsh/iSLNL1ciL8TlmHgA9C6N v2j5DQAA//8DAFBLAwQUAAYACAAAACEAB+2OKCEIAACePgAADwAAAHdvcmQvc3R5bGVzLnht bMxb23KbSBB936r9B4p3Rxc70toVJeVLvHFVLk5k1z6PYGRRBkYLKLbz9dvTg0YIBHQbUrVP FgPTp6+nkTz97sNzFDo/ZZIGKp65ozdD15Gxp/wgfpi593fXR3+5TpqJ2BehiuXMfZGp++H9 n3+8ezpLs5dQpg4IiNOzyJu5qyxbnw0GqbeSkUjfqLWM4eZSJZHI4DJ5GEQiedysjzwVrUUW LIIwyF4G4+Fw4uZiEooUtVwGnrxS3iaScYb7B4kMQaKK01WwTrfSnijSnlTirxPlyTQFo6PQ yItEEFsxo5OKoCjwEpWqZfYGjBkYjQZaFGwfDfFTFLpO5J3dPMQqEYsQnPc0OnHfg+d85V3J pdiEWaovk9skv8yv8M+1irPUeToTqRcEd+BSEBAFIOvTeZwGLtyRIs3O00AcvLnSTx2846VZ QdpF4AfuQCOmv0DmTxHO3PF4u3KpNdhbC0X8sF2T8dH9vKjJzLVLC5A7c0VyND/XwgZo5vZv wdz1nvFwhaqshQfBAByxzCQkBeSIxgkDnYPjKeSLufix0X4Vm0zlICgAwIpi4bLkccgVyJy5 SWC4K5eflfco/XkGN2YuYsHi/c1tEqgEknTmnp5qTFicyyj4FPi+1PWSr93Hq8CX/6xkfJ9K f7f+/RqTP5foqU2cgfqTKWZBmPofnz251mkLomOhI/xVb4DEgXAUcFChTbDTxiyUUHHx3y3k yMTwIMpKCl3hDurfCIRWbzoDjbVFRQNQLkvX4+4iTrqLeNtdBCZvN19Mu2sBvN41IiY3CllJ D2qmPJN8RT8cnzakrN5RyaLWHZWkad1RyZHWHZWUaN1RyYDWHZWAt+6oxLd1RyWcjTs8gcRV zqJj9AapsO+CLJR6fyMBjTpSXd5qnFuRiIdErFeObqxltZvIcr5ZZDRVkU5fT5bzLFHxQ6tH oDvr0n01J3+M1iuRBvCW1OL6cUfX3+m3HufvJPBbod6a5KvYhC8mB1vYbSg8uVKhLxPnTj6b iDL2f1XO3LxltCrXMayfg4dV5sxX2HJbwSY1Tq/3hJH/OUjRB43FNKkxpU04KYaTmrysF/5F +sEm2rqG8DYyMXzOCHMJAlVsdtGJDlG1ulqt0AGgmGDaBd8ElE/Q3zQXvnwdY4r+phW9Uj5B f9O4Xikf86M5vmymuYIvrQ6pvKbs2r1UoUqWm3BbA630MGVXsIWgmcAuYiufRBJTdgXv0adz 7nnwzY2Sp+xY7HiUgcIOh0HBYqPbwg5KifZGDIvYASphjRlY3biWAcQm3R/yZ6B/E+M2A2Rp +67ZWs7HNR6AFkR6h/6+UVn7O/S4hvOoKDcx/FySSoeGdlxTeVS0PJ9Mv2PEuFvjYwB164AM oG6tkAFUkx/17zy2J9JBujdHBhablm0Xw7QjM/OUzcwWiNcCeuqbhPevmuqtz4Vq3ySgsANU 7ZsEFHZ0Sr3M9k0CVm99k4BV0zXqY1TkVI5R7L5ZBLJvAgSL+iFvAlA/5E0A6oe8CUDdybsd pD/yJmCxucFyapG8CUD4COervgUqkjcBiM0Nhu3y34y2fQ+lNH+57YG8CSjsAFXJm4DCjk4d eROw8BFOJpSwLNURsPohbwJQP+RNAOqHvAlA/ZA3Aagf8iYAdSfvdpD+yJuAxeYGy6lF8iYA senBAhXJmwCEj3C44SB5Y9X/dvImoLADVCVvAgo7OiVCtS+pBCx2gEpYlrwJWPgIJxlyLExu jlH9kDfBon7ImwDUD3kTgPohbwJQd/JuB+mPvAlYbG6wnFokbwIQmx4sUJG8CUBsbjhI3liM v528CSjsAFXJm4DCjk6JUC3PEbDYASphWfImYGG+dCZvAhA+8logjkX9kDfBon7ImwDUD3kT gLqTdztIf+RNwGJzg+XUInkTgNj0YIGK5E0AYnPDQfLGGvnt5E1AYQeoSt4EFHZ0SoRqyZuA xQ5QCctSHQGrH/ImAGFidiZvAhA+8gogrCJOmPohb4JF/ZA3Aag7ebeD9EfeBCw2N1hOLZI3 AYhNDxaoSN4EIDY36HO2cF6UfDx1VJME1HMG21MNZMBxTZCogLmBP+RSJjBkJdtPh3QE3FrI QKxJD6qJF0o9OrSD3cc1CUKGChZhoPBI9wue0ikMIhxPGyYJ7r5dOp/MAExlH6bU/skbmB4q jgvheJIeHAI9s5c1jOystyfLtTQYENJzXfkIEI7I3cBAUD7WozfrOR94EIeq8mX8v22OCp8B ETdWobwVYHkwEdUAlR94t2eQ8Lh7GbjmVDwqshvJ2KqZn47fvUOZ5/bOaDbqnemT4A0640nx Rh85+IiJalVBGM5Cldo0hJAtQjNiBh9uYh8shCFB/K+ZCab/LIwouH8pw/CLwIG0TK3rHw3l MjN3R0PsgCVRC5VlKqrfn+ABcdTkkABIh6Iy5lIbUZ8n8SZayAQmvBp8/lXpzoGTaPspac66 1qQC1dP1uu2Viy2QCxGGSsV4kr+crPk9c8wf9VoIGLP7pqfmKmUEI4KP2/WC0EuonO7ZA2Oy OmUQdDi8Gk4npxdGat3gIqZWPrZ4Yi8Ojy3mI5LwZ2/2c+beiZWKhI4lTnUWF7zUXpkKsEOc o0leE792Q5xmDWIDI6dN+bPHM94mhfTFYckyrZUd3BQ5ZxeCUvgOMhZaUxNMZiDro4Zu+L/5 29bEJ2gviXZBpUh3dw6VQ70/65lz/2sISt132+RiPBldG8/nbvP04fVdOQyH19c6R3G6GN8a YWramoAiN9un9ag1dARYrCbjljrS9/8BAAD//wMAUEsDBBQABgAIAAAAIQDQuFjG8gEAALsF AAASAAAAd29yZC9mb250VGFibGUueG1snJPfbtowFMbvJ/UdIt+XOCHtWtRQdWxIu9nFxB7A GIdY9Z/Ix5Dx9ju2Q3qB0EhBiuA79qdzfvnOy+tfrbKjcCCtqUkxoyQThtudNPua/Nms759I Bp6ZHVPWiJqcBJDX5d2Xl37RWOMhw/sGFprXpPW+W+Q58FZoBjPbCYPFxjrNPP51+1wz937o 7rnVHfNyK5X0p7yk9JEMNu4WF9s0kovvlh+0MD7ez51Q6GgNtLKDs1t/i1tv3a5zlgsAnFmr 5KeZNKNNUV0YacmdBdv4GQ6Tp47yYIXXCxp/aUUyzRc/98Y6tlXIri8qshzAZf3CMI3iiim5 dTIWOmYsiAJrR6ZqQku6pg/4DN+KzsOT5MGBt8yB8ONBmuSGaalOZxV6CZAKnfS8PetH5mRo KJVA7rFwgC2tyY+CUlqu1yQpRU0qFN5Wo1JiU+nzPJyZjwomBxuLPvFI8Rx9UEGf4VbsM0/R uSCxkVpA9kv02W+rmblCpKSPSOIBeQQy80lEXPSNBG8lgo2Xb+P8OMkKla9PVTHMP4lI8plA hLXY8RUQ3xBECEVAUX0+Gsb6jTuIzakTU8AML3T+EZXxFafwfICJwcCAXY8KpRHn7WBWTOPO XCMTopG4hKhMW5rPReRyaWg1hmYKif8vzbA9sPwHAAD//wMAUEsDBBQABgAIAAAAIQDGltBN 9gEAAPYDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CDonpuy6iWHQDAIHRQq0jQEpyZml VjZRiiTIjRH367uUYllOe6pOsw8Nh7NLfvPammwPIWpnV/l0UuQZWOVqbber/LH6crnIs4jS 1tI4C6v8ADG/ER8/8E1wHgJqiBlR2LjKd4h+yVhUO2hlnFDZUqVxoZVIYdgy1zRawZ1TLy1Y ZLOiuGLwimBrqC/9QJj3jMs9/i9p7VTSF5+qgyfBglfQeiMRxI8kx0xqhy1nQ5ZXDqWpdAti WlwtqDLEfCO3EMUnznrAn12oo7heUKaHfL2TQSokE8V8nv4eJfit90YrieSv+K5VcNE1mD10 TmSJgLNxCyd3SlAvQeNBFJyNQ/5N2yTlmrMekbYgt0H6XSTdSeEQ8lJJA2syQTTSRODslOD3 INOAN1KTZL7H5R4UupBF/ZtGPMuznzJCsm6V72XQ0iJZmNr6oMPGRwyi0miIm2p93MFx2xjr uZh2DQTOGxNBr4EK5+q6E+JDQ3fDf4idjsV2GnqpIzkjOJzxjnXtWi/tQax1VC4rDxGhjRfZ V6smNM23YrL/V3z0lbtLm/Rm63lytAvPGnell4om9nk2p4uftmJU4iUtD9Q05iPhKcHvaQTB pFPpX7uF+tjzdyHt2VP/jMV0Pino6xbrmKPlGN6X+AMAAP//AwBQSwECLQAUAAYACAAAACEA CSSHgoEBAACOBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQIt ABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAALoDAABfcmVscy8ucmVsc1BL AQItABQABgAIAAAAIQAfBa+pZwEAAOEFAAAcAAAAAAAAAAAAAAAAAN4GAAB3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABtIaHdAEQAAdDsAABEAAAAAAAAA AAAAAAAAhwkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsA ABUAAAAAAAAAAAAAAAAA9hoAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAA IQBhq9AvfwQAAIwMAAARAAAAAAAAAAAAAAAAANEhAAB3b3JkL3NldHRpbmdzLnhtbFBLAQIt ABQABgAIAAAAIQDzDYbz1gEAABgLAAAUAAAAAAAAAAAAAAAAAH8mAAB3b3JkL3dlYlNldHRp bmdzLnhtbFBLAQItABQABgAIAAAAIQDfFSwHqggAAI9BAAAaAAAAAAAAAAAAAAAAAIcoAAB3 b3JkL3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQCukvZjhAEAAO8CAAAR AAAAAAAAAAAAAAAAAGkxAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQAH7Y4o IQgAAJ4+AAAPAAAAAAAAAAAAAAAAACQ0AAB3b3JkL3N0eWxlcy54bWxQSwECLQAUAAYACAAA ACEA0LhYxvIBAAC7BQAAEgAAAAAAAAAAAAAAAAByPAAAd29yZC9mb250VGFibGUueG1sUEsB Ai0AFAAGAAgAAAAhAMaW0E32AQAA9gMAABAAAAAAAAAAAAAAAAAAlD4AAGRvY1Byb3BzL2Fw cC54bWxQSwUGAAAAAAwADAAJAwAAwEEAAAAA --------------010301040806040506000103-- ------------=_1355320545-4561-1-- From kishoret@juniper.net Wed Dec 12 08:04:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED821F89B5 for ; Wed, 12 Dec 2012 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWiw9ZPjEjZ4 for ; Wed, 12 Dec 2012 08:04:53 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89721F8978 for ; Wed, 12 Dec 2012 08:04:53 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUMirJZzQy7dsbkmYvgppX4pHFseJmZ5t@postini.com; Wed, 12 Dec 2012 08:04:53 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 08:01:25 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 12 Dec 2012 08:01:25 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.204) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 12 Dec 2012 08:03:34 -0800 Received: from mail34-am1-R.bigfish.com (10.3.201.241) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 12 Dec 2012 16:01:20 +0000 Received: from mail34-am1 (localhost [127.0.0.1]) by mail34-am1-R.bigfish.com (Postfix) with ESMTP id 2F728601D5 for ; Wed, 12 Dec 2012 16:01:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz9371I542I1432I4015I62a3Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail34-am1 (localhost.localdomain [127.0.0.1]) by mail34-am1 (MessageSwitch) id 1355328078298033_15364; Wed, 12 Dec 2012 16:01:18 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.251]) by mail34-am1.bigfish.com (Postfix) with ESMTP id 3C68E460055; Wed, 12 Dec 2012 16:01:18 +0000 (UTC) Received: from BY2PRD0512HT003.namprd05.prod.outlook.com (157.56.238.5) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 12 Dec 2012 16:01:13 +0000 Received: from BY2PRD0512MB640.namprd05.prod.outlook.com ([169.254.4.42]) by BY2PRD0512HT003.namprd05.prod.outlook.com ([10.255.243.36]) with mapi id 14.16.0245.002; Wed, 12 Dec 2012 16:01:12 +0000 From: Kishore Tiruveedhula To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-ldp-dod Thread-Index: AQHN0sjuT//0KPoqIkKgB9viXURzLZgVXT/g Date: Wed, 12 Dec 2012 16:01:11 +0000 Message-ID: References: <50BF105F.5030004@pi.nu> In-Reply-To: <50BF105F.5030004@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PI.NU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-dod@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 16:04:54 -0000 I am not aware of any related IPR on draft-ietf-mpls-ldp-dod. Thanks, Kishore >-----Original Message----- >From: Loa Andersson [mailto:loa@pi.nu] >Sent: Wednesday, December 05, 2012 4:14 AM >To: mpls@ietf.org >Cc: draft-ietf-mpls-ldp-dod@tools.ietf.org; mpls-chairs@tools.ietf.org; >Adrian Farrel; Martin Vigoureux >Subject: IPR poll on draft-ietf-mpls-ldp-dod > >Working Group and authors; > >The authors of draft-ietf-mpls-ldp-dod has indicated that the draft is >ready for working last call. > >Before starting the working group last call we will do an IPR poll to >check whether there is IPR on the document that needs to be disclosed. > >This mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-ldp-dod? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >documents will not advance to the next stage until a response has been >received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >(as MPLS WG co-chair) >-- > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From wwwrun@rfc-editor.org Wed Dec 12 09:53:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085BB21F84F3 for ; Wed, 12 Dec 2012 09:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjDrJ7T+Uuse for ; Wed, 12 Dec 2012 09:53:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8600121F8444 for ; Wed, 12 Dec 2012 09:53:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2DCABB1E002; Wed, 12 Dec 2012 09:44:31 -0800 (PST) To: sboutros@cisco.com, msiva@cisco.com, raggarwa_1@yahoo.com, martin.vigoureux@alcatel-lucent.com, dai.xuehui@zte.com.cn, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20121212174431.2DCABB1E002@rfc-editor.org> Date: Wed, 12 Dec 2012 09:44:31 -0800 (PST) Cc: mpls@ietf.org, daviball@cisco.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:53:13 -0000 The following errata report has been submitted for RFC6435, "MPLS Transport Profile Lock Instruct and Loopback Functions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 -------------------------------------- Type: Editorial Reported by: David Ball Section: 4 (para 5) Original Text ------------- It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs. Corrected Text -------------- It should be noted that the data-plane loopback function may be applied at MIPs/MEPs on different interfaces for different LSPs. Notes ----- The existing text has caused confusion (specifically, among experts in ITU-T SG15 when discussing G.8121.2), in that it seems to suggest that the interface where the MIP/MEP is located may be a different interface to the one where the loopback is applied. Having spoken with some of the original authors, it seems this was not the intent of this sentence; the intent was to point out that as different LSPs would have MIPs/MEPs on different interfaces, the corresponding loopback functions would also be applied on different interfaces. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6435 (draft-ietf-mpls-tp-li-lb-08) -------------------------------------- Title : MPLS Transport Profile Lock Instruct and Loopback Functions Publication Date : November 2011 Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From adrian@olddog.co.uk Wed Dec 12 10:17:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49D221F892B for ; Wed, 12 Dec 2012 10:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJZdrosRcaeP for ; Wed, 12 Dec 2012 10:17:19 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 810E621F8903 for ; Wed, 12 Dec 2012 10:17:19 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCIH8x6022618; Wed, 12 Dec 2012 18:17:08 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBCIH7UR022612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Dec 2012 18:17:07 GMT From: "Adrian Farrel" To: , , , , , , , , References: <20121212174431.2DCABB1E002@rfc-editor.org> In-Reply-To: <20121212174431.2DCABB1E002@rfc-editor.org> Date: Wed, 12 Dec 2012 18:17:05 -0000 Message-ID: <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCcDSjnMquaGJduJ8hwYvwn8ZScGZp5DsNw Content-Language: en-gb Cc: mpls@ietf.org, daviball@cisco.com Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 18:17:20 -0000 Hello, Authors of RFC 6435: I need to hear from you that you meant the text that David suggests. It is very clearly not what you wrote and, if you meant something different, it is clear why people are confused! Working group: I need to hear from you that you agree with David's interpretation and support his proposed change. Only then will I try to work out whether this is a "typo" worthy of an errata report, or a technical change needing a revised RFC. Thanks, Adrian > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 12 December 2012 17:45 > To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > rcallon@juniper.net > Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC6435 (3429) > > > The following errata report has been submitted for RFC6435, > "MPLS Transport Profile Lock Instruct and Loopback Functions". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > > -------------------------------------- > Type: Editorial > Reported by: David Ball > > Section: 4 (para 5) > > Original Text > ------------- > It should be noted that the data-plane loopback function itself is applied to data- > plane loopback points residing on different interfaces from MIPs/MEPs. > > Corrected Text > -------------- > It should be noted that the data-plane loopback function may be applied at > MIPs/MEPs on different interfaces for different LSPs. > > Notes > ----- > The existing text has caused confusion (specifically, among experts in ITU-T SG15 > when discussing G.8121.2), in that it seems to suggest that the interface where > the MIP/MEP is located may be a different interface to the one where the > loopback is applied. > > Having spoken with some of the original authors, it seems this was not the intent > of this sentence; the intent was to point out that as different LSPs would have > MIPs/MEPs on different interfaces, the corresponding loopback functions would > also be applied on different interfaces. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6435 (draft-ietf-mpls-tp-li-lb-08) > -------------------------------------- > Title : MPLS Transport Profile Lock Instruct and Loopback Functions > Publication Date : November 2011 > Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, > Ed., X. Dai, Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG From Thomas.Beckhaus@telekom.de Thu Dec 13 00:48:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DE721F8A50 for ; Thu, 13 Dec 2012 00:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3PrQ5SGHKKk for ; Thu, 13 Dec 2012 00:48:20 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1521F8561 for ; Thu, 13 Dec 2012 00:48:19 -0800 (PST) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 13 Dec 2012 09:48:17 +0100 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 13 Dec 2012 09:48:16 +0100 From: To: , Date: Thu, 13 Dec 2012 09:48:15 +0100 Thread-Topic: IPR poll on draft-ietf-mpls-ldp-dod Thread-Index: Ac3SyOqKxd/KGl3TSY+qP/9BYzmvHAFu0Eyw Message-ID: References: <50BF105F.5030004@pi.nu> In-Reply-To: <50BF105F.5030004@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 08:48:21 -0000 Hi Loa, Hi all, I'm not aware of any IPR. Regards Thomas > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, December 05, 2012 10:14 AM > To: mpls@ietf.org > Cc: draft-ietf-mpls-ldp-dod@tools.ietf.org; > mpls-chairs@tools.ietf.org; Adrian Farrel; Martin Vigoureux > Subject: IPR poll on draft-ietf-mpls-ldp-dod > Importance: Low > > Working Group and authors; > > The authors of draft-ietf-mpls-ldp-dod has indicated that the draft is > ready for working last call. > > Before starting the working group last call we will do an IPR poll to > check whether there is IPR on the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-ldp-dod? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please > respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an > author or > contributor, then please explicitly respond only if you are > aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > From loa@pi.nu Fri Dec 14 01:01:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4724521F86FA for ; Fri, 14 Dec 2012 01:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTB7DUbu1TU4 for ; Fri, 14 Dec 2012 01:01:10 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id AD11321F86F7 for ; Fri, 14 Dec 2012 01:01:10 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 71B4E8244C; Fri, 14 Dec 2012 10:01:06 +0100 (CET) Message-ID: <50CAEAD4.6000705@pi.nu> Date: Fri, 14 Dec 2012 10:01:08 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 09:01:11 -0000 Working group, This is to start a "two week" poll on adopting draft-xu-mpls-in-udp-06 as an MPLS working group document. Due to the holiday season this poll has been extended with one week. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends January 07, 2013. There is one IPR claim against this document - https://datatracker.ietf.org/ipr/1941/ . All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However, up to version -03 (the document that we used for the IPR poll) Marshall Eubanks was listed as one of the authors. Marshall has discontinued all interactions with the IETF, including the author team of draft-xu-mpls-in-udp-06. The working group chairs has tried to contact Marshall by other means, to try get a response on the IPR poll. We have had no success in this. From version -04 the authors decided to remove Marshall as a co-author. /Loa (mpls wg co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lucy.yong@huawei.com Fri Dec 14 07:56:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78E21F8870 for ; Fri, 14 Dec 2012 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjoZAyYLdap8 for ; Fri, 14 Dec 2012 07:56:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAEA21F8865 for ; Fri, 14 Dec 2012 07:56:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANV56403; Fri, 14 Dec 2012 15:56:48 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 15:55:49 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Dec 2012 15:56:45 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Fri, 14 Dec 2012 07:56:43 -0800 From: Lucy yong To: Loa Andersson , "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmX32Lutv/oaEGki3jzw9v3K5gYc1og Date: Fri, 14 Dec 2012 15:56:42 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44863065@dfweml505-mbx> References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:56:52 -0000 Support as one of co-authors. Lucy > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Friday, December 14, 2012 3:01 AM > To: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux > Subject: [mpls] poll to see if we have support to make draft-xu-mpls- > in-udp an mpls working group document >=20 > Working group, >=20 > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends January 07, 2013. >=20 > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. >=20 > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. >=20 > From version -04 the authors decided to remove Marshall as a co-author. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From koike.yoshinori@lab.ntt.co.jp Fri Dec 14 09:40:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC921F897B for ; Fri, 14 Dec 2012 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4NZoPhVFOTu for ; Fri, 14 Dec 2012 09:40:43 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0621F85B3 for ; Fri, 14 Dec 2012 09:40:42 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id qBEHeaeG019334; Sat, 15 Dec 2012 02:40:36 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B76F2E0159; Sat, 15 Dec 2012 02:40:36 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9EE41E0154; Sat, 15 Dec 2012 02:40:36 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id qBEHeaSx015943; Sat, 15 Dec 2012 02:40:36 +0900 Message-ID: <50CB6508.10804@lab.ntt.co.jp> Date: Sat, 15 Dec 2012 02:42:32 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mpls@ietf.org, daviball@cisco.com References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> In-Reply-To: <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:40:44 -0000 Hello David, I agree with original text is confusing and thank you for the proposal. However, I'm wondering if the proposed text is true and exactly reflect the intent explained in the notes. My suggestion is as follows: It should be noted that the data-plane loopback function itself is applied to data-plane loopback point which is different from MIP/MEP. Firstly, the description "the data-plane loopback function may be applied at MIPs/MEPs" doesn't seem to be true. In my understanding, data-plane loopback function can be set/enabled/disabled at MIP/MEP using a management system but not be applied to MIP/MEP itself. So I clarified this point in my proposal. One of the reason is that MIP/MEP is only involved in OAM packets. There seems no specification in any RFC, which describe that MIP/MEP could handle data packets which are not OAM packets . In G.8121 amd1, data-plane loopback sink and source are specified and according to Temporary Document(TD673R1<->R0/Plen) during last SG15 meeting, the data-plane loopback sink/source was removed from figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be to avoid a restriction of implementations, however it doesn't seem to make it possible to apply dataplane loopback point to MIP/MEP. In realty, if data-plane loopback function is enabled, for data-plane LB function there is no need to parse the packet except for outermost label value. Secondly, if you need to clarify the relationship between data-plane LB point at which data-plane LB function is conducted and MIP/MEP at which data-plane LB function is enabled/configured using management system, it seems enough just to say the two point usually resides on the same interface and clarify the binding of two points. I have no issue on this specification. However, just in case, it seems better to confirm if the change is ok in ITU-T joint interregnum meeting Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a result, I didn't add related text in my proposal. I'm not an implementer, so I would appreciate it if you could correct me if I'm wrong. Thank you in advance. Best regards, Yoshinori (2012/12/13 3:17), Adrian Farrel wrote: > Hello, > > Authors of RFC 6435: I need to hear from you that you meant the text that David > suggests. It is very clearly not what you wrote and, if you meant something > different, it is clear why people are confused! > > Working group: I need to hear from you that you agree with David's > interpretation and support his proposed change. > > Only then will I try to work out whether this is a "typo" worthy of an errata > report, or a technical change needing a revised RFC. > > Thanks, > Adrian > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 12 December 2012 17:45 >> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >> rcallon@juniper.net >> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC6435 (3429) >> >> >> The following errata report has been submitted for RFC6435, >> "MPLS Transport Profile Lock Instruct and Loopback Functions". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >> >> -------------------------------------- >> Type: Editorial >> Reported by: David Ball >> >> Section: 4 (para 5) >> >> Original Text >> ------------- >> It should be noted that the data-plane loopback function itself is applied to > data- >> plane loopback points residing on different interfaces from MIPs/MEPs. >> >> Corrected Text >> -------------- >> It should be noted that the data-plane loopback function may be applied at >> MIPs/MEPs on different interfaces for different LSPs. >> >> Notes >> ----- >> The existing text has caused confusion (specifically, among experts in ITU-T > SG15 >> when discussing G.8121.2), in that it seems to suggest that the interface > where >> the MIP/MEP is located may be a different interface to the one where the >> loopback is applied. >> >> Having spoken with some of the original authors, it seems this was not the > intent >> of this sentence; the intent was to point out that as different LSPs would > have >> MIPs/MEPs on different interfaces, the corresponding loopback functions would >> also be applied on different interfaces. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >> -------------------------------------- >> Title : MPLS Transport Profile Lock Instruct and Loopback > Functions >> Publication Date : November 2011 >> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > Vigoureux, >> Ed., X. Dai, Ed. >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From adrian@olddog.co.uk Fri Dec 14 10:35:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9508221F8A7C for ; Fri, 14 Dec 2012 10:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxoZxvebndhu for ; Fri, 14 Dec 2012 10:35:52 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D5B8E21F8A75 for ; Fri, 14 Dec 2012 10:35:51 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEIZmhZ014660; Fri, 14 Dec 2012 18:35:48 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBEIZl8i014651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 18:35:48 GMT From: "Adrian Farrel" To: Date: Fri, 14 Dec 2012 18:35:45 -0000 Message-ID: <015a01cdda29$d4ef0180$7ecd0480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3aKdIxxdBnBnShTdWDhWn228ZDbQ== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-tp-itu-t-identifiers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:35:52 -0000 Hi, I have done my AD review of this document, and have no blocking comments. I will go ahead and issue the IETF last call. During last call, please consider the two minor issues suggested below. Thanks, Adrian --- There are some abbreviations that need to be expanded on first use because they show up before the terminology section: OAM ITU-T LSP PW --- You could make the document shorter by simply referencing the notational conventions of RFC 6370. From koike.yoshinori@lab.ntt.co.jp Fri Dec 14 10:38:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA10D21F8855 for ; Fri, 14 Dec 2012 10:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtyBRFMx-b9o for ; Fri, 14 Dec 2012 10:38:47 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8471521F8990 for ; Fri, 14 Dec 2012 10:38:47 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id qBEIchqa012506; Sat, 15 Dec 2012 03:38:43 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D2F56E0153; Sat, 15 Dec 2012 03:38:42 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C6DBCE014E; Sat, 15 Dec 2012 03:38:42 +0900 (JST) Received: from [129.60.11.43] (koike-pc.nslab.ecl.ntt.co.jp [129.60.11.43]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id qBEIcgKt006741; Sat, 15 Dec 2012 03:38:42 +0900 Message-ID: <50CB72A6.7030901@lab.ntt.co.jp> Date: Sat, 15 Dec 2012 03:40:38 +0900 From: Yoshinori Koike User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: daviball@cisco.com References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> In-Reply-To: <50CB6508.10804@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:38:48 -0000 Hello David, Sorry, there was a mis-description in the previous email. Not G.8121.1 but G.8121.2. Best regards, Yoshinori (2012/12/15 2:42), Yoshinori Koike wrote: > Hello David, > > I agree with original text is confusing and thank you for the proposal. > However, I'm wondering if the proposed text is true and exactly reflect > the intent explained in the notes. > > My suggestion is as follows: > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback point which is different from MIP/MEP. > > Firstly, the description "the data-plane loopback function may be > applied at MIPs/MEPs" doesn't seem to be true. > > In my understanding, data-plane loopback function can be > set/enabled/disabled at MIP/MEP using a management system but not be > applied to MIP/MEP itself. So I clarified this point in my proposal. > > One of the reason is that MIP/MEP is only involved in OAM packets. There > seems no specification in any RFC, which describe that MIP/MEP could > handle data packets which are not OAM packets . > > In G.8121 amd1, data-plane loopback sink and source are specified and > according to Temporary Document(TD673R1<->R0/Plen) during last SG15 > meeting, the data-plane loopback sink/source was removed from figures of > MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be to avoid a > restriction of implementations, however it doesn't seem to make it > possible to apply dataplane loopback point to MIP/MEP. In realty, if > data-plane loopback function is enabled, for data-plane LB function > there is no need to parse the packet except for outermost label value. > > Secondly, if you need to clarify the relationship between data-plane LB > point at which data-plane LB function is conducted and MIP/MEP at which > data-plane LB function is enabled/configured using management system, it > seems enough just to say the two point usually resides on the same > interface and clarify the binding of two points. I have no issue on this > specification. However, just in case, it seems better to confirm if the > change is ok in ITU-T joint interregnum meeting Jan 2013, because this > is a matter of 8121 or/and G.8121.1. As a result, I didn't add related > text in my proposal. > > I'm not an implementer, so I would appreciate it if you could correct me > if I'm wrong. Thank you in advance. > > Best regards, > > Yoshinori > > > (2012/12/13 3:17), Adrian Farrel wrote: >> Hello, >> >> Authors of RFC 6435: I need to hear from you that you meant the text >> that David >> suggests. It is very clearly not what you wrote and, if you meant >> something >> different, it is clear why people are confused! >> >> Working group: I need to hear from you that you agree with David's >> interpretation and support his proposed change. >> >> Only then will I try to work out whether this is a "typo" worthy of an >> errata >> report, or a technical change needing a revised RFC. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 12 December 2012 17:45 >>> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >>> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >>> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >>> rcallon@juniper.net >>> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Editorial Errata Reported] RFC6435 (3429) >>> >>> >>> The following errata report has been submitted for RFC6435, >>> "MPLS Transport Profile Lock Instruct and Loopback Functions". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: David Ball >>> >>> Section: 4 (para 5) >>> >>> Original Text >>> ------------- >>> It should be noted that the data-plane loopback function itself is >>> applied to >> data- >>> plane loopback points residing on different interfaces from MIPs/MEPs. >>> >>> Corrected Text >>> -------------- >>> It should be noted that the data-plane loopback function may be >>> applied at >>> MIPs/MEPs on different interfaces for different LSPs. >>> >>> Notes >>> ----- >>> The existing text has caused confusion (specifically, among experts >>> in ITU-T >> SG15 >>> when discussing G.8121.2), in that it seems to suggest that the >>> interface >> where >>> the MIP/MEP is located may be a different interface to the one where the >>> loopback is applied. >>> >>> Having spoken with some of the original authors, it seems this was >>> not the >> intent >>> of this sentence; the intent was to point out that as different LSPs >>> would >> have >>> MIPs/MEPs on different interfaces, the corresponding loopback >>> functions would >>> also be applied on different interfaces. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >>> -------------------------------------- >>> Title : MPLS Transport Profile Lock Instruct and Loopback >> Functions >>> Publication Date : November 2011 >>> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. >>> Aggarwal, Ed., M. >> Vigoureux, >>> Ed., X. Dai, Ed. >>> Category : PROPOSED STANDARD >>> Source : Multiprotocol Label Switching >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > -- Yoshinori Koike koike.yoshinori@lab.ntt.co.jp From loa@pi.nu Fri Dec 14 10:45:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED91E21F8A05 for ; Fri, 14 Dec 2012 10:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.678 X-Spam-Level: X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey7cb9TXMmSk for ; Fri, 14 Dec 2012 10:45:34 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCB321F89B6 for ; Fri, 14 Dec 2012 10:45:34 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 921558244C; Fri, 14 Dec 2012 19:45:27 +0100 (CET) Message-ID: <50CB73C9.40802@pi.nu> Date: Fri, 14 Dec 2012 19:45:29 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls-ads@tools.ietf.org" , Martin Vigoureux , "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" References: <5098CF68.2000105@pi.nu> <50A3B5C0.4060203@pi.nu> <50BDCCD3.4030803@pi.nu> In-Reply-To: <50BDCCD3.4030803@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Working Group Last Call - closed. Re: Extended - Re: working group last call on draft-ietf-mpls-tp-mip-mep-map X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:45:35 -0000 Working group, this working group last call is closed. The working group chairs has followed the discussion on the mailing list closely. We want to go forward with the draft-ietf-mpls-tp-mip-mep-map, but we also believe that the that it should be turned into a more framework style of document. We believe that OAM messages carrying a MIP or MEP identifier in the message header (before the payload OAM protocol fields) should be assigned new ACh Type values rather than being variations of existing OAM messages that does not currently include such identifiers. The identifiers carried in those messages, regardless of how we chose to encode them, must be found at well know places and have well known format. While the document has been prepared it has gone through and excluded some solutions, this is fine. As this is made into a framework document, it does not need to go into as much detail of the proposed solution. We will need protocol specification for the ACh types and we should not constrain the protocol specifications unnecessarily. As this is made into a framework document, it does not need to go into as much detail of the proposed solution. This document is therefore returned for further working group work and a new WG last call will be held sometime in the future when the document is ready. /Loa for the mpls wg chairs On 2012-12-04 11:13, Loa Andersson wrote: > Working Group, > > since we have a discussion relating to to comments in this working > group last call, the chairs will leave the wg last open until the > end of this week. > > /Loa > for the wg co-chairs > > On 2012-11-14 16:16, Loa Andersson wrote: >> >> Working Group, >> >> This is to start a 2 week working group last call on >> draft-ietf-mpls-tp-mip-mep-map. >> >> Please send your comments to the mpls working group mailing >> list (mpls@ietf.org). >> >> Please send both technical comments, and if you are happy with the >> document as is also indications of support. >> >> This working group last call will end on November 28. >> >> /Loa >> for the wg co-chairs >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From iesg-secretary@ietf.org Fri Dec 14 10:53:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1221F8AB1; Fri, 14 Dec 2012 10:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3ipIqvKlwvw; Fri, 14 Dec 2012 10:53:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3B21F8952; Fri, 14 Dec 2012 10:53:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121214185345.474.68772.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 10:53:45 -0800 Cc: mpls@ietf.org Subject: [mpls] Last Call: (MPLS-TP Identifiers Following ITU-T Conventions) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:53:47 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Identifiers Following ITU-T Conventions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-itu-t-identifiers/ballot/ No IPR declarations have been submitted directly on this I-D. From kvivek@broadcom.com Fri Dec 14 19:16:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95E21F8B16 for ; Fri, 14 Dec 2012 19:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrDBNhDmSmeT for ; Fri, 14 Dec 2012 19:16:47 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50121F8AE5 for ; Fri, 14 Dec 2012 19:16:47 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 14 Dec 2012 19:11:59 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 14 Dec 2012 19:09:58 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 14 Dec 2012 19:09:37 -0800 From: "Vivek Kumar" To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: Ac3acUW0YZjbzTjlTYuE5CNFAvoJhA== Date: Sat, 15 Dec 2012 03:09:36 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC41DEAC984@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CD535F539W11346174-05-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 03:16:48 -0000 I support this draft.=20 Regards, vivek Date: Fri, 14 Dec 2012 10:01:08 +0100 From: Loa Andersson To: "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Subject: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Message-ID: <50CAEAD4.6000705@pi.nu> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Working group, This is to start a "two week" poll on adopting draft-xu-mpls-in-udp-06 as an MPLS working group document. Due to the holiday season this poll has been extended with one week. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends January 07, 2013. There is one IPR claim against this document - https://datatracker.ietf.org/ipr/1941/ . All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However, up to version -03 (the document that we used for the IPR poll) Marshall Eubanks was listed as one of the authors. Marshall has discontinued all interactions with the IETF, including the author team of draft-xu-mpls-in-udp-06. The working group chairs has tried to contact Marshall by other means, to try get a response on the IPR poll. We have had no success in this. From version -04 the authors decided to remove Marshall as a co-author. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From davarish@yahoo.com Fri Dec 14 21:34:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4B121F88DC for ; Fri, 14 Dec 2012 21:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TphEPKTNs1lF for ; Fri, 14 Dec 2012 21:34:26 -0800 (PST) Received: from nm22.bullet.mail.bf1.yahoo.com (nm22.bullet.mail.bf1.yahoo.com [98.139.212.181]) by ietfa.amsl.com (Postfix) with ESMTP id BEFDC21F88BF for ; Fri, 14 Dec 2012 21:34:23 -0800 (PST) Received: from [98.139.214.32] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 15 Dec 2012 05:34:23 -0000 Received: from [76.13.13.233] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 15 Dec 2012 05:34:22 -0000 Received: from [127.0.0.1] by smtp112-mob.biz.mail.ac4.yahoo.com with NNFMP; 15 Dec 2012 05:34:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1355549662; bh=bOvqZzFMMcukx3mqJl/JmCzJ9easD7t4ki3ExLzg+to=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=eWd8QNlEzPNGhR4nOG0rViHBDYCZkBQL5pflqwA6+IWCazw6znEdLU3uz1i4U0ualzU/bojN4oaFR46HuAt7NdJ1xSRTWhazbJQAemSkLD8+8fXJRspU636kMqaDJb8T6Oa+Nqk3DNVpkkjv/HspY1fSKWOr5+k8CcuTqWpsvXk= X-Yahoo-Newman-Id: 728122.25675.bm@smtp112-mob.biz.mail.ac4.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uVufC8QVM1nIeVpGUdpM805cNkgYHMPv11WjH6S_tuQJ6X8 ZAPwGPeUJX8lqsh0qToFnQntDg1a4rN4xlh80c5msveFnF5XYaYQPKE6nKv1 JbT6Cj17Y.H5dx2ssxP97vw7yjD0jGXtC7dXDJ68hfsN4c0EOVJoJcXh5tdW EExg.y6dUhsOGs4ImH5oYtgbvchlVdVk7hmNo2nTwuqY9da3lRxNTxy2KcLz 5_p2bWs3QhuUo20QViMJpGzrrmKoLrNdFUtLkrEyn3D2p8UNukuS0EDzMvFk 4tpsxQnq7.i97w5cdQnE7rYuXo38cNQD8rZyK8gDTLmijcHQgygKNTFBssU8 IMLJEdzJOKuoLa_KE1S1A_NdcYf8F0AIS4oVXLgek7JVnbeNqxZsmQr6Gp1b OSElo0HW2bcOSY0_7GXXIr9lcxk5WcehFtmYX0i1LL9DHmlcYp20Al9fvlH3 eyCwkup3fprlmkxCpVCFHpxBoyM3e1ZRBII5yHbClz43DqLSsUQBqqoHX8oE 4CS75k3GKm2zgPg-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg Received: from [10.165.233.23] (davarish@166.137.212.214 with xymcookie) by smtp112-mob.biz.mail.ac4.yahoo.com with SMTP; 14 Dec 2012 21:34:22 -0800 PST References: <50CAEAD4.6000705@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <50CAEAD4.6000705@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.com> X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Fri, 14 Dec 2012 21:34:18 -0800 To: Loa Andersson Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 05:34:26 -0000 I don't support this draft since it has no application in today's modern met= ro and core, where MPLS is dominant, and its only practical application in i= n data center, which already is crowded with other solutions such as NVGRE a= nd VXLAN.=20 It seems the authors are trying to bypass the NVO3 solution selection proces= s by advancing the draft in MPLS WG. Regards, Shahram On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: > Working group, >=20 > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends January 07, 2013. >=20 > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. >=20 > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. >=20 > =46rom version -04 the authors decided to remove Marshall as a co-author. >=20 > /Loa > (mpls wg co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti.kompella@gmail.com Fri Dec 14 23:52:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6C221F8945 for ; Fri, 14 Dec 2012 23:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkmwdXg9x9XM for ; Fri, 14 Dec 2012 23:52:20 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC53521F88C8 for ; Fri, 14 Dec 2012 23:52:20 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so4133450obc.31 for ; Fri, 14 Dec 2012 23:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=JXE2gXpFGXVEp5i+d/Ozysai75kvciGNTwGwS/BnY3c=; b=VXZ/48j3289oPSa5RI6wqOCAG8MFl1eiOEP4dvsAG1NEk2tFGLXgxvv6SHUyoHgmMf QGHzY1O2Fpnv9t0dbFsx/G7w0A7wcUYThE0Qyd8XHbS/gRuYtOPyhEBtQSgFQvdNK3Lx /yc+Qr8l3jNpHN/Jt0tK/V9Gbz9C7A/S/9Jsnpn2JJp6RdlZqdbf3wl+XhTbAkwGuj+9 p67u1Z71pi5dgVi2ytDiZEpNIWoq27UqESYMMarlANkHUfQopiqFQLEx/i7GEcpA3jcs A22Kp4WvFfutQ5HTNf/Qmel+QC2S/mF9umq7ItE9dtYfLdnfhpnczPEdm4KtCFC7QL4u iZrw== Received: by 10.182.89.42 with SMTP id bl10mr6736626obb.27.1355557938436; Fri, 14 Dec 2012 23:52:18 -0800 (PST) Received: from [192.168.1.69] (75-37-193-116.lightspeed.lsatca.sbcglobal.net. [75.37.193.116]) by mx.google.com with ESMTPS id b3sm5019835obo.6.2012.12.14.23.52.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2012 23:52:17 -0800 (PST) References: <50CAEAD4.6000705@pi.nu> <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.com> In-Reply-To: <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <046500CE-059D-4471-A831-835F50C7D7AA@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A405) From: Kireeti Kompella Date: Fri, 14 Dec 2012 23:52:13 -0800 To: "S. Davari" Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 07:52:21 -0000 Support.=20 On Dec 14, 2012, at 21:34, "S. Davari" wrote: > It seems the authors are trying to bypass the NVO3 solution selection proc= ess by advancing the draft in MPLS WG. That's completely uncalled for. If it's your opinion that this draft has a b= etter fit in the NVO3 WG, just say so. This draft is about MPLS and should be dealt with in the MPLS WG. That's my o= pinion, but I'm happy to defer to the WG chairs and ADs. Kireeti From aldrin.ietf@gmail.com Sat Dec 15 00:13:27 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3147A21F8A12 for ; Sat, 15 Dec 2012 00:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGcPuylYLQp3 for ; Sat, 15 Dec 2012 00:13:26 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB06F21F8A11 for ; Sat, 15 Dec 2012 00:13:26 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2675562pbc.31 for ; Sat, 15 Dec 2012 00:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=FBvjymfViYKivMiOcJeqwddLvPfb/LHxOXqeTBUeMbU=; b=CaSK3PkM3iOciivkCGU7PYYjnjrMbsP7m0r3ntViB6FCJsItvHdrIoyVRtJbKIt0Af 98jhdq7ZTonmKJmCnYBWUUZU52DbrPW0RW17opFdIUZpZt9bkAbYCQpWzufkAFHQjPce MoFPS/c9kqhU6HKIBohkO9k/YHn+0wFvcO1yQ/uBH2kpgtRpmiRvsNUvmoliYCy57xlC JV71NY4in8ytRHUtRcVIyE5+GYP7Pu3Aax0K1ZD40W2GFVVLeDSNdgbrLPyuK22uRUJr lNtITMybbXgoU7/5YfBSUZnluheUJV51/ojxmw/1F1/2VkIBUSMGp5Zy2SxqOVjHWt2G T32A== Received: by 10.68.131.8 with SMTP id oi8mr23058111pbb.29.1355559206440; Sat, 15 Dec 2012 00:13:26 -0800 (PST) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id nt5sm4358407pbb.59.2012.12.15.00.13.24 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 00:13:25 -0800 (PST) References: <50CAEAD4.6000705@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <50CAEAD4.6000705@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A523) From: Sam Aldrin Date: Sat, 15 Dec 2012 00:13:25 -0800 To: Loa Andersson Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 08:13:27 -0000 Support. -Sam Sent from my iPad On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: > Working group, > > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends January 07, 2013. > > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. > > From version -04 the authors decided to remove Marshall as a co-author. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From binnyjeshan@gmail.com Sun Dec 16 06:44:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063DD21F8715; Sun, 16 Dec 2012 06:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+dCXX1FkPZ2; Sun, 16 Dec 2012 06:44:41 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E011E21F84EB; Sun, 16 Dec 2012 06:44:36 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id z4so1818379qan.10 for ; Sun, 16 Dec 2012 06:44:36 -0800 (PST) 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=aSX4HIkwJMuIdAFsuDHgNX+SykTHKvZR1DE79DYCFfc=; b=h+xDDOYtQ/GB2G1C4dHHQ9XQAwMA6Z1mCzfoFF/DaFEYh+PzTRJFoFBXKvmcWZ3YW9 Ihz+VmiLttJLidumSBxNd7FaoE6es1NZH+y6AzxJ64/RO3WxsM8sA/odXUsUC/SKyNvC J1o0RWYEITZ3EsB172EKYMZGhSdQssV86ows4toIRf9tSM9yxXljFxoc+spQNU7oaiKN gTxdTizTMwX035ZqwebL3VdJQKdh21JD8guOqbVzEjHaWQD7TnbWeIic8F+ix+NsmHh7 +YvaDW8gjlahJpRoI64PnqbefungSF/BDaYJXpLIXTX3qIgiAH605Gc6LGqk3We38No4 vMhA== MIME-Version: 1.0 Received: by 10.229.195.211 with SMTP id ed19mr1076553qcb.78.1355669075006; Sun, 16 Dec 2012 06:44:35 -0800 (PST) Received: by 10.49.106.169 with HTTP; Sun, 16 Dec 2012 06:44:34 -0800 (PST) In-Reply-To: <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> Date: Sun, 16 Dec 2012 20:14:34 +0530 Message-ID: From: Binny Jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=005045016f07a6163604d0f94dd5 Cc: mpls@ietf.org, "Santiago Alvarez \(saalvare\)" , pwe3@ietf.org, rtg-bfd@ietf.org Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 14:44:43 -0000 --005045016f07a6163604d0f94dd5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, Looks like i missed this discussion. I second Sam to his point - "Good to have an informational document and do not support the idea of standardizing the intervals" And IMHO, i think BFD as it currently supports wide range of adjustable timer intervals has given good flexibility for troubleshooting faults like packet drops in high bandwidth links. Regards, Binny. Aricent Group - India. On 5 December 2012 05:19, Marc Binderberger wrote: > Hello Sam, Santiago, Gregory, Sharam et al., > > thanks for the feedback. Input from the MPLS and PWE3 list is welcome > regarding important timer values for which we would like to have a common > support. > > Few comments from my side: > > I can live with an informal document, at least with respect to the > "standard intervals". The document shall help to improve interoperability > and even an informal document can become de-facto standard when customers > request it ;-) > > There is the aspect of the multiple poll/final sequences to find the next > common interval. I think it is covered by RFC5880 but this statement may > require more discussion on the BFD list. If not covered then we would nee= d > a standard, I think. > > We will not make any reference to Y.1731 in the text but where intervals > we proposed are close to Y.1731 intervals I'm fine to adjust to Y.1731 > values, which may make a combined "OAM hardware" simpler/cheaper. > > > We list the following values in the draft -03 version > > o 3.3msec: required by MPLS-TP > > o 10msec and 20msec: both values allow to detect faster than 50msec, > when used with a multiplier of 2 or 3 (for 10msec). A compromise > could be a single interval of 15msec. > > o 50msec: this seems an interval often supported by software > implementations, so the assumption here is that for convenience > this value should be supported. > > o 300msec: this would support large scale of 3 x 300msec setups used > by customers to have a detection time slightly below 1sec for VoIP > setups. > > o 1sec: as mentioned in RFC5880 > > > We also discussed some time ago that the 300msec could be replaced by > 100msec intervals but this still needs more discussion. And the lower > interval range 10-50msec, especially 10-20msec, I personally tend to have > more "standard values" than less, providing more common intervals between > hardware based BFD and software based BFD; it is at least my impression > that in this range most software-based implementations have their lower > limit and the more common intervals the easier we can support 50-60msec > detect+restore even with software-based BFD (10msec may just push the > limit, 100msec is obviously too slow). > > > This is vague beside the 3.3msec and 1sec, so again if good reasons exist > for specific values from the MPLS, MPLS-TP and PWE3 standards or > applications: input is very welcome! > > > Thanks & Regards, > Marc > > > > > On 2012-12-03, at 20:53 , Sam Aldrin wrote: > > I echo what Santiago had said in his email. Good to have an informational > document and do not support the idea of standardizing the intervals. > > -sam > On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" < > saalvare@cisco.com> wrote: > > Applicability of BFD is pretty wide. Mandating a set of intervals driven > by Y.1731 doesn=92t sound like a good idea to me. Having lived through m= ost > of the BFD CC interop testing in the context of MPLS-TP, I can see some > value in having an informational doc that would discuss interval > configuration and interoperability.**** > Cheers.**** > > SA**** > --**** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf O= f > *Gregory Mirsky > *Sent:* Monday, December 03, 2012 11:33 AM > *To:* Marc Binderberger; Shahram Davari > *Cc:* mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org > *Subject:* Re: [mpls] Commenst on draft-akiya-bfd-intervals-03**** > ** ** > Dear Shahram, Marc, et al.,**** > I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE= 3 > WGs have a stake in this discussion.**** > I agree that compatibility with intervals standardized for Ether OAM > (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll > note that even with the same transmission intervals failure detection in > BFD-based CC/CV and Ether OAM is different time interval. Not by much but > different nevertheless.**** > And I agree with Marc that BFD-based CC is not only for packet or Etherne= t > transport applications. And more values of transmission interval are > useful. That is why I believe that we should not standardize any values, = at > least not on Standard Track. At most it could be an informational documen= t. > Or, which will be great, have a survey among providers on what interval > values being used (similar to great survey on PWE VCCV Control Channels).= * > *** > **** > Regards,**** > Greg**** > ** ** > ------------------------------ > > *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org > ] *On Behalf Of *Marc Binderberger > *Sent:* Monday, December 03, 2012 11:08 AM > *To:* Shahram Davari > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: Commenst on draft-akiya-bfd-intervals-03**** > Hello Shahram,**** > ** ** > thanks for re-vitalizing this discussion - must admit I was busy with too > many other things.**** > ** ** > I do agree with including the values you mention in the list of BFD > supported values, although I question the large values.**** > ** ** > On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD > implementations out there. So we likely need to support other values as > well to fit into the existing world.**** > ** ** > ** ** > Regards, Marc**** > ** ** > ** ** > ** ** > ** ** > ** ** > On 2012-12-03, at 20:02 , Shahram Davari wrote:**** > > > **** > Hi,**** > I would like to propose standardizing the same intervals as Y.1731/802.1a= g > for BFD. This would make the total L2, L3 OAM more homogeneous. So the > proposal is:**** > 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.**** > Thank you,**** > Shharam**** > ** ** > --**** > Marc Binderberger **** > ** ** > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > -- > Marc Binderberger > > --005045016f07a6163604d0f94dd5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

Looks like i missed this discussion.
I second Sam to his point - "Good to have an informational document and do not support the id= ea of standardizing the intervals"=A0

And IMHO, i think BFD as it curre= ntly supports wide range of adjustable timer intervals has given good flexi= bility for troubleshooting faults like packet drops in high bandwidth links= .

Regards,
=
Binny.
=
Aricent Group - India.

On 5 December 2012 05:19, Marc Binder= berger <marc@sniff.de> wrote:
Hello Sam, Santiago, Gregory, Sharam et= al.,

thanks for the feedback. Input from the MPLS and P= WE3 list is welcome regarding important timer values for which we would lik= e to have a common support.

Few comments from my side:

I c= an live with an informal document, at least with respect to the "stand= ard intervals". The document shall help to improve interoperability an= d even an informal document can become de-facto standard when customers req= uest it ;-)

There is the aspect of the multiple poll/final sequence= s to find the next common interval. I think it is covered by RFC5880 but th= is statement may require more discussion on the BFD list. If not covered th= en we would need a standard, I think.

We will not make any reference to Y.1731 in the text bu= t where intervals we proposed are close to Y.1731 intervals I'm fine to= adjust to Y.1731 values, which may make a combined "OAM hardware"= ; simpler/cheaper.


We list the following values in the draf= t -03 version

=A0 =A0o =A03.3msec: required b= y MPLS-TP

=A0 =A0o =A010msec and 20msec: both valu= es allow to detect faster than 50msec,
=A0 =A0 =A0 when used with a multiplier of 2 or 3 (for 10msec). =A0A c= ompromise
=A0 =A0 =A0 could be a single interval of 15msec.
=

=A0 =A0o =A050msec: this seems an interval often suppor= ted by software
=A0 =A0 =A0 implementations, so the assumption here is that for conven= ience
=A0 =A0 =A0 this value should be supported.

<= /div>
=A0 =A0o =A0300msec: this would support large scale of 3 x 300mse= c setups used
=A0 =A0 =A0 by customers to have a detection time slightly below 1sec = for VoIP
=A0 =A0 =A0 setups.

=A0 =A0o = =A01sec: as mentioned in RFC5880


<= div>We also discussed some time ago that the 300msec could be replaced by 1= 00msec intervals but this still needs more discussion. And the lower interv= al range 10-50msec, especially 10-20msec, I personally tend to have more &q= uot;standard values" than less, providing more common intervals betwee= n hardware based BFD and software based BFD; it is at least my impression t= hat in this range most software-based implementations have their lower limi= t and the more common intervals the easier we can support 50-60msec detect+= restore even with software-based BFD (10msec may just push the limit, 100ms= ec is obviously too slow).


This is vague beside the 3.3msec and 1se= c, so again if good reasons exist for specific values from the MPLS, MPLS-T= P and PWE3 standards or applications: input is very welcome!


Thanks & Regards,
Marc




<= div>
On 2012-12-03, at 20:53 , Sam Aldrin wrote:

I echo what Santiago had said in his em= ail. Good to have an informational document and do not support the idea of = standardizing the intervals.

-sam
On Dec 3,= 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" <saalvare@cisco.com> wro= te:

Applicability of BFD is pretty wide.=A0= Mandating a set of intervals driven by Y.1731 doesn=92t sound like a good = idea to me.=A0 Having lived through most of the BFD CC interop testing in t= he context of MPLS-TP, I can see some value in having an informational doc = that would discuss interval configuration and interoperability.
Cheers.
=A0
SA
--
=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(181,196,223);padding:3pt 0in 0in">
From:=A0mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=A0On Behalf Of=A0Gregory Mirsky
Sent:=A0Monday, December 03, 2012 11:33 AM
To:=A0Marc Binderberger; Shahram Davari
Cc:=A0mpls@ietf.org; = rtg-bfd@ietf.org;= pwe3@ietf.org
Subject:=A0Re: [mpls] Commenst on draft-akiya-bfd-inter= vals-03
=A0
Dear Shahram, Marc, et al.,
I th= ink that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs = have a stake in this discussion.
I ag= ree that compatibility with intervals standardized for Ether OAM (CFM/Y.173= 1) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless.
And I agree with Marc that BFD-based CC is not only for = packet or Ethernet transport applications. And more values of transmission = interval are useful. That is why I believe that we should not standardize a= ny values, at least not on Standard Track. At most it could be an informati= onal document. Or, which will be great, have a survey among providers on wh= at interval values being used (similar to great survey on PWE VCCV Control = Channels).
=A0
=A0=A0=A0 = Regards,
=A0=A0=A0=A0=A0=A0=A0 Greg
=A0

From:=A0= rtg-bfd-bounces@ietf.org=A0[mailto:rtg-bfd-bounces@iet= f.org]=A0On Behalf Of=A0Marc Binderber= ger
Sent:=A0Monday, December 03, 2012 11:08 AM
To:=A0Shahram Davari
Cc:=A0rtg-bfd@ietf.org
Subject:=A0Re: Commenst on draft-akiya-bfd-intervals-03=

Hello Shahram,
=A0
thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things.
<= /u>=A0
I do agree with including the values you = mention in the list of BFD supported values, although I question the large = values.
=A0
On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world.
=A0
=A0<= /div>
Regards, Marc
= =A0
=A0
=A0<= /div>
=A0
=A0<= /div>
On 2012-12-03, at 20:02 , Shahram Davari wrote:


Hi,=
I would like to propose standardizing= the same intervals as Y.1731/802.1ag for BFD. This would make the total L2= , L3 OAM more homogeneous. So the proposal is:
3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.=
Thank you,
=A0Shharam
=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> --= =
Mar= c Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.= de>
=A0
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>


--005045016f07a6163604d0f94dd5-- From binnyjeshan@gmail.com Sun Dec 16 06:50:14 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807A921F87BC; Sun, 16 Dec 2012 06:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NVBo+WFFqpq; Sun, 16 Dec 2012 06:50:10 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58A21F87B6; Sun, 16 Dec 2012 06:50:10 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so3411191qcs.27 for ; Sun, 16 Dec 2012 06:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cUJiGws3f/eBo6Lb9eqE7MeNFIWFJt4TbKCXVbpYdrM=; b=mR3ROrgOjrBHc5mlo2JDFlAWwdnDb63ZT7A2woprgJzxjALXS/ODSU/DKa8XvrHYjD SUaBy7k14lz9DDizYJnOHBJW2iPGHIMRJ3Rd4ChhENp9KofR1yupEs6NhTXqQwpfdUps P1n6afk2jtqP6GwxfVHrKV6zvr5IS4qN7VwdF0B5RiJHvC6YF8kOUpoZocZpFX9LzlOn gISoAoGlwD8jETVHMoz7oyJX8uWVT/0ISv1NjbpuAPySrNLYSGI8WouTn7koUtlW5LyI VFyqE/5TIwq5qwMbvW2O0shZomo8gnCopoChIcB0TaN5sssQf/jmazRxurUnLTeyiwNk 7z4g== MIME-Version: 1.0 Received: by 10.49.131.67 with SMTP id ok3mr5798307qeb.42.1355669409572; Sun, 16 Dec 2012 06:50:09 -0800 (PST) Received: by 10.49.106.169 with HTTP; Sun, 16 Dec 2012 06:50:09 -0800 (PST) In-Reply-To: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <8C07C743-5276-429E-AC05-E1577A9EE856@sniff.de> Date: Sun, 16 Dec 2012 20:20:09 +0530 Message-ID: From: Binny Jeshan To: Marc Binderberger Content-Type: multipart/alternative; boundary=047d7bdc06f09727da04d0f9614e Cc: mpls@ietf.org, "Santiago Alvarez \(saalvare\)" , pwe3@ietf.org, rtg-bfd@ietf.org Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 14:50:14 -0000 --047d7bdc06f09727da04d0f9614e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Marc, You mentioned, "* **There is the aspect of the multiple poll/final sequences to find the next common interval. I think it is covered by RFC5880 but this statement may require more discussion on the BFD list. If not covered then we would need a standard, I think. *" Could you please describe more on this, if not in this discussion mail, you can choose to do it in another mail. This topic interests me :), as i'd like to know what is missing or needs to be covered. Regards, Binny. Aricent Group - India. On 16 December 2012 20:14, Binny Jeshan wrote: > Hello, > > Looks like i missed this discussion. > > I second Sam to his point - "Good to have an informational document and > do not support the idea of standardizing the intervals" > > And IMHO, i think BFD as it currently supports wide range of adjustable > timer intervals has given good flexibility for troubleshooting faults lik= e > packet drops in high bandwidth links. > > Regards, > Binny. > Aricent Group - India. > > On 5 December 2012 05:19, Marc Binderberger wrote: > >> Hello Sam, Santiago, Gregory, Sharam et al., >> >> thanks for the feedback. Input from the MPLS and PWE3 list is welcome >> regarding important timer values for which we would like to have a commo= n >> support. >> >> Few comments from my side: >> >> I can live with an informal document, at least with respect to the >> "standard intervals". The document shall help to improve interoperabilit= y >> and even an informal document can become de-facto standard when customer= s >> request it ;-) >> >> There is the aspect of the multiple poll/final sequences to find the nex= t >> common interval. I think it is covered by RFC5880 but this statement may >> require more discussion on the BFD list. If not covered then we would ne= ed >> a standard, I think. >> >> We will not make any reference to Y.1731 in the text but where intervals >> we proposed are close to Y.1731 intervals I'm fine to adjust to Y.1731 >> values, which may make a combined "OAM hardware" simpler/cheaper. >> >> >> We list the following values in the draft -03 version >> >> o 3.3msec: required by MPLS-TP >> >> o 10msec and 20msec: both values allow to detect faster than 50msec, >> when used with a multiplier of 2 or 3 (for 10msec). A compromise >> could be a single interval of 15msec. >> >> o 50msec: this seems an interval often supported by software >> implementations, so the assumption here is that for convenience >> this value should be supported. >> >> o 300msec: this would support large scale of 3 x 300msec setups used >> by customers to have a detection time slightly below 1sec for VoIP >> setups. >> >> o 1sec: as mentioned in RFC5880 >> >> >> We also discussed some time ago that the 300msec could be replaced by >> 100msec intervals but this still needs more discussion. And the lower >> interval range 10-50msec, especially 10-20msec, I personally tend to hav= e >> more "standard values" than less, providing more common intervals betwee= n >> hardware based BFD and software based BFD; it is at least my impression >> that in this range most software-based implementations have their lower >> limit and the more common intervals the easier we can support 50-60msec >> detect+restore even with software-based BFD (10msec may just push the >> limit, 100msec is obviously too slow). >> >> >> This is vague beside the 3.3msec and 1sec, so again if good reasons exis= t >> for specific values from the MPLS, MPLS-TP and PWE3 standards or >> applications: input is very welcome! >> >> >> Thanks & Regards, >> Marc >> >> >> >> >> On 2012-12-03, at 20:53 , Sam Aldrin wrote: >> >> I echo what Santiago had said in his email. Good to have an informationa= l >> document and do not support the idea of standardizing the intervals. >> >> -sam >> On Dec 3, 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" < >> saalvare@cisco.com> wrote: >> >> Applicability of BFD is pretty wide. Mandating a set of intervals drive= n >> by Y.1731 doesn=92t sound like a good idea to me. Having lived through = most >> of the BFD CC interop testing in the context of MPLS-TP, I can see some >> value in having an informational doc that would discuss interval >> configuration and interoperability.**** >> Cheers.**** >> >> SA**** >> --**** >> >> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf >> Of *Gregory Mirsky >> *Sent:* Monday, December 03, 2012 11:33 AM >> *To:* Marc Binderberger; Shahram Davari >> *Cc:* mpls@ietf.org; rtg-bfd@ietf.org; pwe3@ietf.org >> *Subject:* Re: [mpls] Commenst on draft-akiya-bfd-intervals-03**** >> ** ** >> Dear Shahram, Marc, et al.,**** >> I think that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and >> PWE3 WGs have a stake in this discussion.**** >> I agree that compatibility with intervals standardized for Ether OAM >> (CFM/Y.1731) makes sense and might be helpful in interworking. But I'll >> note that even with the same transmission intervals failure detection in >> BFD-based CC/CV and Ether OAM is different time interval. Not by much bu= t >> different nevertheless.**** >> And I agree with Marc that BFD-based CC is not only for packet or >> Ethernet transport applications. And more values of transmission interva= l >> are useful. That is why I believe that we should not standardize any >> values, at least not on Standard Track. At most it could be an >> informational document. Or, which will be great, have a survey among >> providers on what interval values being used (similar to great survey on >> PWE VCCV Control Channels).**** >> **** >> Regards,**** >> Greg**** >> ** ** >> ------------------------------ >> >> *From:* rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org >> ] *On Behalf Of *Marc Binderberger >> *Sent:* Monday, December 03, 2012 11:08 AM >> *To:* Shahram Davari >> *Cc:* rtg-bfd@ietf.org >> *Subject:* Re: Commenst on draft-akiya-bfd-intervals-03**** >> Hello Shahram,**** >> ** ** >> thanks for re-vitalizing this discussion - must admit I was busy with to= o >> many other things.**** >> ** ** >> I do agree with including the values you mention in the list of BFD >> supported values, although I question the large values.**** >> ** ** >> On the other hand: we are not re-inventing Ethernet OAM and we _have_ BF= D >> implementations out there. So we likely need to support other values as >> well to fit into the existing world.**** >> ** ** >> ** ** >> Regards, Marc**** >> ** ** >> ** ** >> ** ** >> ** ** >> ** ** >> On 2012-12-03, at 20:02 , Shahram Davari wrote:**** >> >> >> **** >> Hi,**** >> I would like to propose standardizing the same intervals as >> Y.1731/802.1ag for BFD. This would make the total L2, L3 OAM more >> homogeneous. So the proposal is:**** >> 3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.**** >> Thank you,**** >> Shharam**** >> ** ** >> --**** >> Marc Binderberger **** >> ** ** >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> -- >> Marc Binderberger >> >> > --047d7bdc06f09727da04d0f9614e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Marc,
You mentioned,

" There is the aspect of the multiple po= ll/final sequences to find the next common interval. I think it is covered = by RFC5880 but this statement may require more discussion on the BFD lis= t. If not covered then we would need a standard, I think. "= ;

Could you please desc= ribe more on this, if not in this discussion mail, you can choose to do it = in another mail. This topic interests me :), as i'd like to know what i= s missing or needs to be covered.

Regards,<= /div>
Binny.<= /div>
Aricent Group=A0- India.

On 16 December 2012 20:14, Binny Jesh= an <binnyjeshan@gmail.com> wrote:
Hello,

Looks like i misse= d this discussion.

I second Sam to his point - &qu= ot;Good to have an informational document and do not support the idea = of standardizing the intervals"=A0

And IMHO, i think BFD as it currently supports wide range of adjust= able timer intervals has given good flexibility for troubleshooting faults = like packet drops in high bandwidth links.

Regards,
=
Binny.
=
Aricent Group - India.

On 5 December = 2012 05:19, Marc Binderberger <marc@sniff.de> wrote:
Hello Sam, Santiago, Gregory, Sharam et= al.,

thanks for the feedback. Input from the MPLS and P= WE3 list is welcome regarding important timer values for which we would lik= e to have a common support.

Few comments from my side:

I c= an live with an informal document, at least with respect to the "stand= ard intervals". The document shall help to improve interoperability an= d even an informal document can become de-facto standard when customers req= uest it ;-)

There is the aspect of the multiple poll/final sequence= s to find the next common interval. I think it is covered by RFC5880 but th= is statement may require more discussion on the BFD list. If not covered th= en we would need a standard, I think.

We will not make any reference to Y.1731 in the text bu= t where intervals we proposed are close to Y.1731 intervals I'm fine to= adjust to Y.1731 values, which may make a combined "OAM hardware"= ; simpler/cheaper.


We list the following values in the draf= t -03 version

=A0 =A0o =A03.3msec: required b= y MPLS-TP

=A0 =A0o =A010msec and 20msec: both valu= es allow to detect faster than 50msec,
=A0 =A0 =A0 when used with a multiplier of 2 or 3 (for 10msec). =A0A c= ompromise
=A0 =A0 =A0 could be a single interval of 15msec.
=

=A0 =A0o =A050msec: this seems an interval often suppor= ted by software
=A0 =A0 =A0 implementations, so the assumption here is that for conven= ience
=A0 =A0 =A0 this value should be supported.

<= /div>
=A0 =A0o =A0300msec: this would support large scale of 3 x 300mse= c setups used
=A0 =A0 =A0 by customers to have a detection time slightly below 1sec = for VoIP
=A0 =A0 =A0 setups.

=A0 =A0o = =A01sec: as mentioned in RFC5880


<= div>We also discussed some time ago that the 300msec could be replaced by 1= 00msec intervals but this still needs more discussion. And the lower interv= al range 10-50msec, especially 10-20msec, I personally tend to have more &q= uot;standard values" than less, providing more common intervals betwee= n hardware based BFD and software based BFD; it is at least my impression t= hat in this range most software-based implementations have their lower limi= t and the more common intervals the easier we can support 50-60msec detect+= restore even with software-based BFD (10msec may just push the limit, 100ms= ec is obviously too slow).


This is vague beside the 3.3msec and 1se= c, so again if good reasons exist for specific values from the MPLS, MPLS-T= P and PWE3 standards or applications: input is very welcome!


Thanks & Regards,
Marc




On 2= 012-12-03, at 20:53 , Sam Aldrin wrote:

I echo what Santiago had said in his em= ail. Good to have an informational document and do not support the idea of = standardizing the intervals.

-sam
On Dec 3,= 2012, at 11:48 AM, "Santiago Alvarez (saalvare)" <saalvare@cisco.com> wro= te:

Applicability of BFD is pretty wide.=A0= Mandating a set of intervals driven by Y.1731 doesn=92t sound like a good = idea to me.=A0 Having lived through most of the BFD CC interop testing in t= he context of MPLS-TP, I can see some value in having an informational doc = that would discuss interval configuration and interoperability.
Cheers.
=A0
SA
--
=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(181,196,223);padding:3pt 0in 0in">
From:=A0mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=A0On Behalf Of=A0Gregory Mirsky
Sent:=A0Monday, December 03, 2012 11:33 AM
To:=A0Marc Binderberger; Shahram Davari
Cc:=A0mpls@ietf.org; = rtg-bfd@ietf.org;= pwe3@ietf.org
Subject:=A0Re: [mpls] Commenst on draft-akiya-bfd-inter= vals-03
=A0
Dear Shahram, Marc, et al.,
I th= ink that since BFD is the CC/CV part of MPLS-TP OAM both MPLS and PWE3 WGs = have a stake in this discussion.
I ag= ree that compatibility with intervals standardized for Ether OAM (CFM/Y.173= 1) makes sense and might be helpful in interworking. But I'll note that= even with the same transmission intervals failure detection in BFD-based C= C/CV and Ether OAM is different time interval. Not by much but different ne= vertheless.
And I agree with Marc that BFD-based CC is not only for = packet or Ethernet transport applications. And more values of transmission = interval are useful. That is why I believe that we should not standardize a= ny values, at least not on Standard Track. At most it could be an informati= onal document. Or, which will be great, have a survey among providers on wh= at interval values being used (similar to great survey on PWE VCCV Control = Channels).
=A0
=A0=A0=A0 = Regards,
=A0=A0=A0=A0=A0=A0=A0 Greg
=A0

From:=A0= rtg-bfd-bounces@ietf.org=A0[mailto:rtg-bfd-bounces@iet= f.org]=A0On Behalf Of=A0Marc Binderber= ger
Sent:=A0Monday, December 03, 2012 11:08 AM
To:=A0Shahram Davari
Cc:=A0rtg-bfd@ietf.org
Subject:=A0Re: Commenst on draft-akiya-bfd-intervals-03=

Hello Shahram,
=A0
thanks for re-vitalizing this discussion - must admit I was busy with too m= any other things.
<= /u>=A0
I do agree with including the values you = mention in the list of BFD supported values, although I question the large = values.
=A0
On the other hand: we are not re-inventing Ethernet OAM and we _have_ BFD i= mplementations out there. So we likely need to support other values as well= to fit into the existing world.
=A0
=A0<= /div>
Regards, Marc
= =A0
=A0
=A0<= /div>
=A0
=A0<= /div>
On 2012-12-03, at 20:02 , Shahram Davari wrote:


Hi,=
I would like to propose standardizing= the same intervals as Y.1731/802.1ag for BFD. This would make the total L2= , L3 OAM more homogeneous. So the proposal is:
3.3ms, 10ms, 100ms, 1 sec, 10sec, 1 min, 10min.=
Thank you,
=A0Shharam
=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times = New Roman',serif"> --= =
Mar= c Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.= de>
=A0
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>



--047d7bdc06f09727da04d0f9614e-- From cpignata@cisco.com Sun Dec 16 08:16:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C094A21F87D7 for ; Sun, 16 Dec 2012 08:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snxYMw9iKtbb for ; Sun, 16 Dec 2012 08:16:40 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E326421F8784 for ; Sun, 16 Dec 2012 08:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18842; q=dns/txt; s=iport; t=1355674600; x=1356884200; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KG92zR/QRd4dnER1IkqdRGuTJuWcQ5EIUOi/xJvKIp8=; b=N+FsZVCwGrF17GbxLLQUqdAZgRpD0xDyTtE0V5XVxnhkwmFjNAbrRAqK E1zDxnHq24RykikZWEiy6GFJ+LimoQJS1S0pAX3txx07sr83/L06MVZbl /PNW4eiOD16DX789zu22/xGaafdyBjxGA8AvbcSuLd3r4OUWXkRu8Iv0v s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAHrzzVCtJV2Z/2dsb2JhbABFiRqjBYkLAYZPgkkWc4IeAQEBBAEBAWsJAhACAQgRAwECCx0HIQYLFAkIAgQOBQgBh3gDDwyvWA2JVYt0aYNiYQOSV4FdgnKKG4URgnOCIg X-IronPort-AV: E=Sophos;i="4.84,294,1355097600"; d="scan'208,217";a="153484924" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 16 Dec 2012 16:16:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBGGGdx4006040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 16:16:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 16 Dec 2012 10:16:38 -0600 From: "Carlos Pignataro (cpignata)" To: Kireeti Kompella Thread-Topic: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt Thread-Index: AQHN26i61pBvDgYtvUO7JXu4csIevg== Date: Sun, 16 Dec 2012 16:16:38 +0000 Message-ID: <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.242] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED3227D1CDCxmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 16:16:41 -0000 --_000_95067C434CE250468B77282634C96ED3227D1CDCxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Kireeti, This is a very nicely written document that covers important aspects. One early comment is that, in a way, this seems to actually be multi-part d= ocument, including requirements, as well as compliance and performance test= ing. One early question is whether it makes sense to take each part separat= ely (even in different WGs, with one as a BCP in mpls in other in bmwg cont= inuation of rfc5695). I also agree with Andy's comments about some PW specific pieces to this. Some more specific comments, hopefully these are clear and useful: 2.1. Forwarding Basics Should this section also include forwarding specifics about reserved labels= , and in particular RA. 2.3. MPLS Multipath Techniques ... The most common multipath techniques are ECMP applied at the IP forwarding level, Ethernet LAG with inspection of the IP payload, and multipath on links carrying both IP and MPLS, where the IP header is inspected below the MPLS label stack. In most core networks, the vast majority of traffic is MPLS encapsulated. In order to support an adequately even load distribution across multiple links, IP addresses must be used. Common practice today is to reinspect the IP addresses at each LSR and use the label stack and IP addresses in a hash performed at each LSR. This description might appear oversimplified, especially in the presence of= BCP128. It was interesting that RFC 4928 is not cited, when it contains a = whole section on current ECMP practices at http://tools.ietf.org/html/bcp12= 8#section-2. Further, this section describes how in addition to IP addresse= s, some cases use the label stack (alone or in combination) as input into t= he hash for multipath. 2.3.1. Pseudowire Control Word Within the core of a network some form of multipath is almost certain to be used. Multipath techniques deployed today are likely to be looking beneath the label stack for an opportunity to hash on IP addresses. A pseudowire encapsulated at a network edge must have a means to prevent reordering within the core if the pseudowire will be crossing a network core, or any part of a network topology where multipath is used. Not supporting the ability to encapsulate a pseudowire with a control word may lock a product out from consideration. A pseudowire capability without control word support might be sufficient for applications which are strictly both intra-metro and low bandwidth. However a provider with other applications will very likely not tolerate having equipment which can only support a subset of their pseudowire needs. While I agree with this text, I wonder if it is attempting to set up a new = requirement. For example, although not 2119-capitalized, "A pseudowire enca= psulated at a network edge must have a means to prevent reordering within t= he core". PWE3 has been discussing this topic, but today's specs include PW= Types for which a CW is optional. Similarly, recommendations are already a= t this http://tools.ietf.org/html/bcp128#section-3. 2.3.2. Pseudowire Flow Label ... Any pseudowire which does not carry a flow label is in effect a single microflow (in [RFC2475] terms). This is a bit of a corner-case nit, but for completeness: this is not the c= ase for IP L2 Transport PW without its optional CW (without flow label) htt= p://tools.ietf.org/html/rfc4447#section-4.1. 2.3.2. Pseudowire Flow Label 2.3.3. MPLS Entropy Label (see Section 2.3) This is an editorial nit, but for readability -- it confused me to see a po= inter to S2.3 within S2.3.x (as if there is an (apparent) reading loop). 3. Questions for Suppliers Q#10 Are reserved labels included in the label stack hash? They MUST NOT be included. Could a citation be included for this MUST NOT? Or is this document adding = this requirement? I think there was a mention in RFC 6790, but RFC4928/BCP1= 28 says: Any reserved label, no matter where it is located in the stack, may be included in the computation for load balancing. Modification of the label stack between packets of a single flow could result in re-ordering that flow. That is, were an explicit null or a router-alert label to be added to a packet, that packet could take a different path through the network. 4. Forwarding Compliance and Performance Testing I wonder if this complete section should be progressed independently in a s= eparate document. Again, this is an useful well-written document, thanks! -- Carlos. On Oct 8, 2012, at 8:30 PM, Kireeti Kompella > wrote: Hi Folks, I'd spoken on the issue of deep label stacks at the last IETF, and there wa= s interest from chip suppliers, vendors and service providers. Curtis just= submitted the draft; it goes beyond just deep label stacks. There are sug= gestions in the draft on aspects of implementing MPLS forwarding, as well a= s questions to ask regarding an implementation, and things to test. Please read and comment to the list. If you (that includes MPLS WG chairs and ADs) could also formulate your th= oughts on what type of doc (Info, BCP, PS) this should be, that would be ve= ry helpful in moving this discussion forward. Thanks, Kireeti. Begin forwarded message: From: internet-drafts@ietf.org Subject: New Version Notification for draft-villamizar-mpls-forwarding-00.t= xt Date: October 8, 2012 16:49:08PDT To: curtis@occnc.com Cc: kireeti.kompella@gmail.com A new version of I-D, draft-villamizar-mpls-forwarding-00.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-forwarding Revision: 00 Title: MPLS Forwarding Compliance and Performance Requirements Creation date: 2012-10-08 WG ID: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-villamizar-mpls-= forwarding-00.txt Status: http://datatracker.ietf.org/doc/draft-villamizar-mpls-forw= arding Htmlized: http://tools.ietf.org/html/draft-villamizar-mpls-forwardin= g-00 Abstract: This document provides guidelines for implementors regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS label stack is encountered, MPLS UHP operations which require one or more label POP plus a PUSH, guidelines for hashing an MPLS stack and payload for multipath, and conformance and performance requirements for recent pseudowire and MPLS standards. The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_95067C434CE250468B77282634C96ED3227D1CDCxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Kireeti,

This is a very nicely written document that covers important aspects.<= /div>

One early comment is that, in a way, this seems to actually be multi-p= art document, including requirements, as well as compliance and performance= testing. One early question is whether it makes sense to take each part se= parately (even in different WGs, with one as a BCP in mpls in other in bmwg continuation of rfc5695).

I also agree with Andy's comments about some PW specific pieces to thi= s.

Some more specific comments, hopefully these are clear and useful: 

2.1.  Forwarding Basics
Should this section also include forwarding specifics about reserved l= abels, and in particular RA.

2.3.  MPLS Multipath Techniques
...
   The most common multipath techniques are ECMP applied at the IP
   forwarding level, Ethernet LAG with inspection of the IP payload, and
   multipath on links carrying both IP and MPLS, where the IP header is
   inspected below the MPLS label stack.  In most core networks, the
   vast majority of traffic is MPLS encapsulated.

   In order to support an adequately even load distribution across
   multiple links, IP addresses must be used.  Common practice today is
   to reinspect the IP addresses at each LSR and use the label stack and
   IP addresses in a hash performed at each LSR.
This description might appear oversimplified, especially in the presen= ce of BCP128. It was interesting that RFC 4928 is not cited, when it c= ontains a whole section on current ECMP practices at http://tools.ietf.org/html/bcp128#se= ction-2. Further, this section describes how in addition to IP addresses, some case= s use the label stack (alone or in combination) as input into the hash for = multipath.

2.3.1.  Pseudowire Control Word

   Within the core of a network some form of multipath is almost certain
   to be used.  Multipath techniques deployed today are likely to be
   looking beneath the label stack for an opportunity to hash on IP
   addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used.

   Not supporting the ability to encapsulate a pseudowire with a control
   word may lock a product out from consideration.  A pseudowire
   capability without control word support might be sufficient for
   applications which are strictly both intra-metro and low bandwidth.
   However a provider with other applications will very likely not
   tolerate having equipment which can only support a subset of their
   pseudowire needs.

While I agree with this text, I wonder if it is attempting to set up a= new requirement. For example, although not 2119-capitalized, "A pseud= owire encapsulated at a network edge must have a means to prevent reor= dering within the core". PWE3 has been discussing this topic, but today's specs include PW Types for which a CW is optional.= Similarly, recommendations are already at this http://tools.ietf.org/html/bcp128#section= -3.

2.3.2.  Pseudowire Flow Label

...
   Any pseudowire which does not carry a flow label is in effect a
   single microflow (in [RFC2475] terms).
This is a bit of a corner-case nit, but for completeness: this is not = the case for IP L2 Transport PW without its optional CW (without flow label= ) http://to= ols.ietf.org/html/rfc4447#section-4.1.

2.3.2.  Pseudowire Flow Label
2.3.3.  MPLS Entropy Label
   (see Section 2.3)
This is an editorial nit, but for readability -- it confused me to see= a pointer to S2.3 within S2.3.x (as if there is an (apparent) reading loop= ).

3.  Questions for Suppliers
       Q#10  Are reserved labels included in the label stack hash?  Th=
ey
             MUST NOT be included.
Could a citation be included for this MUST NOT? Or is this document ad= ding this requirement? I think there was a mention in RFC 6790, but RFC4928= /BCP128 says:

   Any reserved label, no
   matter where it is located in the stack, may be included in the
   computation for load balancing.  Modification of the label stack
   between packets of a single flow could result in re-ordering that
   flow.  That is, were an explicit null or a router-alert label to be

   added to a packet, that packet could take a diffe=
rent path through
   the network.




4.  Forwarding Compliance and Performance Testing


I wonder if this complete section should be progressed independently i=
n a separate document.

Again, this is an useful well-written document, thanks!

-- Carlos.


On Oct 8, 2012, at 8:30 PM, Kireeti Kompella <kireeti.kompella@gmail.com> wrote:

Hi Folks,

I'd spoken on the issue of deep label stacks at the last IETF, and the= re was interest from chip suppliers, vendors and service providers.  C= urtis just submitted the draft; it goes beyond just deep label stacks. &nbs= p;There are suggestions in the draft on aspects of implementing MPLS forwarding, as well as questions to ask regarding an = implementation, and things to test.

Please read and comment to the list.  

If you (that includes MPLS WG chairs and ADs) could also  formula= te your thoughts on what type of doc (Info, BCP, PS) this should be, that w= ould be very helpful in moving this discussion forward.

Thanks,
Kireeti.

Begin forwarded message:

Subject: New V= ersion Notification for draft-villamizar-mpls-forwarding-00.txt
Date: October 8, = 2012 16:49:08PDT


A new version of I-D, draft-villamizar-mpls-forwarding-00.txt
has been successfully submitted by Curtis Villamizar and posted to the
IETF repository.

Filename: d= raft-villamizar-mpls-forwarding
Revision: 0= 0
Title: MPLS Forwarding= Compliance and Performance Requirements
Creation date: 2012-10-08
WG ID: Individual Subm= ission
Number of pages: 17
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-villamizar-mpls-fo= rwarding-00.txt
Status:          http://data= tracker.ietf.org/doc/draft-villamizar-mpls-forwarding
Htmlized:        http://tools.ietf.org/h= tml/draft-villamizar-mpls-forwarding-00


Abstract:
  This document provides guidelines for implementors regarding MP= LS
  forwarding and a basis for evaluations of forwarding implementa= tions.
  Guidelines cover basic MPLS forwarding, forwarding when a deep = MPLS
  label stack is encountered, MPLS UHP operations which require o= ne or
  more label POP plus a PUSH, guidelines for hashing an MPLS stac= k and
  payload for multipath, and conformance and performance requirem= ents
  for recent pseudowire and MPLS standards.




The IETF Secretariat


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

--_000_95067C434CE250468B77282634C96ED3227D1CDCxmbalnx02ciscoc_-- From wwwrun@rfc-editor.org Sun Dec 16 11:49:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBB21F8928 for ; Sun, 16 Dec 2012 11:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.162 X-Spam-Level: X-Spam-Status: No, score=-102.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjcTFXBb9KuK for ; Sun, 16 Dec 2012 11:49:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 94D1821F88B6 for ; Sun, 16 Dec 2012 11:49:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 9621872E039; Sun, 16 Dec 2012 11:40:49 -0800 (PST) To: kireeti.kompella@gmail.com, jdrake@juniper.net, shane@level3.net, wim.henderickx@alcatel-lucent.com, lucy.yong@huawei.com, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20121216194049.9621872E039@rfc-editor.org> Date: Sun, 16 Dec 2012 11:40:49 -0800 (PST) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6790 (3431) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 19:49:46 -0000 The following errata report has been submitted for RFC6790, "The Use of Entropy Labels in MPLS Forwarding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6790&eid=3431 -------------------------------------- Type: Technical Reported by: Jeff Wheeler Section: 5.2 Original Text ------------- This is an optional, transitive BGP attribute of value 28. Corrected Text -------------- This is an optional, transitive BGP Attribute having Attribute Type Code 28, length 0, and no data. Notes ----- "Value" is (slightly) confusing in this context. The text should also explicitly specify that there isn't Attribute Data and thus the length will be 0. Ambiguity on this matter may lead implementations to utilize the data field in some unforeseen way. Other implementations may then reject the attribute, applying general attribute processing rules, with an Attribute Length Error (RFC 4271 S6.3 paragraph 4.) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6790 (draft-ietf-mpls-entropy-label-06) -------------------------------------- Title : The Use of Entropy Labels in MPLS Forwarding Publication Date : November 2012 Author(s) : K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From mach.chen@huawei.com Sun Dec 16 16:51:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C80021F87D8 for ; Sun, 16 Dec 2012 16:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=3.732, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IvwN000td9R for ; Sun, 16 Dec 2012 16:51:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A38621F87B4 for ; Sun, 16 Dec 2012 16:51:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMN90706; Mon, 17 Dec 2012 00:51:23 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 00:50:23 +0000 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 00:51:20 +0000 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.138]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Mon, 17 Dec 2012 08:51:17 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmXs8JMPgiWuUin9ISR2x/ZbJgcLU2Q Date: Mon, 17 Dec 2012 00:51:17 +0000 Message-ID: References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 00:51:28 -0000 Support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Friday, December 14, 2012 5:01 PM > To: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; > mpls-chairs@tools.ietf.org; Martin Vigoureux > Subject: [mpls] poll to see if we have support to make draft-xu-mpls-in-u= dp an > mpls working group document >=20 > Working group, >=20 > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends January 07, 2013. >=20 > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. >=20 > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. >=20 > From version -04 the authors decided to remove Marshall as a co-author. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Sun Dec 16 17:23:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403D621F8778 for ; Sun, 16 Dec 2012 17:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZzV3669wlSb for ; Sun, 16 Dec 2012 17:23:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9F21F8600 for ; Sun, 16 Dec 2012 17:23:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMN92164; Mon, 17 Dec 2012 01:23:48 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 01:23:44 +0000 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Dec 2012 01:23:45 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.003; Mon, 17 Dec 2012 09:23:41 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmViJ5nrl3LP0WPgxeczSmrrJgcNmoA Date: Mon, 17 Dec 2012 01:23:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07588BE4@szxeml525-mbs.china.huawei.com> References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 01:23:51 -0000 U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4NCg0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIExvYQ0KPiBBbmRlcnNzb24NCj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNMjV IDE3OjAxDQo+IMrVvP7IyzogbXBsc0BpZXRmLm9yZzsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmc7DQo+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBNYXJ0aW4gVmlnb3Vy ZXV4DQo+INb3zOI6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFr ZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQN Cj4gDQo+IFdvcmtpbmcgZ3JvdXAsDQo+IA0KPiBUaGlzIGlzIHRvIHN0YXJ0IGEgInR3byB3ZWVr IiBwb2xsIG9uIGFkb3B0aW5nDQo+IGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMg d29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gRHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlz IHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0aCBvbmUgd2Vlay4NCj4gDQo+IFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcN Cj4gZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzIGF0IGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYW4g dGVjaG5pY2FsDQo+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNw ZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBh ZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gDQo+IFRoaXMgcG9sbCBlbmRz IEphbnVhcnkgMDcsIDIwMTMuDQo+IA0KPiBUaGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3Qg dGhpcyBkb2N1bWVudCAtDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEv IC4NCj4gDQo+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55 IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5DQo+IGRpc2Nsb3NlZC4NCj4gDQo+ IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZv ciB0aGUgSVBSIHBvbGwpDQo+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2Yg dGhlIGF1dGhvcnMuIE1hcnNoYWxsIGhhcw0KPiBkaXNjb250aW51ZWQgYWxsIGludGVyYWN0aW9u cyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlIGF1dGhvciB0ZWFtDQo+IG9mIGRyYWZ0LXh1 LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBncm91cCBjaGFpcnMgaGFzIHRyaWVkIHRvDQo+ IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBv biB0aGUgSVBSIHBvbGwuDQo+IFdlIGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy4NCj4gDQo+ ICBGcm9tIHZlcnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxs IGFzIGEgY28tYXV0aG9yLg0KPiANCj4gL0xvYQ0KPiAobXBscyB3ZyBjby1jaGFpcikNCj4gLS0N Cj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0K PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KPiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRz IE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAg ICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcg bGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0K From kireeti.kompella@gmail.com Sun Dec 16 18:18:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CFF21F87C6 for ; Sun, 16 Dec 2012 18:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgzX5OslbOsu for ; Sun, 16 Dec 2012 18:18:45 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79DFE21F876B for ; Sun, 16 Dec 2012 18:18:45 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3271981pbc.31 for ; Sun, 16 Dec 2012 18:18:45 -0800 (PST) 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=hpk9rBP2R3PF4UMQs19/kHDJwniaeb4cS6FsLQLq578=; b=LHX8KRGQiJqvaj1DJE3eU+H5BGopM5ReBRzywISrqlc7Gs87vJMgGfHb4TpQCsDuFX RzmSfghSvDCeZwPbETZnfZ/DrL9DucrwF2W+Kgc+kkG1M0X1U/K4j7s5yDxYN8+JOWgL Au2itP4Bm4uZgXgGyYNOi2cL1hRjyJH8d1kzV1Vdr0AHc3+3W75k5mf9QecE5Cuv576M FNWaGaQiYglEFJ0SilcHkNtyCK9Jx9HpjIQWjPz8R0WjojY5GmClaBgBa6RnQj5B8b3E WLLBArbnEXGP2/Pcqz7xpBkALh6GhzQ4P/t4KfGzjzCHDxOERDSkQbZsTsYaoxG/+9LB pjqQ== MIME-Version: 1.0 Received: by 10.66.73.105 with SMTP id k9mr38169525pav.37.1355710725164; Sun, 16 Dec 2012 18:18:45 -0800 (PST) Received: by 10.68.216.134 with HTTP; Sun, 16 Dec 2012 18:18:45 -0800 (PST) In-Reply-To: <20121216194049.9621872E039@rfc-editor.org> References: <20121216194049.9621872E039@rfc-editor.org> Date: Sun, 16 Dec 2012 18:18:45 -0800 Message-ID: From: Kireeti Kompella To: RFC Errata System Content-Type: multipart/alternative; boundary=f46d042f9f9a310d7c04d10300b8 Cc: mpls@ietf.org, "" , Ross Callon Subject: Re: [mpls] [Technical Errata Reported] RFC6790 (3431) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:18:46 -0000 --f46d042f9f9a310d7c04d10300b8 Content-Type: text/plain; charset=ISO-8859-1 Jeff, Good point. Seeing the current IDR drama about "low order attribute bits", what's the best way to state this in a future proof way? How about: "This is an optional, transitive BGP attribute of value 28. The Length MUST be set to 0 when sending (as the Value field is empty), and SHOULD be ignored on receipt." Kireeti On Sun, Dec 16, 2012 at 11:40 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC6790, > "The Use of Entropy Labels in MPLS Forwarding". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6790&eid=3431 > > -------------------------------------- > Type: Technical > Reported by: Jeff Wheeler > > Section: 5.2 > > Original Text > ------------- > This is an optional, transitive BGP attribute of value 28. > > Corrected Text > -------------- > This is an optional, transitive BGP Attribute having Attribute Type Code > 28, length 0, and no data. > > Notes > ----- > "Value" is (slightly) confusing in this context. The text should also > explicitly specify that there isn't Attribute Data and thus the length will > be 0. > > Ambiguity on this matter may lead implementations to utilize the data > field in some unforeseen way. Other implementations may then reject the > attribute, applying general attribute processing rules, with an Attribute > Length Error (RFC 4271 S6.3 paragraph 4.) > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6790 (draft-ietf-mpls-entropy-label-06) > -------------------------------------- > Title : The Use of Entropy Labels in MPLS Forwarding > Publication Date : November 2012 > Author(s) : K. Kompella, J. Drake, S. Amante, W. Henderickx, L. > Yong > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > -- Kireeti --f46d042f9f9a310d7c04d10300b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jeff,

Good point.=A0

Seeing the c= urrent IDR drama about "low order attribute bits", what's the= best way to state this in a future proof way?

How about:

"This is= an optional, transitive BGP attribute of value 28. =A0The Length MUST be s= et to 0 when sending (as the Value field is empty), and SHOULD be ignored o= n receipt."

Kireeti


On Sun, Dec 1= 6, 2012 at 11:40 AM, RFC Errata System <rfc-editor@rfc-editor.org<= /a>> wrote:

The following errata report has been submitted for RFC6790,
"The Use of Entropy Labels in MPLS Forwarding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc= =3D6790&eid=3D3431

--------------------------------------
Type: Technical
Reported by: Jeff Wheeler <jsw@inc= oncepts.biz>

Section: 5.2

Original Text
-------------
This is an optional, transitive BGP attribute of value 28.

Corrected Text
--------------
This is an optional, transitive BGP Attribute having Attribute Type Code 28= , length 0, and no data.

Notes
-----
"Value" is (slightly) confusing in this context. =A0The text shou= ld also explicitly specify that there isn't Attribute Data and thus the= length will be 0.

Ambiguity on this matter may lead implementations to utilize the data field= in some unforeseen way. =A0Other implementations may then reject the attri= bute, applying general attribute processing rules, with an Attribute Length= Error (RFC 4271 S6.3 paragraph 4.)

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6790 (draft-ietf-mpls-entropy-label-06)
--------------------------------------
Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The Use of Entropy Labels in MPLS Forwa= rding
Publication Date =A0 =A0: November 2012
Author(s) =A0 =A0 =A0 =A0 =A0 : K. Kompella, J. Drake, S. Amante, W. Hender= ickx, L. Yong
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Multiprotocol Label Switching
Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Routing
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG



--
Kireeti
--f46d042f9f9a310d7c04d10300b8-- From cpignata@cisco.com Sun Dec 16 18:27:58 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4A21F882A for ; Sun, 16 Dec 2012 18:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC5pkykDKtR0 for ; Sun, 16 Dec 2012 18:27:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E119221F8824 for ; Sun, 16 Dec 2012 18:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5203; q=dns/txt; s=iport; t=1355711277; x=1356920877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Dp6leF1+bsbiRu/5WFUObWDMMiKSwtx8obZlYQb7QnI=; b=cDATBhJNo3HQvmdzQG3sYI7hTn+InsZ/eAbP0GFuA3/cPTf1Y22r1YMs GHdIRBywl1QFEY7P7T7DxyFPFkPkZJB7zMCnYPrF8pobjDcg2kXXqhcg4 87evMChKKFHiVwiyDia/hHMjM5sWmd+ZN1BapCVYaaQotFgcYXKr9/V2S U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADOCzlCtJV2d/2dsb2JhbABFvkYWc4IeAQEBAwEBAQFrCwULAgEIGAokIQYLJQIEDgUIAYd4AwkGDK8vDYlVi3Rpg2JhA5Q0jQ2FEYJzgiI X-IronPort-AV: E=Sophos;i="4.84,297,1355097600"; d="scan'208";a="153569155" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 17 Dec 2012 02:27:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBH2Ruq3031824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 02:27:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.91]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sun, 16 Dec 2012 20:27:55 -0600 From: "Carlos Pignataro (cpignata)" To: Kireeti Kompella Thread-Topic: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 Thread-Index: AQHN2/4eSKL5R73cyUiReWde36S3qw== Date: Mon, 17 Dec 2012 02:27:55 +0000 Message-ID: <95067C434CE250468B77282634C96ED3227D2C24@xmb-aln-x02.cisco.com> References: <5087BF31.2020605@pi.nu> <11323_1351174762_50894A6A_11323_5351_1_53C29892C857584299CBF5D05346208A0DF4EA@PEXCVZYM11.corporate.adroot.infra.ftgroup> <14e201cdb2c6$864b6850$92e238f0$@olddog.co.uk> <0D9E31EC-5568-49B1-A0E1-F0FB6B93463E@gmail.com> In-Reply-To: <0D9E31EC-5568-49B1-A0E1-F0FB6B93463E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.242] Content-Type: text/plain; charset="Windows-1252" Content-ID: <254AB57AB363D24CA43D58D79A102AEF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:27:58 -0000 A perhaps slightly different way of thinking of this is what is the value o= f allowing multiple ways to convey the same meaning? Given potential of rep= resenting Explicit-null as {0}, or {15; 0}, or {15; 15; 15; 15; 15; 0}, why= (or why not) allow other than the first? Note that the current text already has (epi ready) a MUST: Any of these values present as an extended special purpose label MUST be interpreted exactly as it would if it was presented as a special purpose label. Please find some additional comments and initial questions on the document,= hopefully these are useful: More substantive: 2. Questions ... 4. The special purpose label value of 3 (the "Implicit Null Label", [RFC3032]) is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how and for what purpose? This seems a bit tactical (or too focused of) a question, especially as com= pared to the other ones. It is also not related to "allocation, retirement,= or extension" of special purpose labels, it concerns with one part of the = use of a value allocated and used. Is this question proposing (implicitly, = no pun intended) to partition the special purpose allocation in DP and CP? = Similarly, there are special purpose / reserved labels that are used in the= DP but not used as labels in signaling/CP specifically. E.g., RA and ELI a= re not used as a label value in signaling (say in a Label Mapping). Should = a question be included as well? Given than the answer (oversimplifying) says 'yes, if you write a Standards= -Track RFC through the MPLS WG', why ask this at all? Status quo seems to b= e that an RTP should be written updating what's in RFC 3032. 2. Questions 3. Answers There appears to be a Question/Answer pair missing. The currently allocated= reserved label values are not sequential (http://www.iana.org/assignments/= mpls-label-values/mpls-label-values.xml). 4-6, 8-12, and 15 are unassigned.= If this document extends the special purpose labels into {15; n}, where sh= ould new values allocated from? First from the non-extended original range = until exhausting it? As a hard requirement? As a discussion point part of W= G work? 3.1. Extended Special Purpose MPLS Label Values Any of these values present as an extended special purpose label MUST be interpreted exactly as it would if it was presented as a special purpose label. In particular, an arbitrary string of consecutive extension labels is legal, and semantically equivalent to a single extension label (note that this string of extension labels MUST be followed by an extended special purpose label that is not the extension label). What are the benefits or tradeoffs of instead saying "0-15 MUST NOT be used= after 15"? 3.2. Process for Retiring Special Purpose Labels b. 12 months after the RFC deprecating the label value is published, ... c. 24 months after the RFC that deprecated the label value was This document will request IANA to release the label value for for future use and assignment. While I see value in deprecating a reserved label so as to not be used in f= urther specifications and developments, what is the rational for allowing p= otential future reassignment of deprecated values? Given that the extended = range is 20 bit - 15 which is quite large for its use, and we know how hard= it is to prove a non-use, why entertain reassignment? More editorial: Allocating and Retiring MPLS Reserved Labels Should the title reflect "Special Purpose" instead of "Reserved" labels? Sh= ould the title include not only allocation and retirement, but also extensi= on of the special purpose label space? 4. IANA Considerations ... 4. Create a new registry called the "Extended Special Purpose MPLS Label Values" registry. The ranges and allocation policies for this registry are as follows (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC4020] is allowed only for those values assigned by Standards Action. Which values are assigned by other schemes not by Standards Action?=20 Thanks, -- Carlos. On Oct 25, 2012, at 12:58 PM, Kireeti Kompella = wrote: > Hi Adrian, >=20 > On Oct 25, 2012, at 08:36 , "Adrian Farrel" wrote: >=20 >> With regard to the (infinite) nesting, we could simply define that label= s 0-15 >> MUST NOT appear after label 15 making the new registry run 16 to 1048575 >=20 > While we could specify this, there are a host of ways people could do sil= ly but innocuous things with the label stack, such as insert 52 explicit nu= lls, or 93 sets of ELI+EL. >=20 > This is a case where my allergy against MUSTs breaks out in full-blown, t= hroat-closing glory =85 which may be an excellent reason for the suggestion= :-) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From internet-drafts@ietf.org Sun Dec 16 21:44:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D8421F8948; Sun, 16 Dec 2012 21:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZt7mRc2A+eC; Sun, 16 Dec 2012 21:44:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D5321F8878; Sun, 16 Dec 2012 21:44:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121217054424.9143.2978.idtracker@ietfa.amsl.com> Date: Sun, 16 Dec 2012 21:44:24 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-use-cases-and-design-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:44:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Applicability; Use Cases and Design Author(s) : Luyuan Fang Nabil Bitar Raymond Zhang Masahiro DAIKOKU Ping Pan Filename : draft-ietf-mpls-tp-use-cases-and-design-03.txt Pages : 14 Date : 2012-12-16 Abstract: This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-use-cases-and-design-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dhruv.ietf@gmail.com Sun Dec 16 22:05:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE5621F8993 for ; Sun, 16 Dec 2012 22:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-6pvfj4YqMw for ; Sun, 16 Dec 2012 22:05:42 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6321F8991 for ; Sun, 16 Dec 2012 22:05:42 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so5087305iaz.31 for ; Sun, 16 Dec 2012 22:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=u3N2Srd3ZgUPdqRFhIxeMRHd1EqUnO1pznMvB3qXXkk=; b=iyAxmI+rj19eKsZSM3yPhdH+Cqzh90O6hxVAISo96v06GhfXb6PQm1Qrh+EdcRDuAr 9HwdIWCZnABhfbnkoOO21U8Ju+CYnGeQeCHRm9ns1D9qhELUnPUpFKOkDvRcXHQwPWqc QLEjeN0/gynObyzP+vjdWQQgR2TOX7bfUrKX8QNIID8+IV4N3H8IGUsYUeT5C39eNU7I 9AZSEj8MHjhT6MpCRninAVQWnvYx9p8lg9iQDfGJe01UWh1dddNrHHU956e3glrlsC2t kRDyWskaR1wqtMhd4I0mlAVMYBZ4336lKH9pqCjG2Ahn9LI7YmPXUlhDw+zC7kQ5O0rJ ITRw== MIME-Version: 1.0 Received: by 10.50.219.129 with SMTP id po1mr8085147igc.35.1355724341661; Sun, 16 Dec 2012 22:05:41 -0800 (PST) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.153.194 with HTTP; Sun, 16 Dec 2012 22:05:41 -0800 (PST) In-Reply-To: <50CAEAD4.6000705@pi.nu> References: <50CAEAD4.6000705@pi.nu> Date: Mon, 17 Dec 2012 11:35:41 +0530 X-Google-Sender-Auth: JhL0U_2xGzo_fQjjXhlV1Om0jNM Message-ID: From: Dhruv Dhody To: Loa Andersson Content-Type: multipart/alternative; boundary=14dae93410cbcc4fa804d1062b86 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 06:05:43 -0000 --14dae93410cbcc4fa804d1062b86 Content-Type: text/plain; charset=ISO-8859-1 Support. On Fri, Dec 14, 2012 at 2:31 PM, Loa Andersson wrote: > Working group, > > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends January 07, 2013. > > There is one IPR claim against this document - > https://datatracker.ietf.org/**ipr/1941/. > > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. > > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. > > From version -04 the authors decided to remove Marshall as a co-author. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --14dae93410cbcc4fa804d1062b86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support.=A0


On= Fri, Dec 14, 2012 at 2:31 PM, Loa Andersson <loa@pi.nu> wrote:
=
Working group,

This is to start a "two week" poll on adopting
draft-xu-mpls-in-udp-06 as an MPLS working group document.
Due to the holiday season this poll has been extended with one week.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.org). Please give an technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends January 07, 2013.

There is one IPR claim against this document -
https:= //datatracker.ietf.org/ipr/1941/ .

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

However, up to version -03 (the document that we used for the IPR poll)
Marshall Eubanks was listed as one of the authors. Marshall has
discontinued all interactions with the IETF, including the author team
of draft-xu-mpls-in-udp-06. The working group chairs has tried to
contact Marshall by other means, to try get a response on the IPR poll.
We have had no success in this.

>From version -04 the authors decided to remove Marshall as a co-author.

/Loa
(mpls wg co-chair)
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0+46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--14dae93410cbcc4fa804d1062b86-- From jsw@inconcepts.biz Sun Dec 16 22:07:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B76C21F899D for ; Sun, 16 Dec 2012 22:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-1mDqN1QnFT for ; Sun, 16 Dec 2012 22:07:54 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7302A21F8993 for ; Sun, 16 Dec 2012 22:07:54 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so5088547iaz.31 for ; Sun, 16 Dec 2012 22:07:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2gEUy9tho+mvVZ+VeIYXFTs5VRh6yns7+ZrRQ46TVqM=; b=dXa52DuhWzaVcVNVCaBIQM0D9PRQooDFttRTz+05RpOB5qsxdjLdT76SivI2pmEGvn OVnq2o/rwGWcmqymUjiz3SE2jYkQO04zvdqqk+EdQXg0OSWiROMD3KS6OYVH8zz4Yk4k uQwR9ElkY1Qr7+PwN7JrX7FdkdpnRd5MwAy3lfF3tBxNvjHfMMIk3cjG6NUcfkp0OynW cmeGBAbE3A2pp47cez1+U6nFZZ0l9WsK3QnuSq6221tBk/fbGLwFGVVc8gJrgwrEGMBJ GPGK3lzNnJ9CW2dq+LGVUB8XBIilCRfCcmKntKVEsk++tpuzao7dn6uUKE6GSv2BWUD4 x41g== MIME-Version: 1.0 Received: by 10.50.195.135 with SMTP id ie7mr8103237igc.8.1355724474053; Sun, 16 Dec 2012 22:07:54 -0800 (PST) Received: by 10.64.132.33 with HTTP; Sun, 16 Dec 2012 22:07:53 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <20121216194049.9621872E039@rfc-editor.org> Date: Mon, 17 Dec 2012 01:07:53 -0500 Message-ID: From: Jeff Wheeler To: Kireeti Kompella Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlG0mnX9bR6GG9eN853W8A/7lGQthAQlyrqaT677u8WdmzvrW8B/rta4UWlLuVFqkeM3VwD Cc: mpls@ietf.org, "" , Ross Callon , RFC Errata System Subject: Re: [mpls] [Technical Errata Reported] RFC6790 (3431) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 06:07:55 -0000 On Sun, Dec 16, 2012 at 9:18 PM, Kireeti Kompella wrote: > How about: > > "This is an optional, transitive BGP attribute of value 28. The Length MUST > be set to 0 when sending (as the Value field is empty), and SHOULD be > ignored on receipt." I think the text I supplied in the errata report is a better way to express the underlying intent, without any confusion, than what you suggest above. "value 28" is actually not correct. The field we are talking about is literally called the Attribute Type Code and should be referred to as such so there is not any confusion. I have made some notes: http://inconcepts.biz/~jsw/img/1121216aa-rfc6790pg14.jpg There is disagreement on IDR about whether "sender," "sending," etc. includes propagators of a route (RR or whatever) or if it only means the originator of a route. You use "sending," above, in the same context as they argue does not mean propagator. I think if you want to be that expressive, then you should declare the mandatory behavior for all of originator, propagator, and receiver. If Length MUST be set to 0 then there is no possibility of data. I think suggesting that a value SHOULD be ignored then confuses the reader. If the Length is not 0, a BGP implementation which recognizes Type Code 28 and knows this Attribute's Length MUST be 0 will follow the general rules, which is the correct behavior. In short, I think the corrected text I supplied is a concise expression of your intent. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From nsheth@contrailsystems.com Sun Dec 16 22:38:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA5721F898B for ; Sun, 16 Dec 2012 22:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbwaB4f0RMYZ for ; Sun, 16 Dec 2012 22:38:05 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F095321F8973 for ; Sun, 16 Dec 2012 22:38:04 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so3395713pbc.31 for ; Sun, 16 Dec 2012 22:38:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=pqW0zxedlC9KEXbgO0/4Ku0oyupuFdWTJIPRZ7nKe9c=; b=iJbRYFMRRpm5+QyRFhRb/9pg2U+7mapV+enFlCiO4a5Dl72wHRjWvfibVIA3qN8vWV DqQr9FLRzlW3kF+RW9I1lhsWnPj/qwJal9qM9KeMq41cY/EJEh3e6TA4wGmV9A90TVbZ NF2yKOy+udRAa0CtZAnqE+1MNVbOohHIS4lqMviZYtzQrQkQOvH7AprqsHUVJyew8vqv Vg81FCILvuiBKI6PqwDeKB+8CLmtNvY4lRNcPTMu+QNTpw/a93kXyReAKJDLrFTw9HWs +ZXNTRty1MOvksYmPwm3rexDlZHXsnKdrJX6/Mkpr9weA0nWFRjSIXJ46q1mInWaCowg s6Mg== Received: by 10.66.78.100 with SMTP id a4mr39915477pax.4.1355726284812; Sun, 16 Dec 2012 22:38:04 -0800 (PST) Received: from [192.168.0.108] (c-24-4-109-72.hsd1.ca.comcast.net. [24.4.109.72]) by mx.google.com with ESMTPS id tq4sm1642739pbc.50.2012.12.16.22.38.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 22:38:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Nischal Sheth In-Reply-To: <50CAEAD4.6000705@pi.nu> Date: Sun, 16 Dec 2012 22:38:04 -0800 Content-Transfer-Encoding: 7bit Message-Id: <8C4ED2A0-F6E7-4DA8-84D1-BEFF0D5557A1@contrailsystems.com> References: <50CAEAD4.6000705@pi.nu> To: mpls@ietf.org X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlS2ij1N5mYG18VnWHEAvkiacQ6n1VrSxI7no4WN3E4QDcGsHKPiGh33+ij185/qioo3bP8 Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 06:38:05 -0000 Support as a co-author. -Nischal From internet-drafts@ietf.org Sun Dec 16 23:58:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30821F847B; Sun, 16 Dec 2012 23:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3VGAemdSeB5; Sun, 16 Dec 2012 23:58:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9962F21F845E; Sun, 16 Dec 2012 23:58:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121217075823.10145.94787.idtracker@ietfa.amsl.com> Date: Sun, 16 Dec 2012 23:58:23 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-use-cases-and-design-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 07:58:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Applicability; Use Cases and Design Author(s) : Luyuan Fang Nabil Bitar Raymond Zhang Masahiro DAIKOKU Ping Pan Filename : draft-ietf-mpls-tp-use-cases-and-design-04.txt Pages : 14 Date : 2012-12-16 Abstract: This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-use-cases-and-design-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lufang@cisco.com Mon Dec 17 01:30:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1521F8A59 for ; Mon, 17 Dec 2012 01:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ctkiR0RiJlN for ; Mon, 17 Dec 2012 01:30:04 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8451B21F8A49 for ; Mon, 17 Dec 2012 01:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=101330; q=dns/txt; s=iport; t=1355736603; x=1356946203; h=from:to:cc:subject:date:message-id:mime-version; bh=YSd4qhU8NY4v3IqRSsSoGvsBQ3+w+nZMKvb9FRvE9qs=; b=GzeajOJ4zlVh6NViM5LASxYaxRGxriNS6+GIgW+xW49ye7Ji3n5flyBu 3k4YyIZSrROndZIjF22HF7uUv5ZEjV23FY1+zRi7XOz1/fUMFzPuQYR6v Zt0Dp6R7tc6KKTWSwEthdi6dS1rLuSjrUPtE9Sp9RxSElFBhmriqLZUUq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0HAKrlzlCtJV2b/2dsb2JhbABFgkmyWAGFGoN2FnOCHgEBAQQtQQsMBgEZAwECCxYBBjkUCQoEDgUIEYd6DLlLjF2DYmEDlyaPLIJzgiI X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208,217";a="153438433" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 17 Dec 2012 09:30:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBH9U2cI014169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 09:30:02 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.18]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 03:30:01 -0600 From: "Luyuan Fang (lufang)" To: Adrian Farrel Thread-Topic: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design Thread-Index: AQHN3DkW3M+XNw6UqkuyE0x0DJ6b+g== Date: Mon, 17 Dec 2012 09:30:01 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93101C1E5D@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.241.4] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD93101C1E5Dxmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-tp-use-cases-and-design@toools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 09:30:08 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD93101C1E5Dxmbrcdx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adrian, Thanks again for your review. Your comments are extremely helpful for us to= improve the quality of this document. We addressed all your comments and reworked the entire document to tidy it = up. Version 03 reflects most changes, 04 has the latest update. http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-04. Please see my comments in-line. -----Original Message----- To: > Subject: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design From: "Adrian Farrel" > Date: Thu, 16 Aug 2012 12:21:17 +0100 Cc: mpls@ietf.org Hi, I have done my AD review of this document as usual before pushing it forward for IETF last call and IESG review. This has generated a long list of comments. Many are formatting and style issues that really should be fixed to make the document acceptable for publication. Others are technical questions that need to be resolved either in discussion or by updates to the document. #LF: We have updated the document to address all your comments, the latest = version is draft-ietf-mpls-tp-use-cases-and-design-04.txt. The volume of changes will make for quite a bit of extra work, I'm afraid. But I think these changes are necessary before I can support this document for publication as an RFC. #LF: Agree that the changes are necessary, we have done significant editing= to update the document, your comments are very very helpful, thanks. Please work with the chairs and the working group to resolve these issues. #LF: Thanks to the chairs for their support and help. And thanks to the WG = members for your review/comments in advance. Thanks, Adrian =3D=3D=3D In reading the document I find the authors are confused about what they mean by MPLS-TP. Is MPLS-TP a profile of the MPLS toolset for use in transport networks? Is it a profile of the MPLS functions that are used in transport networks? Is it a delta to the base MPLS functions? Is it a project to enhance the base MPLS to add features needed for transport networks. This question results in significant ambiguity in the text. For example, you say "MPLS-TP disallowed ECMP", but I think you mean that "ECMP is not appropriate in a transport network, so the MPLS transport profile assumes that ECMP will not be present and the MPLS tools necessary for handling ECMP will not be used." #LF: Fixed in the new version through rewriting. --- Please fix the format nits shown by idnits (page and line lengths). #LF: Fixed. The 04 version is nits free as shown by idnits tool. --- Per the exchanges on the MPLS mailing list, you need to replace "PHP as optional" with "PHP must be disabled by default" #LF: Fixed. The text was in Section 3, Section 3 is now removed. --- It would significantly help the reviewers if you could manage to format the page headers and footers, align the section headings. #LF: Done. --- The Table of Contents is a bit messed up. #LF: Fixed. --- There are a number of random page throws that mess up the formatting. #LF: Fixed. --- This document desperately needs review by a native speaker to tidy the English. While this might not seem critical, the large number of small errors make reading and reviewing hard. They may also obscure some technical issues. #LF: Fixed, tidied the language and improved the clarity. I strongly suggest that the chairs solicit a review from an interested working group member (in return for a mention in the Acknowledgements, or in exchange for beer). #LF: Appreciate WG members to help to review and comment. Acknowledgements = and/or beer work for me, great idea. Here are a few examples from early in the document... - - - - Abstract OLD for Multiprotocol Label Switching Transport profile (MPLS-TP). NEW for the Multiprotocol Label Switching Transport Profile (MPLS-TP). #LF: Fixed. - - - - Abstract OLD The design considerations discussed in this documents ranging from NEW The design considerations discussed in this document range from #LF: Fixed, this sentence is removed in the new version. - - - - Section 1.1 OLD The end of live for many NEW The end of life for many #LF: Fixed. - - - - Section 1.1 OLD MPLS-TP re-use a subset of MPLS base functions NEW MPLS-TP re-uses a subset of MPLS base functions #LF: Fixed. - - - - Section 1.1 OLD MPLS-TP extended current MPLS OAM functions NEW MPLS-TP extended previous MPLS OAM functions #LF: Fixed. --- Why do you consider use of RFC 2119 language to be appropriate in this Informational document? All I could find was an instance of "MUST" that you have inherited from RFC 5654. I think you could usefully tidy this up. #LF: Removed =93Requirements Language=94 paragraph and the reference to RFC= 2119. --- There are too many acronyms used in Section 1 without expansion. #LF: Wrote a new list of terminology, included all acronyms which were used= in the document. --- Section 1.2 I think Henry Yu asked for you to change his affiliation. #LF: Fixed. Section 1.2 is removed. Henry=92s correct address is listed in = the Contributors' addresses section. --- s/2. Terminologies/2. Terminology/ #LF: Done. --- Please clean up Section 2 to remove those acronyms not actually used in the document. For example, APS, DM, SRLG. You'll need to do a search and destroy operation. On the other hand, please search the document for other acronyms such as MSTP. #LF: Done, wrote a new terminology list. Please also decide whether G-ACH or G-ACh. #LF: Done, used G-ACh. --- Section 3 seems a bit of a muddle. Details below, but this discussion makes me wonder what the purpose of Section 3 is. The function of MPLS-TP is well-defined in other documents. By summarising it here you risk leaving out key pieces, and may give the wrong impression about the details. It may be better to cut out this section and leave the document to focus on the uses cases and network design. #LF: Agree. It is better to remove Section 3, done. - - - - Section 3.2 MPLS-TP extended the LSP support from unidirectional to both bi- directional unidirectional support. The implication here is that there is something different in the MPLS data plane in MPLS-TP to support bidirectional LSPs. But I don't think there is. As far as the data plane is concerned, there is no difference between two unidirectional LSPs and one bidirectional LSP. #LF: Fixed, removed Section 3. - - - - Section 3.3 I don't think that the use of an NMS for static provisioning is a "control plane option". Maybe if you retitled the section as "Provisioning". But anyway, I don't see why the ACH is mentioned in this section. #LF: Fixed, removed Section 3. --- The whole of the substantial Section 5.7 amounts to "In MPLS-TP, it is best to provision LSPs with low or zero Relative Delay Time. But there is no discussion of what this means for an MPLS-TP deployment. Furthermore the section ends with... More discussion will be added on how to manage the Relative delay time. ...and this does not convince me that the document is complete. #LF: Rewrote section 5.7. --- Section 6 I would expect this document to examine the security requirements of the different use cases. When is it necessary to use the security tools developed and discussed in the two referenced documents? #LF: Added security discussion on Metro Access and Mobile backhaul use case= s, and some general security risks unique to MPLS-TP discussed in the TP Se= curity FW . --- Could you please split the Authors' Addresses into two sections. Authors' Addresses to match those on the front page, and Contributors' Addresses to capture all the others. #LF: Done. Where does Section 1.2 sit with respect to the Authors and Contributors? Do you really need Section 1.2? #LF: No. Removed Section 1.2. --- s/10. Author's Addresses/10. Authors' Addresses/ #LF: Done. Thank you! Luyuan --_000_0DB8F45437AB844CBB5102F807A0AD93101C1E5Dxmbrcdx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Adria= n,

Thanks a= gain for your review. Your comments are extremely helpful for us to improve= the quality of this document.
We addre= ssed all your comments and reworked the entire document to tidy it up. Vers= ion 03 reflects most changes, 04 has the latest update.
Please s= ee my comments in-line. 

-----Original Message-----
To: <draft-ietf-mpls-tp-use-cases-and-design@toools.ietf.org>
Subj= ect: [mpls] AD review of draft-ietf-mpls-tp-use-cases-and-design
From: "Adrian Farrel" <adrian@olddog.co.uk>
Date: Thu, 16 Aug 2012 12:21:17 +0100

Hi,=

 

I have done my= AD review of this document as usual before pushing it

forward for IE= TF last call and IESG review. This has generated a long

list of commen= ts. Many are formatting and style issues that really

should be fixe= d to make the document acceptable for publication. Others=

are technical = questions that need to be resolved either in discussion

or by updates = to the document.

#LF: We have u= pdated the document to address all your comments, the latest version is draft-ietf-mpls-tp-use-cases-and-= design-04.txt.

 

The volume of = changes will make for quite a bit of extra work, I'm

afraid. But I = think these changes are necessary before I can support

this document = for publication as an RFC.

#LF: Agree tha= t the changes are necessary, we have done significant editing to update the= document, your comments are very very helpful, thanks.

 

Please work wi= th the chairs and the working group to resolve these

issues.=

#LF: Thanks to= the chairs for their support and help. And thanks to the WG members for yo= ur review/comments in advance.

 

Thanks,

Adrian&= nbsp;

=3D=3D=3D=

 

In reading the= document I find the authors are confused about what they=

mean by MPLS-T= P. Is MPLS-TP a profile of the MPLS toolset for use in

transport netw= orks? Is it a profile of the MPLS functions that are used=

in transport n= etworks? Is it a delta to the base MPLS functions? Is it<= /p>

a project to e= nhance the base MPLS to add features needed for transport=

networks.=

 

This question = results in significant ambiguity in the text. For example,

you say "= MPLS-TP disallowed ECMP", but I think you mean that "ECMP is=

not appropriat= e in a transport network, so the MPLS transport profile

assumes that E= CMP will not be present and the MPLS tools necessary for<= /p>

handling ECMP = will not be used." 

#LF: Fixed in = the new version through rewriting. 

---=

 

Please fix the format nits shown by idnits (page and line lengths= ).

#LF: Fixed. The 04 version is nits free as shown by idnits tool.<= /span>

---=

 

Per the exchan= ges on the MPLS mailing list, you need to replace "PHP as

optional"= with "PHP must be disabled by default"

#LF: Fixed. The text was in Section 3, Section 3 is now removed.<= /span>

---=

 

It would signi= ficantly help the reviewers if you could manage to

format the pag= e headers and footers, align the section headings.

#LF: Done.

---

 

The Table of C= ontents is a bit messed up.

#LF: Fixed.

---=

 

There are a nu= mber of random page throws that mess up the formatting.

#LF: Fixed.

---


This document = desperately needs review by a native speaker to tidy the<= /p>

English. While= this might not seem critical, the large number of small<= /p>

errors make re= ading and reviewing hard. They may also obscure some

technical issu= es. 

#LF: Fixed, ti= died the language and improved the clarity.

 

I strongly sug= gest that the chairs solicit a review from an interested<= /p>

working group = member (in return for a mention in the Acknowledgements,<= /p>

or in exchange= for beer).

#LF: Appreciat= e WG members to help to review and comment. Acknowledgements and/= or beer work for me, great idea.

 

Here are a few= examples from early in the document...

- - - -

 

Abstract<= /o:p>

 

OLD=

   for Multiprotocol Label Switching Transport

   profile (MPLS-TP).

NEW=

   for the Multiprotocol Label Switching Transport

   Profile (MPLS-TP). 

#LF: Fixed.

- - - -

 

Abstract<= /o:p>

 

OLD=

   The

   design considerations discussed in this documents ranging from<= /o:p>

NEW=

   The

   design considerations discussed in this document range from&n= bsp;

#LF: Fixed, th= is sentence is removed in the new version.

- - - -

 

Section 1.1


OLD=

The end of liv= e for many

NEW=

The end of lif= e for many

#LF: Fixed. 

- - - -=


Section 1.1

 

OLD=

   MPLS-TP re-use a subset of

   MPLS base functions

NEW=

   MPLS-TP re-uses a subset of

   MPLS base functions 

#LF: Fixed.

- - - -=


Section 1.1

 

OLD=

   MPLS-TP extended current MPLS OAM

   functions

NEW=

   MPLS-TP extended previous MPLS OAM

   functions 

#LF: Fixed. 

---


Why do you con= sider use of RFC 2119 language to be appropriate in this<= /p>

Informational = document? All I could find was an instance of "MUST" that

you have inher= ited from RFC 5654. I think you could usefully tidy this<= /p>

up.&nbs= p;

#LF: Removed = =93Requirements Language=94 paragraph and the reference to RFC 2119.=

---

There are too = many acronyms used in Section 1 without expansion. 

#LF: Wrote a n= ew list of terminology, included all acronyms which were used in the docume= nt.

---


Section 1.2


I think Henry = Yu asked for you to change his affiliation.

#LF: Fixed. Se= ction 1.2 is removed. Henry=92s correct address is listed in the Contributo= rs' addresses section.

---


s/2. Terminolo= gies/2. Terminology/

#LF: Done.

---


Please clean u= p Section 2 to remove those acronyms not actually used in=

the document. = For example, APS, DM, SRLG. You'll need to do a search and

destroy operat= ion. On the other hand, please search the document for

other acronyms= such as MSTP.

#LF: Done, wro= te a new terminology list.

 

Please also de= cide whether G-ACH or G-ACh.

#LF: Done, use= d G-ACh.

---=

 

Section 3 seem= s a bit of a muddle. Details below, but this discussion

makes me wonde= r what the purpose of Section 3 is. The function of

MPLS-TP is wel= l-defined in other documents. By summarising it here you<= /p>

risk leaving o= ut key pieces, and may give the wrong impression about the

details. It ma= y be better to cut out this section and leave the document

to focus on th= e uses cases and network design. 

#LF: Agree. It= is better to remove Section 3, done.

- - - -=


Section 3.2

 

   MPLS-TP extended the LSP support from unidirectional to both bi-

   directional unidirectional support.

 

The implicatio= n here is that there is something different in the MPLS

data plane in = MPLS-TP to support bidirectional LSPs. But I don't think<= /p>

there is. As f= ar as the data plane is concerned, there is no difference=

between two un= idirectional LSPs and one bidirectional LSP. 

#LF: Fixed, re= moved Section 3. 

- - - -=  


Section 3.3

 

I don't think = that the use of an NMS for static provisioning is a

"control = plane option". Maybe if you retitled the section as<= /p>

"Provisio= ning". But anyway, I don't see why the ACH is mentioned in<= /font>

this section.<= /font> 

#LF: Fixed, re= moved Section 3. 

---=

 

The whole of t= he substantial Section 5.7 amounts to "In MPLS-TP, it is

best to provis= ion LSPs with low or zero Relative Delay Time. But there<= /p>

is no discussi= on of what this means for an MPLS-TP deployment.

 

Furthermore th= e section ends with...

 

   More discussion will be added on how to manage the Relative delay

   time.

 

...and this do= es not convince me that the document is complete.

#LF: Rewrote s= ection 5.7.

---

 

Section 6=

 

I would expect= this document to examine the security requirements of the

different use = cases. When is it necessary to use the security tools

developed and = discussed in the two referenced documents? 

#LF: Added sec= urity discussion on Metro Access and Mobile backhaul use cases, and some ge= neral security risks unique to MPLS-TP discussed in the TP Security FW .

---=

 

Could you plea= se split the Authors' Addresses into two sections.

Authors' Addre= sses to match those on the front page, and

Contributors' = Addresses to capture all the others.

#LF: Done.

 

Where does Sec= tion 1.2 sit with respect to the Authors and

Contributors? = Do you really need Section 1.2? 

#LF: No. Remov= ed Section 1.2.

---=

 

s/10.     Author's Addresses/10.  &= nbsp;  Authors' Addresses/ 

#LF: Done.


Thank you!

Luyuan<= /p>

 

--_000_0DB8F45437AB844CBB5102F807A0AD93101C1E5Dxmbrcdx03ciscoc_-- From agmalis@gmail.com Mon Dec 17 05:18:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE24021F8548 for ; Mon, 17 Dec 2012 05:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GCZT39H1oXk for ; Mon, 17 Dec 2012 05:18:29 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id A363221F84E7 for ; Mon, 17 Dec 2012 05:18:29 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9153713ieb.31 for ; Mon, 17 Dec 2012 05:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TOXZExFjQibVfX86st4Yj7uB1a3oNVHqAh1b5M8HmgU=; b=cHYAI31CSqNbhZW7NyXuPeKx/CVJxTgbQcbeoC9NTjIRLsqikOHGvwFFD+xKRlSSAw t48sHdORo1ksTKeTbI2SA+8CiuP4Nid2UZvjYAOw6QKWOvbnh/2GGU9UnCuAipOlB3RJ p5IXZTFTp8r2dkRYqII1tWVVhH0CLVg2Pq298yFipVulglo+dh3ax3SVaD1DoFIOyg5C XNqItH1cOTEMBE+ojUZlMoXlU0paQf0Tb6BT9x6Obj36WM/k0lYihCS4ceqoHrUJpMpj vIIol+PCZDVgCfZ7llUdd9NwS3mkp8ZmMEeL10fwUkgZpF2MoM07nqHB0ys5E45/rErL uEsQ== Received: by 10.50.151.238 with SMTP id ut14mr8837684igb.58.1355750309182; Mon, 17 Dec 2012 05:18:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.51.228 with HTTP; Mon, 17 Dec 2012 05:18:09 -0800 (PST) In-Reply-To: <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> From: "Andrew G. Malis" Date: Mon, 17 Dec 2012 08:18:09 -0500 Message-ID: To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=e89a8f3b9f7d953bb204d10c371d Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 13:18:34 -0000 --e89a8f3b9f7d953bb204d10c371d Content-Type: text/plain; charset=ISO-8859-1 Carlos, On Sun, Dec 16, 2012 at 11:16 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > 2.3.1. Pseudowire Control Word > > Within the core of a network some form of multipath is almost certain > to be used. Multipath techniques deployed today are likely to be > looking beneath the label stack for an opportunity to hash on IP > addresses. > > A pseudowire encapsulated at a network edge must have a means to > prevent reordering within the core if the pseudowire will be crossing > a network core, or any part of a network topology where multipath is > used. > > Not supporting the ability to encapsulate a pseudowire with a control > word may lock a product out from consideration. A pseudowire > capability without control word support might be sufficient for > applications which are strictly both intra-metro and low bandwidth. > However a provider with other applications will very likely not > tolerate having equipment which can only support a subset of their > pseudowire needs. > > > While I agree with this text, I wonder if it is attempting to set up a > new requirement. For example, although not 2119-capitalized, "A pseudowire > encapsulated at a network edge must have a means to prevent reordering > within the core". PWE3 has been discussing this topic, but today's specs > include PW Types for which a CW is optional. Similarly, recommendations are > already at this http://tools.ietf.org/html/bcp128#section-3 > > . > I don't think this is a new requirement at all, it's consistent with the "avoiding ECMP" section (section 2) of RFC 4385. Perhaps just a reference to 4385 should be added here. Cheers, Andy --e89a8f3b9f7d953bb204d10c371d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --e89a8f3b9f7d953bb204d10c371d-- From daviball@cisco.com Mon Dec 17 06:05:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B8E21F8B03 for ; Mon, 17 Dec 2012 06:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6-omBkYcbIR for ; Mon, 17 Dec 2012 06:05:48 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79121F8B00 for ; Mon, 17 Dec 2012 06:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8411; q=dns/txt; s=iport; t=1355753147; x=1356962747; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Bt3t6PV8dBK9hZb2PBpXw29e2naVCSqHbQYNoD2eFQI=; b=eTTy5kCfsghB+HL929iY4nDYD1G2JRE6IYxQK1phf8iPKGUAryqyYSXz 8l0CoETBjQ5vh2nAQnunq41C8oNCzixIvgPz/vIZSAXQIG30hjOIWgsZC c4Z7jyPwMPY/bSQNejJSaU24RKMM8DA89kn+RsXqAwNKorMtd3Q4cmf0J E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMHABwmz1CQ/khL/2dsb2JhbAArGoNIqBuSUBZzgh4BAQEEAQEBJBMxAwQHDAQLEQQBAQEnBxQTHgEJDhOIAQMPDC26CYt0aYRDA4tSiGaBUQGGWoRdhRGCc3ZuJA X-IronPort-AV: E=Sophos;i="4.84,300,1355097600"; d="scan'208";a="79176107" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Dec 2012 14:05:42 +0000 Received: from ensoft-linux3.cisco.com (ensoft-linux3.cisco.com [10.63.23.12]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBHE5gc4015143 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 14:05:42 GMT Received: from daviball by ensoft-linux3.cisco.com with local (Exim 4.76) (envelope-from ) id 1TkbK9-00065F-U5; Mon, 17 Dec 2012 14:05:41 +0000 Date: Mon, 17 Dec 2012 14:05:41 +0000 From: David Ball To: Yoshinori Koike Message-ID: <20121217140541.GN4232@cisco.com> References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> <50CB6508.10804@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50CB6508.10804@lab.ntt.co.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 14:19:24 -0000 Hi Yoshinori, Thanks for your comments. With regards to your proposal, I am still a little unclear on the intended relationship between the dataplane loopback point and the MIP/MEP. Are these always on the same interface? If not, under what conditions could they be on different interfaces? How is the location of the dataplane loopback point determined? To take a concrete example, suppose we have an interface with both a LSP MEP and a PW MEP. OAM packets destined for the LSP MEP will have an LSP label and a GAL, while OAM packets destined for the PW MEP will have an LSP label and a PW label. Client data traffic will also have both an LSP and a PW label. Now, if either the LSP MEP or the PW MEP are put into a loopback mode, all of the client data packets will be looped. But which OAM packets are looped? - If the LSP MEP is put into loopback mode, do the LSP OAM packets get looped? I think so, since RFC6435 says that both data and OAM packets are looped. - If the LSP MEP is put into loopback mode, do the PW OAM packets get looped? Again, I think so. - If the PW MEP is put into loopback mode, do the PW OAM packets get looped? I think yes, this is equivalent to the first case. - If the PW MEP is put into loopback mode, do the LSP OAM packets get looped. Since they do not have a PW label, I am not sure? I think probably they shouldn't be, since there may be other PWs flowing over the same LSP, with different PW labels, right? Regarding ITU-T G.8121 Amd 1 and G.8121.2, the reason the dataplane loopback process was removed from the MTDe figures in the last SG15 meeting was because of this confusing sentence in RFC6435 - in other words, it wasn't clear whether the MTDe function was the right place for them so as to match the behaviour specified in the RFC. The intent of G.8121.2 is to exactly match RFC6435 and the other relevant IETF RFCs. As a result, in the current ITU-T G.8121/G.8121.2, the dataplane loopback processes do not appear in any of the termination or adaptation functions that are specified; so although the processes themselves are defined, they are never applied. The question is, what is the correct place to apply them in the ITU-T model so as to match the RFC? David On Sat, Dec 15, 2012, Yoshinori Koike wrote: > Hello David, > > I agree with original text is confusing and thank you for the > proposal. However, I'm wondering if the proposed text is true and > exactly reflect the intent explained in the notes. > > My suggestion is as follows: > It should be noted that the data-plane loopback function itself is > applied to data-plane loopback point which is different from > MIP/MEP. > > Firstly, the description "the data-plane loopback function may be > applied at MIPs/MEPs" doesn't seem to be true. > > In my understanding, data-plane loopback function can be > set/enabled/disabled at MIP/MEP using a management system but not be > applied to MIP/MEP itself. So I clarified this point in my proposal. > > One of the reason is that MIP/MEP is only involved in OAM packets. > There seems no specification in any RFC, which describe that MIP/MEP > could handle data packets which are not OAM packets . > > In G.8121 amd1, data-plane loopback sink and source are specified > and according to Temporary Document(TD673R1<->R0/Plen) during last > SG15 meeting, the data-plane loopback sink/source was removed from > figures of MTDe_TT_Sk/So Process(Fig.9-14&16). I guess this might be > to avoid a restriction of implementations, however it doesn't seem > to make it possible to apply dataplane loopback point to MIP/MEP. In > realty, if data-plane loopback function is enabled, for data-plane > LB function there is no need to parse the packet except for > outermost label value. > > Secondly, if you need to clarify the relationship between data-plane > LB point at which data-plane LB function is conducted and MIP/MEP at > which data-plane LB function is enabled/configured using management > system, it seems enough just to say the two point usually resides on > the same interface and clarify the binding of two points. I have no > issue on this specification. However, just in case, it seems better > to confirm if the change is ok in ITU-T joint interregnum meeting > Jan 2013, because this is a matter of 8121 or/and G.8121.1. As a > result, I didn't add related text in my proposal. > > I'm not an implementer, so I would appreciate it if you could > correct me if I'm wrong. Thank you in advance. > > Best regards, > > Yoshinori > > > (2012/12/13 3:17), Adrian Farrel wrote: > >Hello, > > > >Authors of RFC 6435: I need to hear from you that you meant the text that David > >suggests. It is very clearly not what you wrote and, if you meant something > >different, it is clear why people are confused! > > > >Working group: I need to hear from you that you agree with David's > >interpretation and support his proposed change. > > > >Only then will I try to work out whether this is a "typo" worthy of an errata > >report, or a technical change needing a revised RFC. > > > >Thanks, > >Adrian > > > >>-----Original Message----- > >>From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>Sent: 12 December 2012 17:45 > >>To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; > >>martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; > >>stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > >>rcallon@juniper.net > >>Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org > >>Subject: [Editorial Errata Reported] RFC6435 (3429) > >> > >> > >>The following errata report has been submitted for RFC6435, > >>"MPLS Transport Profile Lock Instruct and Loopback Functions". > >> > >>-------------------------------------- > >>You may review the report below and at: > >>http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 > >> > >>-------------------------------------- > >>Type: Editorial > >>Reported by: David Ball > >> > >>Section: 4 (para 5) > >> > >>Original Text > >>------------- > >>It should be noted that the data-plane loopback function itself is applied to > >data- > >>plane loopback points residing on different interfaces from MIPs/MEPs. > >> > >>Corrected Text > >>-------------- > >>It should be noted that the data-plane loopback function may be applied at > >>MIPs/MEPs on different interfaces for different LSPs. > >> > >>Notes > >>----- > >>The existing text has caused confusion (specifically, among experts in ITU-T > >SG15 > >>when discussing G.8121.2), in that it seems to suggest that the interface > >where > >>the MIP/MEP is located may be a different interface to the one where the > >>loopback is applied. > >> > >>Having spoken with some of the original authors, it seems this was not the > >intent > >>of this sentence; the intent was to point out that as different LSPs would > >have > >>MIPs/MEPs on different interfaces, the corresponding loopback functions would > >>also be applied on different interfaces. > >> > >>Instructions: > >>------------- > >>This errata is currently posted as "Reported". If necessary, please > >>use "Reply All" to discuss whether it should be verified or > >>rejected. When a decision is reached, the verifying party (IESG) > >>can log in to change the status and edit the report, if necessary. > >> > >>-------------------------------------- > >>RFC6435 (draft-ietf-mpls-tp-li-lb-08) > >>-------------------------------------- > >>Title : MPLS Transport Profile Lock Instruct and Loopback > >Functions > >>Publication Date : November 2011 > >>Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > >Vigoureux, > >>Ed., X. Dai, Ed. > >>Category : PROPOSED STANDARD > >>Source : Multiprotocol Label Switching > >>Area : Routing > >>Stream : IETF > >>Verifying Party : IESG > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > -- > Yoshinori Koike > koike.yoshinori@lab.ntt.co.jp > -- David Ball From cpignata@cisco.com Mon Dec 17 08:56:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACAE21F8B20 for ; Mon, 17 Dec 2012 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.898 X-Spam-Level: X-Spam-Status: No, score=-109.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-AFeFDHNCws for ; Mon, 17 Dec 2012 08:56:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8F21F8B19 for ; Mon, 17 Dec 2012 08:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6086; q=dns/txt; s=iport; t=1355763402; x=1356973002; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VezuIh3qrLTjkv/X05FLNJD1hgzVfk22xv/eL7yAQb4=; b=PGP17R5j6v189pSCNlRfNKo2xCWV0UgbJIoyDp59zGNTkjroPjCcq3PG s2BqNbvgA7vBGsprbz5bCsLa9X+iyuKfC6SP7I4S4VgC32ACuMLVlGpZZ uPfmppQOTYLz0t72c4wURueaGagzWQENgsiyjHrKc8jkaJPKkpsmLZujC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAD5Oz1CtJXG//2dsb2JhbABFtR8BiRMWc4IfAQEEdwIQAgEIIh0HIREUEQIEDgUIh3kDDwywEA2JVYt0aYNiYQOILIwIgnKKG4URgnOCIg X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208,217";a="153820915" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 17 Dec 2012 16:56:41 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBHGuf6V003102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 16:56:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.42]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 10:56:41 -0600 From: "Carlos Pignataro (cpignata)" To: "Andrew G. Malis" Thread-Topic: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt Thread-Index: AQHN26i61pBvDgYtvUO7JXu4csIevpgdXy2AgAA9DgA= Date: Mon, 17 Dec 2012 16:56:40 +0000 Message-ID: <95067C434CE250468B77282634C96ED3227E446E@xmb-aln-x02.cisco.com> References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.242] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED3227E446Exmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:56:43 -0000 --_000_95067C434CE250468B77282634C96ED3227E446Exmbalnx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Andy, On Dec 17, 2012, at 8:18 AM, Andrew G. Malis > wrote: Carlos, On Sun, Dec 16, 2012 at 11:16 AM, Carlos Pignataro (cpignata) > wrote: 2.3.1. Pseudowire Control Word Within the core of a network some form of multipath is almost certain to be used. Multipath techniques deployed today are likely to be looking beneath the label stack for an opportunity to hash on IP addresses. A pseudowire encapsulated at a network edge must have a means to prevent reordering within the core if the pseudowire will be crossing a network core, or any part of a network topology where multipath is used. Not supporting the ability to encapsulate a pseudowire with a control word may lock a product out from consideration. A pseudowire capability without control word support might be sufficient for applications which are strictly both intra-metro and low bandwidth. However a provider with other applications will very likely not tolerate having equipment which can only support a subset of their pseudowire needs. While I agree with this text, I wonder if it is attempting to set up a new = requirement. For example, although not 2119-capitalized, "A pseudowire enca= psulated at a network edge must have a means to prevent reordering within t= he core". PWE3 has been discussing this topic, but today's specs include PW= Types for which a CW is optional. Similarly, recommendations are already a= t this http://tools.ietf.org/html/bcp128#section-3 . I don't think this is a new requirement at all, it's consistent with the "a= voiding ECMP" section (section 2) of RFC 4385. Perhaps just a reference to = 4385 should be added here. That's a good point, a pointer to S2 of RFC 4385 could certainly help. In reading, it appeared to me that the text in this document was a bit stro= nger, applicable to every pseudowire ("A PW encapsulated at a network edge = must have a means to prevent reordering") as opposed to the Section from 43= 85 ("If a PW is sensitive to packet misordering and ..."). Thanks, -- Carlos. Cheers, Andy --_000_95067C434CE250468B77282634C96ED3227E446Exmbalnx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Andy,

On Dec 17, 2012, at 8:18 AM, Andrew G. Malis <agmalis@gmail.com> wrote:

Carlos,

On Sun, Dec 16, 2012 at 11:16 AM, Carlos Pignata= ro (cpignata) <cpignata@cisco.com> wrote:
2.3.1.  Pseudowire Control Word

   Within the core of a network some form of multipath is almost certain
   to be used.  Multipath techniques deployed today are likely to be
   looking beneath the label stack for an opportunity to hash on IP
   addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used.

   Not supporting the ability to encapsulate a pseudowire with a control
   word may lock a product out from consideration.  A pseudowire
   capability without control word support might be sufficient for
   applications which are strictly both intra-metro and low bandwidth.
   However a provider with other applications will very likely not
   tolerate having equipment which can only support a subset of their
   pseudowire needs.

While I agree with this text, I wonder if it is attempting to set up a= new requirement. For example, although not 2119-capitalized, "A pseud= owire encapsulated at a network edge must have a means to prevent reor= dering within the core". PWE3 has been discussing this topic, but today's specs include PW Types for which a CW is optional.= Similarly, recommendations are already at this http://tools.ietf.org/h= tml/bcp128#section-3
 
.

I don't think this is a new requirement at all, it's consistent with the &q= uot;avoiding ECMP" section (section 2) of RFC 4385. Perhaps just a ref= erence to 4385 should be added here.

That's a good point, a pointer to S2 of RFC 4385 could certainly help.=

In reading, it appeared to me that the text in this document was a bit= stronger, applicable to every pseudowire ("A PW encapsulated at a net= work edge must have a means to prevent reordering") as opposed to the = Section from 4385 ("If a PW is sensitive to packet misordering and ...").

Thanks,

-- Carlos.


Cheers,
Andy

--_000_95067C434CE250468B77282634C96ED3227E446Exmbalnx02ciscoc_-- From kireeti.kompella@gmail.com Mon Dec 17 09:42:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E130F21F8B09 for ; Mon, 17 Dec 2012 09:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luKZYwvPAzkI for ; Mon, 17 Dec 2012 09:42:10 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B15A021F8AC2 for ; Mon, 17 Dec 2012 09:42:10 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so3841053pad.31 for ; Mon, 17 Dec 2012 09:42:10 -0800 (PST) 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=JRnSS6/v5TaIcDmJ/DeIGq7bdDE3QELqk3bMtkni4Zg=; b=UXvgInm241vohAYEe57qK1wRJdBReO4PnHpA6ziNfXZN2pTZrflDwJ39Fz9eQa1L1H 5682bgQg/xaakDt4Ha66P2edX6pNQjIqZsWTTPunuoZjM0dUh3i3PX01BbRVQzT0kknT dNUjp2RhPP5y8mmeCtO+s/S5jvv75kNRl0z3QGHNTb7D3uNUYLQrRP/qVOCIx6WdyaoM uG6ooHa/EwihEIVgYvID031aNdXFTmc4RB/qr/L1d1FP3KukK5A3BvS0YrKWxjxTm3R5 7FEzTV6PmXB5liZsH+OwhVO99zPOxSZ9duIZTBl/CARWO0otpFLX0Cpvi1fIlP6syTEm GxxQ== MIME-Version: 1.0 Received: by 10.68.240.36 with SMTP id vx4mr45355132pbc.90.1355766130271; Mon, 17 Dec 2012 09:42:10 -0800 (PST) Received: by 10.68.216.134 with HTTP; Mon, 17 Dec 2012 09:42:10 -0800 (PST) In-Reply-To: <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> References: <20121008234908.29887.1630.idtracker@ietfa.amsl.com> <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> Date: Mon, 17 Dec 2012 09:42:10 -0800 Message-ID: From: Kireeti Kompella To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=047d7b339c2797e7a104d10fe664 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 17:42:13 -0000 --047d7b339c2797e7a104d10fe664 Content-Type: text/plain; charset=ISO-8859-1 Hi Carlos, Agree that this document covers a lot of different topics. The idea was to float it, and gauge the level of interest. If the WG and chairs thinks that it should be split up, that's fine. We will include more about handling reserved labels (aka special purpose labels) in a future version. Good point about RA. Andy answered the PW questions. The MUST NOT for hashing ECMP is (as you say) in RFC 6790. Thanks for your comments! Kireeti On Sun, Dec 16, 2012 at 8:16 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Kireeti, > > This is a very nicely written document that covers important aspects. > > One early comment is that, in a way, this seems to actually be > multi-part document, including requirements, as well as compliance and > performance testing. One early question is whether it makes sense to take > each part separately (even in different WGs, with one as a BCP in mpls in > other in bmwg continuation of rfc5695). > > I also agree with Andy's comments about some PW specific pieces to this. > > Some more specific comments, hopefully these are clear and useful: > > 2.1. Forwarding Basics > > Should this section also include forwarding specifics about reserved > labels, and in particular RA. > > 2.3. MPLS Multipath Techniques > > ... > > The most common multipath techniques are ECMP applied at the IP > forwarding level, Ethernet LAG with inspection of the IP payload, and > multipath on links carrying both IP and MPLS, where the IP header is > inspected below the MPLS label stack. In most core networks, the > vast majority of traffic is MPLS encapsulated. > > In order to support an adequately even load distribution across > multiple links, IP addresses must be used. Common practice today is > to reinspect the IP addresses at each LSR and use the label stack and > IP addresses in a hash performed at each LSR. > > This description might appear oversimplified, especially in the presence > of BCP128. It was interesting that RFC 4928 is not cited, when it contains > a whole section on current ECMP practices at > http://tools.ietf.org/html/bcp128#section-2. Further, this section > describes how in addition to IP addresses, some cases use the label stack > (alone or in combination) as input into the hash for multipath. > > 2.3.1. Pseudowire Control Word > > Within the core of a network some form of multipath is almost certain > to be used. Multipath techniques deployed today are likely to be > looking beneath the label stack for an opportunity to hash on IP > addresses. > > A pseudowire encapsulated at a network edge must have a means to > prevent reordering within the core if the pseudowire will be crossing > a network core, or any part of a network topology where multipath is > used. > > Not supporting the ability to encapsulate a pseudowire with a control > word may lock a product out from consideration. A pseudowire > capability without control word support might be sufficient for > applications which are strictly both intra-metro and low bandwidth. > However a provider with other applications will very likely not > tolerate having equipment which can only support a subset of their > pseudowire needs. > > > While I agree with this text, I wonder if it is attempting to set up a > new requirement. For example, although not 2119-capitalized, "A pseudowire > encapsulated at a network edge must have a means to prevent reordering > within the core". PWE3 has been discussing this topic, but today's specs > include PW Types for which a CW is optional. Similarly, recommendations are > already at this http://tools.ietf.org/html/bcp128#section-3. > > 2.3.2. Pseudowire Flow Label > > ... > Any pseudowire which does not carry a flow label is in effect a > single microflow (in [RFC2475] terms). > > This is a bit of a corner-case nit, but for completeness: this is not the > case for IP L2 Transport PW without its optional CW (without flow label) > http://tools.ietf.org/html/rfc4447#section-4.1. > > 2.3.2. Pseudowire Flow Label > > 2.3.3. MPLS Entropy Label > > (see Section 2.3) > > This is an editorial nit, but for readability -- it confused me to see a > pointer to S2.3 within S2.3.x (as if there is an (apparent) reading loop). > > 3. Questions for Suppliers > > Q#10 Are reserved labels included in the label stack hash? They > MUST NOT be included. > > Could a citation be included for this MUST NOT? Or is this document adding > this requirement? I think there was a mention in RFC 6790, but > RFC4928/BCP128 says: > > Any reserved label, no > matter where it is located in the stack, may be included in the > computation for load balancing. Modification of the label stack > between packets of a single flow could result in re-ordering that > flow. That is, were an explicit null or a router-alert label to be > > added to a packet, that packet could take a different path through > the network. > > 4. Forwarding Compliance and Performance Testing > > I wonder if this complete section should be progressed independently in a > separate document. > > Again, this is an useful well-written document, thanks! > > -- Carlos. > > > On Oct 8, 2012, at 8:30 PM, Kireeti Kompella > wrote: > > Hi Folks, > > I'd spoken on the issue of deep label stacks at the last IETF, and there > was interest from chip suppliers, vendors and service providers. Curtis > just submitted the draft; it goes beyond just deep label stacks. There are > suggestions in the draft on aspects of implementing MPLS forwarding, as > well as questions to ask regarding an implementation, and things to test. > > Please read and comment to the list. > > If you (that includes MPLS WG chairs and ADs) could also formulate your > thoughts on what type of doc (Info, BCP, PS) this should be, that would be > very helpful in moving this discussion forward. > > Thanks, > Kireeti. > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-villamizar-mpls-forwarding-00.txt* > *Date: *October 8, 2012 16:49:08PDT > *To: *curtis@occnc.com > *Cc: *kireeti.kompella@gmail.com > > > A new version of I-D, draft-villamizar-mpls-forwarding-00.txt > has been successfully submitted by Curtis Villamizar and posted to the > IETF repository. > > Filename: draft-villamizar-mpls-forwarding > Revision: 00 > Title: MPLS Forwarding Compliance and Performance Requirements > Creation date: 2012-10-08 > WG ID: Individual Submission > Number of pages: 17 > URL: > http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt > Status: > http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding > Htmlized: > http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00 > > > Abstract: > This document provides guidelines for implementors regarding MPLS > forwarding and a basis for evaluations of forwarding implementations. > Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS > label stack is encountered, MPLS UHP operations which require one or > more label POP plus a PUSH, guidelines for hashing an MPLS stack and > payload for multipath, and conformance and performance requirements > for recent pseudowire and MPLS standards. > > > > > The IETF Secretariat > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > -- Kireeti --047d7b339c2797e7a104d10fe664 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos,

Agree that this document covers a lot of diff= erent topics. =A0The idea was to float it, and gauge the level of interest.= =A0If the WG and chairs thinks that it should be split up, that's fine= .

We will include more about handling reserved labels (ak= a special purpose labels) in a future version. =A0Good point about RA.

Andy answered the PW questions.

The MUST NOT for hashing ECMP is (as you say) in RFC 6790.
<= br>
Thanks for your comments!

Kireeti



On Sun, Dec 16, 2012 at 8:16 AM, Carlos Pignataro (cpignata) <cpignata@ci= sco.com> wrote:
Hi, Kireeti,

This is a very nicely written document that covers important aspects.<= /div>

One early comment is that, in a way, this seems to actually be multi-p= art document, including requirements, as well as compliance and performance= testing. One early question is whether it makes sense to take each part se= parately (even in different WGs, with one as a BCP in mpls in other in bmwg continuation of rfc5695).

I also agree with Andy's comments about some PW specific pieces to= this.

Some more specific comments, hopefully these are clear and useful: 

2.1.  Forwarding Basics
Should this section also include forwarding specifics about reserved l= abels, and in particular RA.

2.3.  MPLS Multipath Techniques
...
   The most common multipath techniques are ECMP applied at the IP
   forwarding level, Ethernet LAG with inspection of the IP payload, and
   multipath on links carrying both IP and MPLS, where the IP header is
   inspected below the MPLS label stack.  In most core networks, the
   vast majority of traffic is MPLS encapsulated.

   In order to support an adequately even load distribution across
   multiple links, IP addresses must be used.  Common practice today is
   to reinspect the IP addresses at each LSR and use the label stack and
   IP addresses in a hash performed at each LSR.
This description might appear oversimplified, especially in the presen= ce of BCP128. It was interesting that RFC=A04928 is not cited, when it cont= ains a whole section on current ECMP practices at=A0http://tools.ietf.org/ht= ml/bcp128#section-2. Further, this section describes how in addition to IP addresses, some case= s use the label stack (alone or in combination) as input into the hash for = multipath.

2.3.1.  Pseudowire Control Word

   Within the core of a network some form of multipath is almost certain
   to be used.  Multipath techniques deployed today are likely to be
   looking beneath the label stack for an opportunity to hash on IP
   addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used.

   Not supporting the ability to encapsulate a pseudowire with a control
   word may lock a product out from consideration.  A pseudowire
   capability without control word support might be sufficient for
   applications which are strictly both intra-metro and low bandwidth.
   However a provider with other applications will very likely not
   tolerate having equipment which can only support a subset of their
   pseudowire needs.

While I agree with this text, I wonder if it is attempting to set up a= new requirement. For example, although not 2119-capitalized, "A pseud= owire encapsulated at a network edge must have a means to=A0prevent reorder= ing within the core". PWE3 has been discussing this topic, but today's specs include PW Types for which a CW is optio= nal. Similarly, recommendations are already at this=A0http://tools.ietf.org/= html/bcp128#section-3.

2.3.2.  Pseudowire Flow Label

...
   Any pseudowire which does not carry a flow label is in effect a
   single microflow (in [RFC2475] terms).
This is a bit of a corner-case nit, but for completeness: this is not = the case for IP L2 Transport PW without its optional CW (without flow label= )=A0http://tools.ietf.org/html/rfc4447#section-4.1.

2.3.2.  Pseudowire Flow Label
2.3.3.  MPLS Entropy Label
   (see Section 2.3)
This is an editorial nit, but for readability -- it confused me to see= a pointer to S2.3 within S2.3.x (as if there is an (apparent) reading loop= ).

3.  Questions for Suppliers
       Q#10  Are reserved labels included in the label stack hash?  Th=
ey
             MUST NOT be included.
Could a citation be included for this MUST NOT? Or is this document ad= ding this requirement? I think there was a mention in RFC 6790, but RFC4928= /BCP128 says:

   Any reserved label, no
   matter where it is located in the stack, may be included in the
   computation for load balancing.  Modification of the label stack
   between packets of a single flow could result in re-ordering that
   flow.  That is, were an explicit null or a router-alert label to be

   added to a packet, that packet could take a different path through
   the network.




4.  Forwarding Compliance and Performance Testing


I wonder if this complete section should be progressed independently i=
n a separate document.

Again, this is an useful well-written document, thanks!

-- Carlos.


On Oct 8, 2012, at 8:30 PM, Kireeti Kompella <kireeti.kompella@gmail.com&g= t; wrote:

Hi Folks,

I'd spoken on the issue of deep label stacks at the last IETF, and= there was interest from chip suppliers, vendors and service providers. =A0= Curtis just submitted the draft; it goes beyond just deep label stacks. =A0= There are suggestions in the draft on aspects of implementing MPLS forwarding, as well as questions to ask regarding an = implementation, and things to test.

Please read and comment to the list. =A0

If you (that includes MPLS WG chairs and ADs) could also =A0formulate = your thoughts on what type of doc (Info, BCP, PS) this should be, that woul= d be very helpful in moving this discussion forward.

Thanks,
Kireeti.

Begin forwarded message:

Subject: New = Version Notification for draft-villamizar-mpls-forwarding-00.txt
Date: = October 8,= 2012 16:49:08PDT


A new version of I-D, draft-villamizar-mpls-forwarding-00.txt
has been successfully submitted by Curtis Villamizar and posted to the
IETF repository.

Filename: draft-villamizar-mpls= -forwarding
Revision: 00
Title: MPLS Forwarding Compliance and Performance Requirements=
Creation date: 2012-10-08
WG ID: Individual Submission
Number of pages: 17
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0htt= p://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatracker.i= etf.org/doc/draft-villamizar-mpls-forwarding
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html= /draft-villamizar-mpls-forwarding-00


Abstract:
=A0=A0This document provides guidelines for implementors regarding MPLS
=A0=A0forwarding and a basis for evaluations of forwarding implementations.=
=A0=A0Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS =A0=A0label stack is encountered, MPLS UHP operations which require one or<= br> =A0=A0more label POP plus a PUSH, guidelines for hashing an MPLS stack and<= br> =A0=A0payload for multipath, and conformance and performance requirements =A0=A0for recent pseudowire and MPLS standards.




The IETF Secretariat


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls




--
Kireeti
--047d7b339c2797e7a104d10fe664-- From stbryant@cisco.com Mon Dec 17 10:29:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C83121F8BBB; Mon, 17 Dec 2012 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLaiBuWbibVH; Mon, 17 Dec 2012 10:29:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7B21F8B77; Mon, 17 Dec 2012 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=512; q=dns/txt; s=iport; t=1355768985; x=1356978585; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=dck+bk0rjEv/+grlwx0T65yVNVJXXdWaTcqbnH0isYw=; b=Y/7BHA3L7q6Mhyqqc9OS+cYhKtkLWmvHTBb0MFokJeWMcTc9KW7YR4S+ XdBU0GaKOWvdA4NlzJGUoikq6+m5tdO0lekh9XQipor7t7WvOwTmKAOKH WTYM+L1PfdwmoU0tuIdJHUPwobJzgFDs+USmB6Bax4uVayfpKfWsCY4rC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHADZiz1CQ/khR/2dsb2JhbABFg0i6axZzgl1AATwWGAMCAQIBSwEMAQcBAYgPn0aaRZEgA5YKkEiCcw X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208";a="148473663" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2012 18:29:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHITgJR017592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 18:29:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBHITftV009601; Mon, 17 Dec 2012 18:29:41 GMT Message-ID: <50CF64A3.8060208@cisco.com> Date: Mon, 17 Dec 2012 18:29:55 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr mailing list , "mpls@ietf.org" , pce@ietf.org, pim@ietf.org, "idr-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , pce-chairs@tools.ietf.org, pim-chairs@toosl.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" Subject: [mpls] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:29:50 -0000 Hi all, draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. It has been through IETF LC, but we realize that it would be useful for the IDR, MPLS, PCE and PIM working groups to pay special attention to the draft review the sections of this draft that are relevant to their (your) work. I would appreciate feedback from anyone in the WG, but it would be helpful if the WG Chairs could nominate at least one person to review the draft on behalf of the WG. Thanks Stewart From pagarwal@broadcom.com Mon Dec 17 12:19:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED89B21F889C for ; Mon, 17 Dec 2012 12:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qiah0473FM-n for ; Mon, 17 Dec 2012 12:19:12 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD5ED21F8897 for ; Mon, 17 Dec 2012 12:19:11 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 17 Dec 2012 12:17:03 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 17 Dec 2012 12:15:15 -0800 Received: from SJEXCHMB06.corp.ad.broadcom.com ( [fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 17 Dec 2012 12:14:54 -0800 From: "Puneet Agarwal" To: "Loa Andersson" , "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "Martin Vigoureux" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmXWIJe6YiHWk+Hqx5OR02XuZgdccKw Date: Mon, 17 Dec 2012 20:14:53 +0000 Message-ID: References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CD1A235218433189-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:19:13 -0000 I do not support this draft. There are already solutions under consideration in nvo3 (vxlan and nvgre) -= do not see the need another solution. Thanks. =20 -Puneet -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Friday, December 14, 2012 1:01 AM To: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.i= etf.org; Martin Vigoureux Subject: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp= an mpls working group document Working group, This is to start a "two week" poll on adopting draft-xu-mpls-in-udp-06 as an MPLS working group document. Due to the holiday season this poll has been extended with one week. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends January 07, 2013. There is one IPR claim against this document - https://datatracker.ietf.org/ipr/1941/ . All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However, up to version -03 (the document that we used for the IPR poll) Marshall Eubanks was listed as one of the authors. Marshall has discontinued all interactions with the IETF, including the author team of draft-xu-mpls-in-udp-06. The working group chairs has tried to contact Marshall by other means, to try get a response on the IPR poll. We have had no success in this. From version -04 the authors decided to remove Marshall as a co-author. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon Dec 17 15:50:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1694A21F8667; Mon, 17 Dec 2012 15:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv72Y9P4pz5o; Mon, 17 Dec 2012 15:50:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04121F85D9; Mon, 17 Dec 2012 15:50:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217235014.11063.56989.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 15:50:14 -0800 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-security-framework-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 23:50:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Security Framework Author(s) : Luyuan Fang Ben Niven-Jenkins Scott Mansfield Richard F. Graveman Filename : draft-ietf-mpls-tp-security-framework-06.txt Pages : 11 Date : 2012-12-17 Abstract: This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, security requirements for MPLS-TP, and mitigation procedures for MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC5920 "MPLS and GMPLS MPLS and GMPLS security framework" by providing additional security considerations which are applicable to the MPLS-TP extensions. All the security considerations from RFC5920 are assumed to apply. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionality of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-security-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-security-framework-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-security-framework-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Mon Dec 17 20:02:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E7821E804E for ; Mon, 17 Dec 2012 20:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydD0BvtlETL6 for ; Mon, 17 Dec 2012 20:02:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1188D21E8039 for ; Mon, 17 Dec 2012 20:02:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANX92320; Tue, 18 Dec 2012 04:02:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 04:02:08 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 04:02:07 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.003; Tue, 18 Dec 2012 12:02:00 +0800 From: Xuxiaohu To: "S. Davari" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2oXhc4lOuXqSu0yIyoAAYeMNIJgd0uOg Date: Tue, 18 Dec 2012 04:01:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07588EBB@szxeml525-mbs.china.huawei.com> References: <50CAEAD4.6000705@pi.nu> <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.com> In-Reply-To: <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.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.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 04:02:21 -0000 U2hhaHJhbSwNCg0KVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExT LW92ZXItSVAgZW5jYXBzdWxhdGlvbiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2FkLWJhbGFuY2lu ZyBhcHBsaWNhYmlsaXR5IHNvIGZhciB0byB0aG9zZSBvcGVyYXRvcnMgd2hvIGhhcHBlbiB0byBy ZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQIG5l dHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5kIFZYTEFO IGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQgdXNlIGNhc2VzLiBJZiB5b3UgYWJz b2x1dGVseSBiZWxpZXZlIGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBw bGljYXRpb24gdHJhZmZpYyBhY3Jvc3MgSVAgbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBl eGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyIElQIHR1bm5lbGluZyBtZWNoYW5pc21z IHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMsIHBsZWFzZSBzYXkgc28uDQoNCkJ5 IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9udm8zL2N1cnJlbnQvbXNnMDE4NjQuaHRtbCkgaXMganVzdCB0aGUgcmlnaHQgdGhyZWFk IHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9sbG93aW5nIGFyZ3VtZW50IChpLmUuLCB3 aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEgY2VudGVy cykuIEkgaGFkIHRob3VnaHQgeW91IHdvdWxkIHNwZWFrIHVwIGF0IHRoYXQgdGltZS4gU2FkbHks IHN1cnByaXNpbmdseSBzaWxlbnQgdGlsbCBub3cuIA0KDQpTaWdoLCBJIGRpZG4ndCBpbnRlbmQg dG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuIA0KDQpYaWFvaHUNCg0KPiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gUy4NCj4gRGF2YXJpDQo+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI 1SAxMzozNA0KPiDK1bz+yMs6IExvYSBBbmRlcnNzb24NCj4gs63LzTogZHJhZnQteHUtbXBscy1p bi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBw b3J0IHRvIG1ha2UgZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gbXBscyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50DQo+IA0KPiBJIGRvbid0IHN1cHBvcnQgdGhpcyBkcmFmdCBzaW5jZSBpdCBoYXMg bm8gYXBwbGljYXRpb24gaW4gdG9kYXkncyBtb2Rlcm4gbWV0cm8NCj4gYW5kIGNvcmUsIHdoZXJl IE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGljYXRpb24gaW4g aW4gZGF0YQ0KPiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVyIHNv bHV0aW9ucyBzdWNoIGFzIE5WR1JFIGFuZA0KPiBWWExBTi4NCj4gDQo+IEl0IHNlZW1zIHRoZSBh dXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbiBw cm9jZXNzDQo+IGJ5IGFkdmFuY2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4gDQo+IFJlZ2Fy ZHMsDQo+IFNoYWhyYW0NCj4gDQo+IA0KPiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExv YSBBbmRlcnNzb24gPGxvYUBwaS5udT4gd3JvdGU6DQo+IA0KPiA+IFdvcmtpbmcgZ3JvdXAsDQo+ ID4NCj4gPiBUaGlzIGlzIHRvIHN0YXJ0IGEgInR3byB3ZWVrIiBwb2xsIG9uIGFkb3B0aW5nDQo+ ID4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KPiA+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBiZWVuIGV4 dGVuZGVkIHdpdGggb25lIHdlZWsuDQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRz IChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+ID4gZ3JvdXAgbWFp bGluZyBsaXN0IChtcGxzIGF0IGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+ ID4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlm IHlvdSB0aGluayB0aGF0DQo+ID4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBh cyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4NCj4gPiBUaGlzIHBvbGwgZW5kcyBKYW51 YXJ5IDA3LCAyMDEzLg0KPiA+DQo+ID4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRo aXMgZG9jdW1lbnQgLQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEv IC4NCj4gPg0KPiA+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUg d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBv ZiBhbnkgb3RoZXIgSVBSIGNsYWltcyB0aGFuIHRob3NlIGFscmVhZHkNCj4gPiBkaXNjbG9zZWQu DQo+ID4NCj4gPiBIb3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAodGhlIGRvY3VtZW50IHRoYXQg d2UgdXNlZCBmb3IgdGhlIElQUiBwb2xsKQ0KPiA+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3Rl ZCBhcyBvbmUgb2YgdGhlIGF1dGhvcnMuIE1hcnNoYWxsIGhhcw0KPiA+IGRpc2NvbnRpbnVlZCBh bGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0N Cj4gPiBvZiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJz IGhhcyB0cmllZCB0bw0KPiA+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRy eSBnZXQgYSByZXNwb25zZSBvbiB0aGUgSVBSIHBvbGwuDQo+ID4gV2UgaGF2ZSBoYWQgbm8gc3Vj Y2VzcyBpbiB0aGlzLg0KPiA+DQo+ID4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNp ZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBhIGNvLWF1dGhvci4NCj4gPg0KPiA+IC9Mb2ENCj4g PiAobXBscyB3ZyBjby1jaGFpcikNCj4gPiAtLQ0KPiA+DQo+ID4NCj4gPiBMb2EgQW5kZXJzc29u ICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPiBsb2EuYW5kZXJzc29uQGVyaWNzc29u LmNvbQ0KPiA+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxv YUBwaS5udQ0KPiA+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6 ICs0NiAxMCA3MTcgNTIgMTMNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0Bp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxz IG1haWxpbmcgbGlzdA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K From davari@broadcom.com Mon Dec 17 22:32:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E28321F8AF7 for ; Mon, 17 Dec 2012 22:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.716 X-Spam-Level: X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6S3WCNnxchT for ; Mon, 17 Dec 2012 22:32:30 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9D04621F87EC for ; Mon, 17 Dec 2012 22:32:28 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 17 Dec 2012 22:29:12 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 17 Dec 2012 22:32:06 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Mon, 17 Dec 2012 22:31:45 -0800 From: "Shahram Davari" To: Xuxiaohu Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmWPmqZvlc+g02ta7UdXSm87pgZ3hAAgASdM4D//6O8Ew== Date: Tue, 18 Dec 2012 06:31:44 +0000 Message-ID: <0B09397C-B6E5-4847-BBCC-367A9FBABD37@broadcom.com> References: <50CAEAD4.6000705@pi.nu> <63E1EBC2-515C-4661-B038-94DED72295DE@yahoo.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07588EBB@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07588EBB@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CCED2B23R022826503-01-01 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 06:32:32 -0000 Rm9yIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0 aGVyZSBpcyBubyBuZWVkIHRvIGltcHJvdmUgaXQuDQoNClJlZ2FyZHMsDQpTaGFocmFtDQoNCg0K T24gRGVjIDE3LCAyMDEyLCBhdCA4OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWku Y29tPiB3cm90ZToNCg0KPiBTaGFocmFtLA0KPiANCj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVu ZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbiBtZXRob2Qgd2l0aCBh IGJldHRlciBsb2FkLWJhbGFuY2luZyBhcHBsaWNhYmlsaXR5IHNvIGZhciB0byB0aG9zZSBvcGVy YXRvcnMgd2hvIGhhcHBlbiB0byByZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9u IHRyYWZmaWMgYWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3Zl ciBJUCwgTlZHUkUgYW5kIFZYTEFOIGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQg dXNlIGNhc2VzLiBJZiB5b3UgYWJzb2x1dGVseSBiZWxpZXZlIGl0J3MgbWVhbmluZ2xlc3Mgb2Yg dHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYyBhY3Jvc3MgSVAgbmV0d29ya3Mg YW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyIElQ IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMs IHBsZWFzZSBzYXkgc28uDQo+IA0KPiBCeSB0aGUgd2F5LCBpdCBzZWVtcyB0aGlzIChodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwp IGlzIGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBzdWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZv bGxvd2luZyBhcmd1bWVudCAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNlZCBWUE4gaXMg YXBwbGljYWJsZSB0byBkYXRhIGNlbnRlcnMpLiBJIGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVh ayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2lsZW50IHRpbGwgbm93LiAN Cj4gDQo+IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lzZS4g DQo+IA0KPiBYaWFvaHUNCj4gDQo+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+ILeivP7IyzogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFMu DQo+PiBEYXZhcmkNCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4gytW8/sjL OiBMb2EgQW5kZXJzc29uDQo+PiCzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsNCj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+PiDW 98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRy YWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+ IA0KPj4gSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0 aW9uIGluIHRvZGF5J3MgbW9kZXJuIG1ldHJvDQo+PiBhbmQgY29yZSwgd2hlcmUgTVBMUyBpcyBk b21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0aWNhbCBhcHBsaWNhdGlvbiBpbiBpbiBkYXRhDQo+ PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVyIHNvbHV0aW9ucyBz dWNoIGFzIE5WR1JFIGFuZA0KPj4gVlhMQU4uDQo+PiANCj4+IEl0IHNlZW1zIHRoZSBhdXRob3Jz IGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbiBwcm9jZXNz DQo+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+PiANCj4+IFJlZ2FyZHMs DQo+PiBTaGFocmFtDQo+PiANCj4+IA0KPj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAxIEFNLCBM b2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IHdyb3RlOg0KPj4gDQo+Pj4gV29ya2luZyBncm91cCwN Cj4+PiANCj4+PiBUaGlzIGlzIHRvIHN0YXJ0IGEgInR3byB3ZWVrIiBwb2xsIG9uIGFkb3B0aW5n DQo+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Lg0KPj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBiZWVu IGV4dGVuZGVkIHdpdGggb25lIHdlZWsuDQo+Pj4gDQo+Pj4gUGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZw0KPj4+IGdyb3Vw IG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuIHRlY2huaWNh bA0KPj4+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxs eSBpZiB5b3UgdGhpbmsgdGhhdA0KPj4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0 ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPj4+IA0KPj4+IFRoaXMgcG9sbCBlbmRz IEphbnVhcnkgMDcsIDIwMTMuDQo+Pj4gDQo+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2Fp bnN0IHRoaXMgZG9jdW1lbnQgLQ0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXBy LzE5NDEvIC4NCj4+PiANCj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQg b24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+Pj4gdGhhdCB0aGV5IGFyZSBub3Qg YXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5DQo+Pj4gZGlz Y2xvc2VkLg0KPj4+IA0KPj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9jdW1l bnQgdGhhdCB3ZSB1c2VkIGZvciB0aGUgSVBSIHBvbGwpDQo+Pj4gTWFyc2hhbGwgRXViYW5rcyB3 YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4gZGlzY29u dGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZSBhdXRo b3IgdGVhbQ0KPj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBncm91 cCBjaGFpcnMgaGFzIHRyaWVkIHRvDQo+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhlciBtZWFu cywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFIgcG9sbC4NCj4+PiBXZSBoYXZlIGhh ZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+Pj4gDQo+Pj4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0 aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBhIGNvLWF1dGhvci4NCj4+PiANCj4+ PiAvTG9hDQo+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+Pj4gLS0NCj4+PiANCj4+PiANCj4+PiBM b2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4gbG9hLmFuZGVy c3NvbkBlcmljc3Nvbi5jb20NCj4+PiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIg ICAgICAgICAgICBsb2FAcGkubnUNCj4+PiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAg ICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQo+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0 DQo+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+PiBtcGxzQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBs c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== From mkonstan@cisco.com Tue Dec 18 07:13:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E921F8545 for ; Tue, 18 Dec 2012 07:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWJ+CFesPcXO for ; Tue, 18 Dec 2012 07:13:48 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC8E21F8530 for ; Tue, 18 Dec 2012 07:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1595; q=dns/txt; s=iport; t=1355843628; x=1357053228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tuvOoEeIZRNzMP1GQeuYDs9pNLkuzKckhugimZ65xBY=; b=JkJ3rBX4AqA7dm+NGOrgh79ezp3zq5yrCJ1wNuz6uWkujTTCIgfidEUy xbT7+XKOtoXGqYP7GhjRGrifFTH0K2qpHcjrEtyRozcXR7OpKcHgXVm8n mRIBJWHrkd7EizxwHjUzfvX8aIMvz3MRwhgJGfP8h009abtXjNQR+xRlj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALiF0FCtJV2d/2dsb2JhbABEviYWc4IeAQEBAwFuBgUFCQICAQgiJBsXJQIEDgUIiAUGqCSQRgSMRQsQg0dhA4gsniaCc4FtNQ X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="154227112" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 18 Dec 2012 15:13:48 +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 qBIFDmob002674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 15:13:48 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.180]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 09:13:47 -0600 From: "Maciek Konstantynowicz (mkonstan)" To: Loa Andersson Thread-Topic: IPR poll on draft-ietf-mpls-ldp-dod Thread-Index: AQHN3TJGQWPNg5Ti0kyeEH/5estEJw== Date: Tue, 18 Dec 2012 15:13:46 +0000 Message-ID: <96EE5A5F6E4E6448B2AC953A71A9739B1579A1@xmb-rcd-x06.cisco.com> References: <50BF105F.5030004@pi.nu> In-Reply-To: <50BF105F.5030004@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.71] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "" , "mpls-chairs@tools.ietf.org" , "Maciek Konstantynowicz \(mkonstan\)" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:29:07 -0000 Loa, I'm not aware of any IPR related to draft-ietf-mpls-ldp-dod. Thanks, Maciek. On 5 Dec 2012, at 09:14, Loa Andersson wrote: > Working Group and authors; >=20 > The authors of draft-ietf-mpls-ldp-dod has indicated that the draft is > ready for working last call. >=20 > Before starting the working group last call we will do an IPR poll to > check whether there is IPR on the document that needs to be disclosed. >=20 > This mail starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-ldp-dod? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The doc= uments will not advance to the next stage until a response > has been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) > --=20 >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 From josh.rogers@twcable.com Tue Dec 18 07:51:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956EB21F8AB7 for ; Tue, 18 Dec 2012 07:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.079 X-Spam-Level: **** X-Spam-Status: No, score=4.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-U7ZGkugNMa for ; Tue, 18 Dec 2012 07:51:06 -0800 (PST) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id F22F621F8AD4 for ; Tue, 18 Dec 2012 07:51:01 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,309,1355115600"; d="scan'208";a="4009356" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Dec 2012 10:49:42 -0500 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.37]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 18 Dec 2012 10:50:49 -0500 From: "Rogers, Josh" To: Shahram Davari , Xuxiaohu Date: Tue, 18 Dec 2012 10:50:47 -0500 Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: Ac3dN3NbQooFApzKQiGeR14+Zlpezg== Message-ID: In-Reply-To: <0B09397C-B6E5-4847-BBCC-367A9FBABD37@broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:51:06 -0000 SSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUgcHJvYmxlbSB0 aGlzIHNvbHV0aW9uDQphZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCg0KLUpvc2gN Cg0KDQpPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2Fk Y29tLmNvbT4gd3JvdGU6DQoNCj5Gb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3Zl ciBJUCBpcyBsZWdhY3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj50byBpbXByb3ZlIGl0Lg0KPg0K PlJlZ2FyZHMsDQo+U2hhaHJhbQ0KPg0KPg0KPk9uIERlYyAxNywgMjAxMiwgYXQgODowMiBQTSwg Ilh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+PiBTaGFocmFtLA0K Pj4NCj4+IFRoaXMgZHJhZnQgaXMgT05MWSBpbnRlbmRlZCB0byBwcm92aWRlIGEgTVBMUy1vdmVy LUlQIGVuY2Fwc3VsYXRpb24NCj4+bWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcg YXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+b3BlcmF0b3JzIHdobyBoYXBwZW4gdG8g cmVxdWlyZSB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+PmFjcm9zcyBJ UCBuZXR3b3Jrcy4gSSBiZWxpZXZlIE1QTFMtYmFzZWQgVlBOIG92ZXIgSVAsIE5WR1JFIGFuZCBW WExBTg0KPj5lYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYg eW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj5pdCdzIG1lYW5pbmdsZXNzIG9mIHRyYW5zcG9ydGlu ZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQDQo+Pm5ldHdvcmtzIGFuZCB0aGVy ZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMgb3ZlciBJUA0KPj50dW5u ZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVh c2Ugc2F5IHNvLg0KPj4NCj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+KGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9udm8zL2N1cnJlbnQvbXNnMDE4NjQuaHRtbCkg aXMNCj4+anVzdCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUg Zm9sbG93aW5nIGFyZ3VtZW50DQo+PihpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQ TiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEgY2VudGVycykuIEkNCj4+aGFkIHRob3VnaHQgeW91IHdv dWxkIHNwZWFrIHVwIGF0IHRoYXQgdGltZS4gU2FkbHksIHN1cnByaXNpbmdseSBzaWxlbnQNCj4+ dGlsbCBub3cuDQo+Pg0KPj4gU2lnaCwgSSBkaWRuJ3QgaW50ZW5kIHRvIHNheSB0aGUgYWJvdmUg b3RoZXJ3aXNlLg0KPj4NCj4+IFhpYW9odQ0KPj4NCj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+ PiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBTLg0KPj4+IERhdmFyaQ0KPj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAx MzozNA0KPj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPj4+ILOty806IGRyYWZ0LXh1LW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOw0KPj4+IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQo+Pj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZl IHN1cHBvcnQgdG8gbWFrZQ0KPj4+ZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4+PiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+Pg0KPj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0 IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj5tb2Rlcm4gbWV0cm8N Cj4+PiBhbmQgY29yZSwgd2hlcmUgTVBMUyBpcyBkb21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0 aWNhbCBhcHBsaWNhdGlvbg0KPj4+aW4gaW4gZGF0YQ0KPj4+IGNlbnRlciwgd2hpY2ggYWxyZWFk eSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1Y2ggYXMgTlZHUkUgYW5kDQo+Pj4g VlhMQU4uDQo+Pj4NCj4+PiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFz cyB0aGUgTlZPMyBzb2x1dGlvbiBzZWxlY3Rpb24NCj4+PnByb2Nlc3MNCj4+PiBieSBhZHZhbmNp bmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+IFNoYWhyYW0N Cj4+Pg0KPj4+DQo+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29u IDxsb2FAcGkubnU+IHdyb3RlOg0KPj4+DQo+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+Pj4+DQo+Pj4+ IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4gZHJh ZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRl ZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pg0KPj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChz dXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+Pj4+IGdyb3VwIG1haWxp bmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuIHRlY2huaWNhbA0KPj4+ PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYg eW91IHRoaW5rIHRoYXQNCj4+Pj4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBh cyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+Pj4+DQo+Pj4+IFRoaXMgcG9sbCBlbmRzIEph bnVhcnkgMDcsIDIwMTMuDQo+Pj4+DQo+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0gYWdhaW5z dCB0aGlzIGRvY3VtZW50IC0NCj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIv MTk0MS8gLg0KPj4+Pg0KPj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQg b24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+Pj4+IHRoYXQgdGhleSBhcmUgbm90 IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UgYWxyZWFkeQ0KPj4+PiBk aXNjbG9zZWQuDQo+Pj4+DQo+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9j dW1lbnQgdGhhdCB3ZSB1c2VkIGZvciB0aGUgSVBSDQo+Pj4+cG9sbCkNCj4+Pj4gTWFyc2hhbGwg RXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+ Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGlu ZyB0aGUgYXV0aG9yIHRlYW0NCj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3 b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8NCj4+Pj4gY29udGFjdCBNYXJzaGFsbCBi eSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj5wb2xs Lg0KPj4+PiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+Pj4+DQo+Pj4+IEZyb20g dmVyc2lvbiAtMDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0K Pj4+PmNvLWF1dGhvci4NCj4+Pj4NCj4+Pj4gL0xvYQ0KPj4+PiAobXBscyB3ZyBjby1jaGFpcikN Cj4+Pj4gLS0NCj4+Pj4NCj4+Pj4NCj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDoNCj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KPj4+PiBTciBT dHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4+Pj4g RXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1 MiAxMw0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2 IDc2NyA3MiA5MiAxMw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbXBscyBtYWls aW5nIGxpc3QNCj4+PiBtcGxzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+IG1wbHNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QN Cj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHBy aXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5n IHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJl c3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFp bCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1h bmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFu ZCBhbnkgcHJpbnRvdXQuDQo= From rcallon@juniper.net Tue Dec 18 08:17:05 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD321F8A2F for ; Tue, 18 Dec 2012 08:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7opnx-3vS4MQ for ; Tue, 18 Dec 2012 08:17:04 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 85E4D21F8887 for ; Tue, 18 Dec 2012 08:17:04 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUNCXAI7vCaqDA4QSxZ7GvzxIOV5YRTTZ@postini.com; Tue, 18 Dec 2012 08:17:04 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Dec 2012 08:16:03 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 18 Dec 2012 08:16:03 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.141) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 18 Dec 2012 08:19:01 -0800 Received: from mail38-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Dec 2012 16:16:01 +0000 Received: from mail38-db3 (localhost [127.0.0.1]) by mail38-db3-R.bigfish.com (Postfix) with ESMTP id 260B014042E for ; Tue, 18 Dec 2012 16:16:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371I542I4015I62a3Izz1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail38-db3 (localhost.localdomain [127.0.0.1]) by mail38-db3 (MessageSwitch) id 1355847319225588_31110; Tue, 18 Dec 2012 16:15:19 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.238]) by mail38-db3.bigfish.com (Postfix) with ESMTP id 341EA340135; Tue, 18 Dec 2012 16:15:19 +0000 (UTC) Received: from CH1PRD0510HT005.namprd05.prod.outlook.com (157.56.244.213) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Dec 2012 16:15:17 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.22]) by CH1PRD0510HT005.namprd05.prod.outlook.com ([10.255.150.40]) with mapi id 14.16.0245.002; Tue, 18 Dec 2012 16:15:10 +0000 From: Ross Callon To: Loa Andersson , Scott Mansfield Thread-Topic: Linear Protection draft liaison response Thread-Index: Ac3X/1M8ipalfg9tQPir2sKyPsjQ6AAYCJaAATZkGuA= Date: Tue, 18 Dec 2012 16:15:09 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309A0EB55@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <50C8707D.8060800@pi.nu> In-Reply-To: <50C8707D.8060800@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PI.NU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls-ads@tools.ietf.org" Subject: Re: [mpls] Linear Protection draft liaison response X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:17:05 -0000 I have one comment / proposed correction to the draft liaison.=20 Specifically, there are two ways to update an RFC. One way is to create a -= bis version of the RFC. This involves a complete re-write of the RFC (and w= hen updating a large and complex RFC is likely to take a lot of effort and = time). The other way is to create a smaller document which updates the RFC.= This in general involves only needing to document the issue and the correc= tion of the issue. In most cases a small RFC that updates a previous RFC ca= n be done more quickly than a complete -bis.=20 For the various possible updates discussed in the liaison statement, we hav= e not yet come to a consensus as a WG whether the correct way to address an= y particular issue would be via a -bis, or via a smaller RFC that updates t= he previous RFC.=20 There are several places where the draft liaison states something along the= lines of "This normal process could be a -bis version of rfcxxxx...". The = liaison should instead state "This normal process could be an update to rfc= xxxx...".=20 Note that a -bis is one form of update to an RFC, and a smaller RFC that up= dates a previous update is another form of update to an RFC. Rewording the = liaison in this manner therefore does not preclude either of the two ways t= o address each of the issues discussed in the liaison.=20 Thanks, Ross -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Wednesday, December 12, 2012 6:55 AM To: mpls@ietf.org; mpls-chairs@tools.ietf.org; mpls-ads@tools.ietf.org; Sco= tt Mansfield; Martin Vigoureux Subject: Linear Protection draft liaison response Working Group, We've had a small team that prepared a response to and incoming liaison from ITU-T SG15 on linear protection; both the liaison and the proposed response is included in this mail. In my opinion this team has done a tremendous job in creating the proposed response. This mail is to start soliciting comments on the response. We need to send the response before the end of the year, but will have meeting the 18th to check that everything is OK. Comments will be useful whenever we get, all the way up to when the response is sent; but they will particular if we get them before 10am (Boston time) on December 18. Thanks to the team (Eric O, Scott M and Yaacov W) for all the work they have put into this, thanks also to the support from our ADs, Adrian and Stewart. /Loa for the wg chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From linda.dunbar@huawei.com Tue Dec 18 14:36:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759C821F87C8 for ; Tue, 18 Dec 2012 14:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmzeOo5+4N+Z for ; Tue, 18 Dec 2012 14:36:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2173F21F87D1 for ; Tue, 18 Dec 2012 14:36:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANY68668; Tue, 18 Dec 2012 22:36:21 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 22:36:12 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 22:36:20 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 18 Dec 2012 14:36:14 -0800 From: Linda Dunbar To: "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmXwFczGQ9jZE+emdWONY86B5gfKoSwgAABz2A= Date: Tue, 18 Dec 2012 22:36:14 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450DB243@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:36:25 -0000 Support.=20 Linda > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Friday, December 14, 2012 3:01 AM > To: mpls@ietf.org; draft-xu-mpls-in-udp@tools.ietf.org; mpls- > chairs@tools.ietf.org; Martin Vigoureux > Subject: [mpls] poll to see if we have support to make draft-xu-mpls- > in-udp an mpls working group document >=20 > Working group, >=20 > This is to start a "two week" poll on adopting > draft-xu-mpls-in-udp-06 as an MPLS working group document. > Due to the holiday season this poll has been extended with one week. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls at ietf.org). Please give an technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. >=20 > This poll ends January 07, 2013. >=20 > There is one IPR claim against this document - > https://datatracker.ietf.org/ipr/1941/ . >=20 > All the active co-authors has stated on the working group mailing list > that they are not aware of any other IPR claims than those already > disclosed. >=20 > However, up to version -03 (the document that we used for the IPR poll) > Marshall Eubanks was listed as one of the authors. Marshall has > discontinued all interactions with the IETF, including the author team > of draft-xu-mpls-in-udp-06. The working group chairs has tried to > contact Marshall by other means, to try get a response on the IPR poll. > We have had no success in this. >=20 > From version -04 the authors decided to remove Marshall as a co-author. >=20 > /Loa > (mpls wg co-chair) > -- >=20 >=20 > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tochio@jp.fujitsu.com Tue Dec 18 15:51:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CBC21E8084 for ; Tue, 18 Dec 2012 15:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.09 X-Spam-Level: X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVCkS7hV62xR for ; Tue, 18 Dec 2012 15:51:33 -0800 (PST) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id E094821E8085 for ; Tue, 18 Dec 2012 15:51:25 -0800 (PST) Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 4913C3EE0BC; Wed, 19 Dec 2012 08:51:20 +0900 (JST) Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 303FB45DE4E; Wed, 19 Dec 2012 08:51:20 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 1991745DE4D; Wed, 19 Dec 2012 08:51:20 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 0E0411DB8038; Wed, 19 Dec 2012 08:51:20 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id BBAC01DB802C; Wed, 19 Dec 2012 08:51:19 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id qBINp9Ij026783; Wed, 19 Dec 2012 08:51:19 +0900 (JST) X-AuditID: 0a19c027-b7f426d000000ea6-7f-50d10177e5f5 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id F3.57.03750.77101D05; Wed, 19 Dec 2012 08:51:19 +0900 (JST) Received: from [127.0.0.1] (dhcp59.dream.flab.fujitsu.co.jp [10.25.144.196]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id qBINpFrR001980; Wed, 19 Dec 2012 08:51:19 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <50D10135.6030301@jp.fujitsu.com> Date: Wed, 19 Dec 2012 08:50:13 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: mpls@ietf.org References: <20121212174431.2DCABB1E002@rfc-editor.org> <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> In-Reply-To: <09d201cdd894$e4aa0700$adfe1500$@olddog.co.uk> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsXCJXkgU7ec8WKAwfNdGhY/em4wW9xaupLV gcljyZKfTB4rNq9kDGCK4rJJSc3JLEst0rdL4MrYvekcc8Fc2YrWTW3sDYyHxbsYOTkkBEwk Du5cxgRhi0lcuLeerYuRi0NI4DGjxIPZDUwQzndGiaebF7JDVJlKTFz3jBHE5hXQlXh6bzkL iM0ioCrxescaZhCbTUBT4trMO2A1ogK+EtN+XWOCqBeUODnzCVi9CJA97epRMJtZQFxi98E1 YDXCAnYSS+60g8WFBNIkjuzuAdvLKWAtcbD5GRNEva7EzRMfoWx5ie1v5zBPYBSchWTFLCRl s5CULWBkXsUoWVacnVieqJeWk5ikl1aalVlSXKqXnK+XVbCJERK46jsYny3SPMQowMGoxMP7 5ceFACHWxLLiytxDjBIczEoivCf/AIV4UxIrq1KL8uOLSnNSiw8xMnFwSjUwttt+2l+69AwD p6PEYi2eq2cl5tQsNvlUmXPkj+zZxI9vKvM8AiR2/W6accqy+u4s8Zf72deslPSMUJfYoT13 7p29XCf3dgS9eT1vdvZUT3ZejdZ5M3L4hCtln59SPMHY8fI/49T0tGu2czgWHlX9cW1dz1ZD AaVNz+Xz37b96zjQavjsoPiGFCWW4oxEQy3mouJEAHleko86AgAA Subject: Re: [mpls] [Editorial Errata Reported] RFC6435 (3429) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:51:36 -0000 Hi Adrian and all. I am OK for David Ball's proposal, since it states more clearly about loopback fucntions, given that his report from authors is correct. Thanks, Yuji (,as one of those discussing G.8121.2 and its editor) (2012/12/13 3:17), Adrian Farrel wrote: > Hello, > > Authors of RFC 6435: I need to hear from you that you meant the text that David > suggests. It is very clearly not what you wrote and, if you meant something > different, it is clear why people are confused! > > Working group: I need to hear from you that you agree with David's > interpretation and support his proposed change. > > Only then will I try to work out whether this is a "typo" worthy of an errata > report, or a technical change needing a revised RFC. > > Thanks, > Adrian > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 12 December 2012 17:45 >> To: sboutros@cisco.com; msiva@cisco.com; raggarwa_1@yahoo.com; >> martin.vigoureux@alcatel-lucent.com; dai.xuehui@zte.com.cn; >> stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; >> rcallon@juniper.net >> Cc: daviball@cisco.com; mpls@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC6435 (3429) >> >> >> The following errata report has been submitted for RFC6435, >> "MPLS Transport Profile Lock Instruct and Loopback Functions". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6435&eid=3429 >> >> -------------------------------------- >> Type: Editorial >> Reported by: David Ball >> >> Section: 4 (para 5) >> >> Original Text >> ------------- >> It should be noted that the data-plane loopback function itself is applied to > data- >> plane loopback points residing on different interfaces from MIPs/MEPs. >> >> Corrected Text >> -------------- >> It should be noted that the data-plane loopback function may be applied at >> MIPs/MEPs on different interfaces for different LSPs. >> >> Notes >> ----- >> The existing text has caused confusion (specifically, among experts in ITU-T > SG15 >> when discussing G.8121.2), in that it seems to suggest that the interface > where >> the MIP/MEP is located may be a different interface to the one where the >> loopback is applied. >> >> Having spoken with some of the original authors, it seems this was not the > intent >> of this sentence; the intent was to point out that as different LSPs would > have >> MIPs/MEPs on different interfaces, the corresponding loopback functions would >> also be applied on different interfaces. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6435 (draft-ietf-mpls-tp-li-lb-08) >> -------------------------------------- >> Title : MPLS Transport Profile Lock Instruct and Loopback > Functions >> Publication Date : November 2011 >> Author(s) : S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. > Vigoureux, >> Ed., X. Dai, Ed. >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From shane@castlepoint.net Tue Dec 18 19:57:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0713721F869E for ; Tue, 18 Dec 2012 19:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6quHdpdKshb for ; Tue, 18 Dec 2012 19:57:52 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 146A821F85FC for ; Tue, 18 Dec 2012 19:57:52 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id B1FC330000E for ; Wed, 19 Dec 2012 03:57:51 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id AACCE30000A; Tue, 18 Dec 2012 20:57:49 -0700 (MST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Tue, 18 Dec 2012 20:57:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rogers, Josh" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 18 20:57:51 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50d13b3f199638347880032 X-DSPAM-Factors: 27, not+#+#+#+you, 0.40000, working+#+#+#+mpls, 0.40000, 13+#+#+Loa, 0.40000, should+#+#+to, 0.40000, up+#+#+03, 0.40000, if+#+have, 0.40000, not+#+#+#+there, 0.40000, 2013+#+#+#+IPR, 0.40000, L2TPv3+#+here's, 0.40000, their+#+advocators, 0.40000, the+#+#+namely, 0.40000, nu+#+#+group, 0.40000, Andersson+%b3%ad%cb%cd, 0.40000, are+#+#+of, 0.40000, that+#+document, 0.40000, response+#+the, 0.40000, ietf+#+mailto, 0.40000, Those+#+#+to, 0.40000, Josh+#+#+#+12, 0.40000, list+#+#+ietf, 0.40000, very+#+#+#+that, 0.40000, This+#+#+start, 0.40000, the+individual, 0.40000, to+#+#+#+to, 0.40000, addressed+#+#+#+not, 0.40000, com+#+#+#+provider, 0.40000, there+#+market, 0.40000 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 03:57:53 -0000 On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" = wrote: > I share your SP perspective, and do not see the problem this solution > addresses in practice any longer. +1. Please do not define yet another MPLS-over-IP encapsulation. The = IETF already standardized MPLS over GRE. The IETF has also standardized = MPLS over L2TPv3/UDP/IP, which had seen some deployment in at least one, = very large operator network that I'm aware of to support carriage of = L3VPN over an IP-only network. =20 See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 [NOTE: the dates the above were published was back in the 2006 = timeframe!] RFC 4665 for requirements related to VPLS that say that VPLS may be = carried over L2TPv3 And, here's evidence showing that at least one vendor has = implemented IPVPN's over L2TPv3: = http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html If there was market demand for MPLS over IP, then clearly it would have = been more widely implemented by equipment vendors, with either MPLS over = GRE or MPLS over L2TPv3. (Where there's a will, there's a way). I = would note that the most likely reasons this did not pan out was there = are several, practical operational benefits one gets from going with = native MPLS encapsulation/switching within the data plane, namely: - MPLS Fast Re-Route - MPLS Traffic Engineering ... to name, but a few. Those have tended to be quite compelling = arguments to 'upgrade' network HW to support MPLS = encapsulation/switching. -shane > -Josh >=20 >=20 > On 12/18/12 12:31 AM, "Shahram Davari" wrote: >=20 >> For service provider domain, MPLS over IP is legacy and there is no = need >> to improve it. >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" wrote: >>=20 >>> Shahram, >>>=20 >>> This draft is ONLY intended to provide a MPLS-over-IP encapsulation >>> method with a better load-balancing applicability so far to those >>> operators who happen to require transporting MPLS application = traffic >>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and = VXLAN >>> each have their own advocators and use cases. If you absolutely = believe >>> it's meaningless of transporting MPLS application traffic across IP >>> networks and therefore those existing RFCs related to MPLS over IP >>> tunneling mechanisms should be moved to Historic status, please say = so. >>>=20 >>> By the way, it seems this >>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) is >>> just the right thread suitable for you to make the following = argument >>> (i.e., whether or not MPLS-based VPN is applicable to data centers). = I >>> had thought you would speak up at that time. Sadly, surprisingly = silent >>> till now. >>>=20 >>> Sigh, I didn't intend to say the above otherwise. >>>=20 >>> Xiaohu >>>=20 >>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED S. >>>> Davari >>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34 >>>> =CA=D5=BC=FE=C8=CB: Loa Andersson >>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; >>>> mpls-chairs@tools.ietf.org >>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make >>>> draft-xu-mpls-in-udp an >>>> mpls working group document >>>>=20 >>>> I don't support this draft since it has no application in today's >>>> modern metro >>>> and core, where MPLS is dominant, and its only practical = application >>>> in in data >>>> center, which already is crowded with other solutions such as NVGRE = and >>>> VXLAN. >>>>=20 >>>> It seems the authors are trying to bypass the NVO3 solution = selection >>>> process >>>> by advancing the draft in MPLS WG. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: >>>>=20 >>>>> Working group, >>>>>=20 >>>>> This is to start a "two week" poll on adopting >>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. >>>>> Due to the holiday season this poll has been extended with one = week. >>>>>=20 >>>>> Please send your comments (support/not support) to the mpls = working >>>>> group mailing list (mpls at ietf.org). Please give an technical >>>>> motivation for your support/not support, especially if you think = that >>>>> the document should not be adopted as a working group document. >>>>>=20 >>>>> This poll ends January 07, 2013. >>>>>=20 >>>>> There is one IPR claim against this document - >>>>> https://datatracker.ietf.org/ipr/1941/ . >>>>>=20 >>>>> All the active co-authors has stated on the working group mailing = list >>>>> that they are not aware of any other IPR claims than those already >>>>> disclosed. >>>>>=20 >>>>> However, up to version -03 (the document that we used for the IPR >>>>> poll) >>>>> Marshall Eubanks was listed as one of the authors. Marshall has >>>>> discontinued all interactions with the IETF, including the author = team >>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried to >>>>> contact Marshall by other means, to try get a response on the IPR >>>>> poll. >>>>> We have had no success in this. >>>>>=20 >>>>> =46rom version -04 the authors decided to remove Marshall as a >>>>> co-author. >>>>>=20 >>>>> /Loa >>>>> (mpls wg co-chair) >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: >>>> loa.andersson@ericsson.com >>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>> +46 767 72 92 13 >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Tue Dec 18 22:50:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663B321F859D for ; Tue, 18 Dec 2012 22:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4G0TqoDMiY7 for ; Tue, 18 Dec 2012 22:50:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0637D21F8597 for ; Tue, 18 Dec 2012 22:50:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMQ12312; Wed, 19 Dec 2012 06:50:19 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 06:50:07 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 14:50:16 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 19 Dec 2012 14:50:13 +0800 From: Xuxiaohu To: Shane Amante , "Rogers, Josh" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3Olzo1M6JwDPXkycxIud0O1KBJgeLvSAgADLHACAAKzhwA== Date: Wed, 19 Dec 2012 06:50:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 06:50:25 -0000 DQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNo YW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDExOjU4DQo+ IMrVvP7IyzogUm9nZXJzLCBKb3NoDQo+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsg ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+IG1wbHNAaWV0Zi5vcmc7IG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUg aWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gbXBs cyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+IA0KPiANCj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4 OjUwIEFNLCAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+DQo+IHdyb3Rl Og0KPiA+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUgdGhlIHBy b2JsZW0gdGhpcyBzb2x1dGlvbg0KPiA+IGFkZHJlc3NlcyBpbiBwcmFjdGljZSBhbnkgbG9uZ2Vy Lg0KPiANCj4gKzEuICBQbGVhc2UgZG8gbm90IGRlZmluZSB5ZXQgYW5vdGhlciBNUExTLW92ZXIt SVAgZW5jYXBzdWxhdGlvbi4gIFRoZSBJRVRGDQo+IGFscmVhZHkgc3RhbmRhcmRpemVkIE1QTFMg b3ZlciBHUkUuICBUaGUgSUVURiBoYXMgYWxzbyBzdGFuZGFyZGl6ZWQgTVBMUw0KPiBvdmVyIEwy VFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBv bmUsIHZlcnkNCj4gbGFyZ2Ugb3BlcmF0b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBvZiB0byBz dXBwb3J0IGNhcnJpYWdlIG9mIEwzVlBOIG92ZXIgYW4NCj4gSVAtb25seSBuZXR3b3JrLg0KDQpI aSBTaGFuZSwNCg0KVGhhbmsgeW91IGZvciB0ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwgZGVw bG95bWVudHMgb2YgTVBMUyBvdmVyIElQIGluIGF0IGxlYXN0IG9uZSwgdmVyeSBsYXJnZSBvcGVy YXRvciBuZXR3b3JrLiBUaGlzIGZhY3QgbXVzdCBiZSB2ZXJ5IHZhbHVhYmxlIHRvIHRob3NlIHBl b3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1QTFMgb3Zl ciBJUCBpbiB0b2RheSdzIFNQIG5ldHdvcmtzLg0KDQo+IFNlZTogUkZDJ3MgNDQ1NCwgNDcxOSwg NDU5MSwgNDM0OSBmb3IgUFdFMyBvdmVyIEwyVFB2Mw0KPiBbTk9URTogdGhlIGRhdGVzIHRoZSBh Ym92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUgMjAwNiB0aW1lZnJhbWUhXQ0KPiAg ICAgIFJGQyA0NjY1IGZvciByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBWUExTIHRoYXQgc2F5IHRo YXQgVlBMUyBtYXkgYmUNCj4gY2FycmllZCBvdmVyIEwyVFB2Mw0KPiAgICAgIEFuZCwgaGVyZSdz IGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRl ZA0KPiBJUFZQTidzIG92ZXIgTDJUUHYzOg0KPiBodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9k b2NzL2lvcy8xMl8wcy9mZWF0dXJlL2d1aWRlL2NzZ2wzdnBuLmh0bWwNCg0KVGhhbmtzIGFnYWlu IGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlvbmVkIGluIHRoaXMg ZHJhZnQgQU5EIG90aGVyIGRyYWZ0cywgdGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2gg Y2FsY3VsYXRpb24gb24gdGhlIFNlc3Npb24gSUQgZmllbGQgaW4gdGhlIEwyVFB2MyBoZWFkZXIg b3IgdGhlIEtleSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciBhcyBkZWZpbmVkIGluIFtSRkMgNTY0 MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNvIGZh ci4gSW4gY29udHJhc3QsIG1vc3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBhbHJlYWR5IGNh cGFibGUgb2YgYmFsYW5jaW5nIElQIHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2Yg dGhlIGZpdmUtdHVwbGUgb2YgVURQIHBhY2tldHMuIEJ5IHVzaW5nIHRoZSBNUExTLWluLVVEUCBl bmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmcgY2FwYWJp bGl0eSBvZiBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJhZ2VkIHdpdGhv dXQgcmVxdWlyaW5nIGFueSBjaGFuZ2UgdG8gdGhlbS4gVGhhdCBpcyB0aGUgbWFqb3IgbW90aXZh dGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBJZiB0aGVy ZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVuIGNsZWFybHkgaXQgd291 bGQgaGF2ZSBiZWVuDQo+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5k b3JzLCB3aXRoIGVpdGhlciBNUExTIG92ZXIgR1JFIG9yDQo+IE1QTFMgb3ZlciBMMlRQdjMuICAo V2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSSB3b3VsZCBub3RlIHRoYXQN Cj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBhbiBvdXQgd2FzIHRoZXJl IGFyZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25lIGdldHMg ZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+IGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nIHdp dGhpbiB0aGUgZGF0YSBwbGFuZSwgbmFtZWx5Og0KPiAtIE1QTFMgRmFzdCBSZS1Sb3V0ZQ0KPiAt IE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPiAuLi4gdG8gbmFtZSwgYnV0IGEgZmV3LiAgVGhv c2UgaGF2ZSB0ZW5kZWQgdG8gYmUgcXVpdGUgY29tcGVsbGluZyBhcmd1bWVudHMNCj4gdG8gJ3Vw Z3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5n Lg0KPiANCj4gLXNoYW5lDQo+IA0KPiANCj4gPiAtSm9zaA0KPiA+DQo+ID4NCj4gPiBPbiAxMi8x OC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2FkY29tLmNvbT4gd3Jv dGU6DQo+ID4NCj4gPj4gRm9yIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAg aXMgbGVnYWN5IGFuZCB0aGVyZSBpcyBubyBuZWVkDQo+ID4+IHRvIGltcHJvdmUgaXQuDQo+ID4+ DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFNoYWhyYW0NCj4gPj4NCj4gPj4NCj4gPj4gT24gRGVjIDE3 LCAyMDEyLCBhdCA4OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90 ZToNCj4gPj4NCj4gPj4+IFNoYWhyYW0sDQo+ID4+Pg0KPiA+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZ IGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbg0KPiA+Pj4g bWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIg dG8gdGhvc2UNCj4gPj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0 aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPiA+Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJ IGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5kIFZYTEFODQo+ID4+PiBl YWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91IGFic29s dXRlbHkgYmVsaWV2ZQ0KPiA+Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBM UyBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUA0KPiA+Pj4gbmV0d29ya3MgYW5kIHRoZXJl Zm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyIElQDQo+ID4+PiB0 dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBw bGVhc2Ugc2F5IHNvLg0KPiA+Pj4NCj4gPj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4g Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21z ZzAxODY0Lmh0bWwpIGlzDQo+ID4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUgZm9y IHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgYXJndW1lbnQNCj4gPj4+IChpLmUuLCB3aGV0aGVy IG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEgY2VudGVycykuIEkN Cj4gPj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5 LCBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+PiB0aWxsIG5vdy4NCj4gPj4+DQo+ID4+PiBTaWdo LCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pg0KPiA+ Pj4gWGlhb2h1DQo+ID4+Pg0KPiA+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+ILeivP7I yzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0 +rHtDQo+IFMuDQo+ID4+Pj4gRGF2YXJpDQo+ID4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNcjV IDEzOjM0DQo+ID4+Pj4gytW8/sjLOiBMb2EgQW5kZXJzc29uDQo+ID4+Pj4gs63LzTogZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+ID4+Pj4gbXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8g c2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+ID4+Pj4gZHJhZnQteHUtbXBscy1pbi11 ZHAgYW4NCj4gPj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pg0KPiA+Pj4+ IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBp biB0b2RheSdzDQo+ID4+Pj4gbW9kZXJuIG1ldHJvDQo+ID4+Pj4gYW5kIGNvcmUsIHdoZXJlIE1Q TFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGljYXRpb24NCj4gPj4+ PiBpbiBpbiBkYXRhDQo+ID4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0 aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBOVkdSRSBhbmQNCj4gPj4+PiBWWExBTi4NCj4gPj4+ Pg0KPiA+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBO Vk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPiA+Pj4+IHByb2Nlc3MNCj4gPj4+PiBieSBhZHZhbmNp bmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzLA0KPiA+Pj4+ IFNoYWhyYW0NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAx IEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4+IFdv cmtpbmcgZ3JvdXAsDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdl ZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMg YW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pj4+PiBEdWUgdG8gdGhlIGhvbGlk YXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBw b3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+ID4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBs cyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuIHRlY2huaWNhbA0KPiA+Pj4+PiBtb3RpdmF0 aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRoaW5r IHRoYXQNCj4gPj4+Pj4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgcG9sbCBlbmRzIEph bnVhcnkgMDcsIDIwMTMuDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0g YWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4gPj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9pcHIvMTk0MS8gLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRo b3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhv c2UgYWxyZWFkeQ0KPiA+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEhvd2V2ZXIs IHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZvciB0aGUgSVBS DQo+ID4+Pj4+IHBvbGwpDQo+ID4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBv bmUgb2YgdGhlIGF1dGhvcnMuIE1hcnNoYWxsIGhhcw0KPiA+Pj4+PiBkaXNjb250aW51ZWQgYWxs IGludGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlIGF1dGhvciB0ZWFtDQo+ ID4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBncm91cCBjaGFp cnMgaGFzIHRyaWVkIHRvDQo+ID4+Pj4+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMs IHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbiB0aGUgSVBSDQo+ID4+Pj4+IHBvbGwuDQo+ID4+Pj4+ IFdlIGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gRnJvbSB2 ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBhDQo+ ID4+Pj4+IGNvLWF1dGhvci4NCj4gPj4+Pj4NCj4gPj4+Pj4gL0xvYQ0KPiA+Pj4+PiAobXBscyB3 ZyBjby1jaGFpcikNCj4gPj4+Pj4gLS0NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gTG9hIEFu ZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDoNCj4gPj4+PiBsb2EuYW5kZXJz c29uQGVyaWNzc29uLmNvbQ0KPiA+Pj4+PiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFn ZXIgICAgICAgICAgICBsb2FAcGkubnUNCj4gPj4+Pj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAg ICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAxMw0KPiA+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQo+ID4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBtcGxzIG1haWxpbmcg bGlzdA0KPiA+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0Bp ZXRmLm9yZw0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4NCj4gPg0KPiA+IFRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlDQo+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUNCj4gdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZQ0KPiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQo+IGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50 cyBvZiBhbmQNCj4gYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UNCj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUt bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0K PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IA0K DQo= From zjbdamo@hotmail.com Tue Dec 18 23:11:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4121F8A53 for ; Tue, 18 Dec 2012 23:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlBMQupKNIb8 for ; Tue, 18 Dec 2012 23:11:55 -0800 (PST) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4966421F8946 for ; Tue, 18 Dec 2012 23:11:55 -0800 (PST) Received: from BLU168-W57 ([65.55.116.9]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Dec 2012 23:11:54 -0800 X-EIP: [u/hbShjkVQn4J/IYXkwyaqYj9wmwHHcT] X-Originating-Email: [zjbdamo@hotmail.com] Message-ID: From: =?utf-8?B?5pu+5bO75rOi?= To: , , , Date: Wed, 19 Dec 2012 15:11:54 +0800 Importance: Normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2012 07:11:54.0916 (UTC) FILETIME=[204B9E40:01CDDDB8] Subject: [mpls] how to fill the PW_Path_ID in vpls scenario. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 07:11:55 -0000 DQpoaSxNYXR0aGV3IEJvY2NpLEdlb3JnZSBTd2FsbG93IGFuZCBFcmljIEdyYXksDQppbiBSRkMg NjM3MCB0aGUgUFdfUGF0aF9JRCBpcyBBR0k6OkExLXtHbG9iYWxfSUQ6Ok5vZGVfSUQ6OkFDX0lE fTo6Wjkte0dsb2JhbF9JRDo6Tm9kZV9JRDo6QUNfSUR9Lg0KVGhlIEFDX0lEIGlzIHJlZmVyIHRv IDUwMDMsYW5kIHRoZSBBQ19JRCBpcyBkZXNjcmliZWQgYXMgYmVsb3cNCiJBdHRhY2htZW50IENp cmN1aXQgKEFDKSBJRCA9IFRoaXMgaXMgYSBmaXhlZC1sZW5ndGggNC1vY3RldCBmaWVsZA0KwqDC oMKgwqDCoMKgIHVzZWQgdG8gZnVydGhlciByZWZpbmUgaWRlbnRpZmljYXRpb24gb2YgYW4gYXR0 YWNobWVudCBjaXJjdWl0IG9uDQrCoMKgwqDCoMKgwqAgdGhlIFBFLsKgIFRoZSBpbmNsdXNpb24g b2YgdGhlIEFDIElEIGlzIHVzZWQgdG8gaWRlbnRpZnkNCsKgwqDCoMKgwqDCoCBpbmRpdmlkdWFs IGF0dGFjaG1lbnQgY2lyY3VpdHMgdGhhdCBzaGFyZSBhIGNvbW1vbiBwcmVmaXguIg0KYnV0IGlu IHZwbHMgc2NlbmFyaW8gYWMgYW5kIHB3IGlzIG5vdCBvbmUgYnkgb25lLHNvIGhvdyB0byBmaWxs IHRoZSBQV19QYXRoX0lEPw0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMhDQoNCkp1bmJvIFplbmcoQm9C bykNCg0KDQogCQkgCSAgIAkJICA= From xuxiaohu@huawei.com Tue Dec 18 23:22:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6221F8A75 for ; Tue, 18 Dec 2012 23:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[AWL=1.640, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs-jNVq6csGx for ; Tue, 18 Dec 2012 23:22:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0096421F8A53 for ; Tue, 18 Dec 2012 23:22:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMQ14933; Wed, 19 Dec 2012 07:22:19 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 07:22:09 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Dec 2012 07:22:17 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 19 Dec 2012 15:22:13 +0800 From: Xuxiaohu To: Shane Amante , "Rogers, Josh" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3Olzo1M6JwDPXkycxIud0O1KBJgeLvSAgADLHACAAKzhwIAAEQ2g Date: Wed, 19 Dec 2012 07:22:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07589205@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-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.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 07:22:23 -0000 > Thanks again for sharing the above information. As mentioned in this draf= t AND > other drafts, the mechanism of performing hash calculation on the Session= ID > field in the L2TPv3 header or the Key field in the GRE header as defined = in [RFC > 5640] is not widely supported by existing core routers so far. In contras= t, most > existing core routers are already capable of balancing IP traffic flows b= ased on > the hash of the five-tuple of UDP packets. By using the MPLS-in-UDP > encapsulation, the already available load-balancing capability of most ex= isting > core routers can be leveraged without requiring any change to them. That = is > the major motivation of this draft. By the way, I guess this may also be the motivation for LISP to use UDP as = a tunneling technology later (See http://psg.com/lists/rrg/2007/msg00802.ht= ml). Best regards, Xiaohu From loa@pi.nu Tue Dec 18 23:27:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DA421F8A0C for ; Tue, 18 Dec 2012 23:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAnXwp9fmEeP for ; Tue, 18 Dec 2012 23:27:30 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 54EF921F85BC for ; Tue, 18 Dec 2012 23:27:30 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 9D09B8244B; Wed, 19 Dec 2012 08:27:28 +0100 (CET) Message-ID: <50D16C60.8060006@pi.nu> Date: Wed, 19 Dec 2012 08:27:28 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07589205@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07589205@szxeml525-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 07:27:31 -0000 Folks, The working group chairs appreciate discussion on working group drafts or drafts intended for the working group, plese continue this discussion! However the subject line refers to an an ongoing poll, when the discussion is continued please change the subject line. /Loa for the wg chairs On 2012-12-19 08:22, Xuxiaohu wrote: >> Thanks again for sharing the above information. As mentioned in this draft AND >> other drafts, the mechanism of performing hash calculation on the Session ID >> field in the L2TPv3 header or the Key field in the GRE header as defined in [RFC >> 5640] is not widely supported by existing core routers so far. In contrast, most >> existing core routers are already capable of balancing IP traffic flows based on >> the hash of the five-tuple of UDP packets. By using the MPLS-in-UDP >> encapsulation, the already available load-balancing capability of most existing >> core routers can be leveraged without requiring any change to them. That is >> the major motivation of this draft. > > By the way, I guess this may also be the motivation for LISP to use UDP as a tunneling technology later (See http://psg.com/lists/rrg/2007/msg00802.html). > > Best regards, > Xiaohu > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Wed Dec 19 00:25:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C621F85A2 for ; Wed, 19 Dec 2012 00:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.608 X-Spam-Level: X-Spam-Status: No, score=-101.608 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1EafhmIB4JD for ; Wed, 19 Dec 2012 00:25:46 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6821F8594 for ; Wed, 19 Dec 2012 00:25:45 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 045518244C; Wed, 19 Dec 2012 09:25:43 +0100 (CET) Message-ID: <50D17A08.8050109@pi.nu> Date: Wed, 19 Dec 2012 09:25:44 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "" Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 08:25:47 -0000 Working Group, This is to start a working group last call on draft-ietf-mpls-ldp-dod-03. This working last call is extended due to the upcoming holidays. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and if you are happy with the document as is also indications of support. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 15, 2013. /Loa for the wg co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wim.henderickx@alcatel-lucent.com Wed Dec 19 05:47:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E246D21F8B28 for ; Wed, 19 Dec 2012 05:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vwSaN9E7aPw for ; Wed, 19 Dec 2012 05:47:23 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B931A21F8B26 for ; Wed, 19 Dec 2012 05:47:22 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBJDkxp0001399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Dec 2012 14:47:17 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 19 Dec 2012 14:47:00 +0100 From: "Henderickx, Wim (Wim)" To: Loa Andersson , "mpls@ietf.org" Date: Wed, 19 Dec 2012 14:46:56 +0100 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Thread-Index: Ac3d71Ej8ZLalT35T4eOkt2j48KmRQ== Message-ID: In-Reply-To: <50D17A08.8050109@pi.nu> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 13:47:24 -0000 support On 19/12/12 09:25, "Loa Andersson" wrote: > >Working Group, > >This is to start a working group last call on >draft-ietf-mpls-ldp-dod-03. This working last call is extended >due to the upcoming holidays. > >Please send your comments to the mpls working group mailing >list (mpls@ietf.org). > >Please send both technical comments, and if you are happy with the >document as is also indications of support. > >There are no IPR claims against this draft. > >All the co-authors has stated that they are not ware of any IPRs. > >This working group last call will end on January 15, 2013. > >/Loa >for the wg co-chairs > >--=20 > > >Loa Andersson email: loa.andersson@ericsson.com >Sr Strategy and Standards Manager loa@pi.nu >Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From shane@castlepoint.net Wed Dec 19 06:38:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0CA21F84DB for ; Wed, 19 Dec 2012 06:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.637 X-Spam-Level: * X-Spam-Status: No, score=1.637 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPMpm8hQ3tby for ; Wed, 19 Dec 2012 06:38:41 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 35B5321F84D8 for ; Wed, 19 Dec 2012 06:38:41 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id C5C34300010 for ; Wed, 19 Dec 2012 14:38:32 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2D73230000D; Wed, 19 Dec 2012 07:38:27 -0700 (MST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> Date: Wed, 19 Dec 2012 07:38:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Dec 19 07:38:32 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50d1d168199632288586975 X-DSPAM-Factors: 27, not+#+#+#+you, 0.40000, working+#+#+#+mpls, 0.40000, folks+#+#+#+past, 0.40000, 13+#+#+Loa, 0.40000, should+#+#+to, 0.40000, up+#+#+03, 0.40000, if+#+have, 0.40000, if+#+have, 0.40000, ID+#+#+#+to, 0.40000, snip+#+#+#+separation, 0.40000, not+#+#+#+there, 0.40000, using+the, 0.40000, using+the, 0.40000, folks+#+#+#+internal, 0.40000, 2013+#+#+#+IPR, 0.40000, end+#+that, 0.40000, L2TPv3+#+here's, 0.40000, for+#+packets, 0.40000, their+#+advocators, 0.40000, the+#+#+namely, 0.40000, nu+#+#+group, 0.40000, Andersson+%b3%ad%cb%cd, 0.40000, are+#+#+of, 0.40000, are+#+#+of, 0.40000, fact+#+be, 0.40000, that+#+document, 0.40000, response+#+the, 0.40000 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 14:38:42 -0000 Xiaohu, On Dec 18, 2012, at 11:50 PM, Xuxiaohu wrote: -----=D3=CA=BC=FE=D4=AD=BC=FE----- >> =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net] >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58 >> =CA=D5=BC=FE=C8=CB: Rogers, Josh >> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu; = draft-xu-mpls-in-udp@tools.ietf.org; >> mpls@ietf.org; mpls-chairs@tools.ietf.org >> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make = draft-xu-mpls-in-udp an >> mpls working group document >>=20 >>=20 >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" >> wrote: >>> I share your SP perspective, and do not see the problem this = solution >>> addresses in practice any longer. >>=20 >> +1. Please do not define yet another MPLS-over-IP encapsulation. = The IETF >> already standardized MPLS over GRE. The IETF has also standardized = MPLS >> over L2TPv3/UDP/IP, which had seen some deployment in at least one, = very >> large operator network that I'm aware of to support carriage of L3VPN = over an >> IP-only network. >=20 > Hi Shane, >=20 > Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very = valuable to those people who had believed there is no application of = MPLS over IP in today's SP networks. >=20 >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 >> [NOTE: the dates the above were published was back in the 2006 = timeframe!] >> RFC 4665 for requirements related to VPLS that say that VPLS may = be >> carried over L2TPv3 >> And, here's evidence showing that at least one vendor has = implemented >> IPVPN's over L2TPv3: >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >=20 > Thanks again for sharing the above information. As mentioned in this = draft AND other drafts, the mechanism of performing hash calculation on = the Session ID field in the L2TPv3 header or the Key field in the GRE = header as defined in [RFC 5640] is not widely supported by existing core = routers so far. FWIW, I have had success, in the relatively recent past, in requesting a = core router vendor to support changes to the input-keys used in hash = calculations in _existing_ hardware, already deployed (extensively) = throughout my network. Further, I suspect that most large network = operators are savvy folks and understand the internal architecture of = their HW fairly well. As a result, those same operators know what is = and is not technically possible in this regard. Thus, it may be a = question of "methods" necessary to convince their HW supplier(s) to make = appropriate changes in their equipment to achieve their business goals. = :-) However, this may not even be necessary ... see below. > In contrast, most existing core routers are already capable of = balancing IP traffic flows based on the hash of the five-tuple of UDP = packets. By using the MPLS-in-UDP encapsulation, the already available = load-balancing capability of most existing core routers can be leveraged = without requiring any change to them. That is the major motivation of = this draft. If this is a concern, then why not encapsulate the traffic in = MPLS/L2TPv3, which uses UDP/IP, in the first place? IMHO, a better proposal may be to consider a [minor] (?) change to RFC = 3931, which would allow the connection used for data packets (not = control packets) to use a varying set of source ports (or, source IP = addresses), based on a hash calculation, to achieve better = load-balancing over existing equipment in an IP-only core. L2TP = end-system implementations would be better off just using the "Session = ID" (and "Cookie") fields as the demultiplexor to associate incoming = packets with the associated L2TP Control Channel. In fact, it's not = clear to me that existing implementations may /already/ do this, making = any "check" on the incoming source port unnecessary for L2TP end-system = implementations. The beauty of the above approach is: 1) I would think that the above is most likely a change that is limited = to the "control channel" (software) of existing L2TP end-system = implementations. Heck, it may even be backwards compatible with = existing L2TPv3 implementations. (L2TPv3 implementors would need to = comment on that). 2) There is a substantial added security one gets by using "Session ID" = and "Cookie" fields to ensure the received L2TPv3 packet is intended for = the identified session. Quoting from Section 8.2 of RFC 3931: ---snip--- L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit. ---snip--- ... in regard to this question alone, I know the Security Area folks = have, in the past, had /substantial/ concerns about encapsulation of = MPLS over IP transport. In fact, this is why you see text in Section = 7.6, "Security", of RFC 4665. (There's likely similar language in other = drafts that use MPLS for transport). While I'm not sure that Security = Area folks pay much attention to daily traffic on the MPLS WG mailing = list, I'm fairly confident this concern will arise if/when this draft = goes to the IESG ... 3) Finally, this approach only affects the end-systems that implement = L2TP, for tunneling of MPLS/IP, and does not require an entire industry = to support MPLS/UDP encapsulation in their product lines. -shane >=20 > Best regards, > Xiaohu >=20 >> If there was market demand for MPLS over IP, then clearly it would = have been >> more widely implemented by equipment vendors, with either MPLS over = GRE or >> MPLS over L2TPv3. (Where there's a will, there's a way). I would = note that >> the most likely reasons this did not pan out was there are several, = practical >> operational benefits one gets from going with native MPLS >> encapsulation/switching within the data plane, namely: >> - MPLS Fast Re-Route >> - MPLS Traffic Engineering >> ... to name, but a few. Those have tended to be quite compelling = arguments >> to 'upgrade' network HW to support MPLS encapsulation/switching. >>=20 >> -shane >>=20 >>=20 >>> -Josh >>>=20 >>>=20 >>> On 12/18/12 12:31 AM, "Shahram Davari" wrote: >>>=20 >>>> For service provider domain, MPLS over IP is legacy and there is no = need >>>> to improve it. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>>=20 >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" = wrote: >>>>=20 >>>>> Shahram, >>>>>=20 >>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation >>>>> method with a better load-balancing applicability so far to those >>>>> operators who happen to require transporting MPLS application = traffic >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and = VXLAN >>>>> each have their own advocators and use cases. If you absolutely = believe >>>>> it's meaningless of transporting MPLS application traffic across = IP >>>>> networks and therefore those existing RFCs related to MPLS over IP >>>>> tunneling mechanisms should be moved to Historic status, please = say so. >>>>>=20 >>>>> By the way, it seems this >>>>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) = is >>>>> just the right thread suitable for you to make the following = argument >>>>> (i.e., whether or not MPLS-based VPN is applicable to data = centers). I >>>>> had thought you would speak up at that time. Sadly, surprisingly = silent >>>>> till now. >>>>>=20 >>>>> Sigh, I didn't intend to say the above otherwise. >>>>>=20 >>>>> Xiaohu >>>>>=20 >>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- >>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED >> S. >>>>>> Davari >>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34 >>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersson >>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; >>>>>> mpls-chairs@tools.ietf.org >>>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make >>>>>> draft-xu-mpls-in-udp an >>>>>> mpls working group document >>>>>>=20 >>>>>> I don't support this draft since it has no application in today's >>>>>> modern metro >>>>>> and core, where MPLS is dominant, and its only practical = application >>>>>> in in data >>>>>> center, which already is crowded with other solutions such as = NVGRE and >>>>>> VXLAN. >>>>>>=20 >>>>>> It seems the authors are trying to bypass the NVO3 solution = selection >>>>>> process >>>>>> by advancing the draft in MPLS WG. >>>>>>=20 >>>>>> Regards, >>>>>> Shahram >>>>>>=20 >>>>>>=20 >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: >>>>>>=20 >>>>>>> Working group, >>>>>>>=20 >>>>>>> This is to start a "two week" poll on adopting >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. >>>>>>> Due to the holiday season this poll has been extended with one = week. >>>>>>>=20 >>>>>>> Please send your comments (support/not support) to the mpls = working >>>>>>> group mailing list (mpls at ietf.org). Please give an technical >>>>>>> motivation for your support/not support, especially if you think = that >>>>>>> the document should not be adopted as a working group document. >>>>>>>=20 >>>>>>> This poll ends January 07, 2013. >>>>>>>=20 >>>>>>> There is one IPR claim against this document - >>>>>>> https://datatracker.ietf.org/ipr/1941/ . >>>>>>>=20 >>>>>>> All the active co-authors has stated on the working group = mailing list >>>>>>> that they are not aware of any other IPR claims than those = already >>>>>>> disclosed. >>>>>>>=20 >>>>>>> However, up to version -03 (the document that we used for the = IPR >>>>>>> poll) >>>>>>> Marshall Eubanks was listed as one of the authors. Marshall has >>>>>>> discontinued all interactions with the IETF, including the = author team >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried = to >>>>>>> contact Marshall by other means, to try get a response on the = IPR >>>>>>> poll. >>>>>>> We have had no success in this. >>>>>>>=20 >>>>>>> =46rom version -04 the authors decided to remove Marshall as a >>>>>>> co-author. >>>>>>>=20 >>>>>>> /Loa >>>>>>> (mpls wg co-chair) >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: >>>>>> loa.andersson@ericsson.com >>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>> +46 767 72 92 13 >>>>>>> _______________________________________________ >>>>>>> mpls mailing list >>>>>>> mpls@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> _______________________________________________ >>>>> mpls mailing list >>>>> mpls@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>=20 >>>=20 >>> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or = subject to >> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the >> use of the individual or entity to which it is addressed. If you are = not the >> intended recipient of this E-mail, you are hereby notified that any = dissemination, >> distribution, copying, or action taken in relation to the contents of = and >> attachments to this E-mail is strictly prohibited and may be = unlawful. If you >> have received this E-mail in error, please notify the sender = immediately and >> permanently delete the original and any copy of this E-mail and any = printout. >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 From curtis@occnc.com Wed Dec 19 16:10:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F2021F89D0 for ; Wed, 19 Dec 2012 16:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJMLT+9U4iYT for ; Wed, 19 Dec 2012 16:10:41 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D719B21F89D2 for ; Wed, 19 Dec 2012 16:10:40 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id qBK083C6010247; Wed, 19 Dec 2012 19:08:03 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201212200008.qBK083C6010247@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Sun, 16 Dec 2012 16:16:38 GMT." <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> Date: Wed, 19 Dec 2012 19:08:02 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 00:10:42 -0000 Hi Carlos, I see Andy and Kireeti already replied. In message <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > > Hi, Kireeti, > > This is a very nicely written document that covers important aspects. > > One early comment is that, in a way, this seems to actually be > multi-part document, including requirements, as well as compliance and > performance testing. One early question is whether it makes sense to > take each part separately (even in different WGs, with one as a BCP in > mpls in other in bmwg continuation of rfc5695). > > I also agree with Andy's comments about some PW specific pieces to this. > > Some more specific comments, hopefully these are clear and useful: The sections with questions to ask and testing are intentionally terse and serve only as outlines. This is to put a summary in one place. If BMWG wants to launch one or more documents to cover the testing in detailed benchmark specifications, they are more than welcome to do so. That is why we gave Al a heads up and why Al gave the BMWG mailing list a heads up. Of course, if there is consensus to break up this document into more than one, I'm OK with that approach. > 2.1. Forwarding Basics > > Should this section also include forwarding specifics about reserved > labels, and in particular RA. ... what Kireeti said. Yes we could reference the reserved label list and also if there is new work on "special purpose labels" we can reference that work too. So far RFC 3032 specifies RA and the NULL labels (RFC 3032 is obviously cited), the update to NULL is in RFC 4182 (cited), and GAL is defined in RFC 5586. We also cover EL and ELI (RFC 6790) in some detail. At this point that covers it for reserved labels. We can explicitly point out RA. We didn't cover OAM Alert Label #14 RFC3429 as use of ITU-T Y.1711 is strongly discouraged today. Y.1711 doesn't work at all for multipath and all service providers use multipath. When Kireeti's "special purpose labels" draft becomes a WG item we can point to "special purpose labels". I'm not sure what the WG concensus is on that. We still have 4-6 and 8-12 to assign, which should be plenty IMHO, but the extension mechanism can't hurt (too much). Its been pointed out in private email that some TP OAM functions require hardware support (DM, LM, and to a lesser extent CC/CV). The most challenging may be LM. Also PTP and NTP benefit from hardware support and the TICTOC work should be reflected here. > 2.3. MPLS Multipath Techniques > > ... > > The most common multipath techniques are ECMP applied at the IP > forwarding level, Ethernet LAG with inspection of the IP payload, and > multipath on links carrying both IP and MPLS, where the IP header is > inspected below the MPLS label stack. In most core networks, the > vast majority of traffic is MPLS encapsulated. > > In order to support an adequately even load distribution across > multiple links, IP addresses must be used. Common practice today is > to reinspect the IP addresses at each LSR and use the label stack and > IP addresses in a hash performed at each LSR. > > This description might appear oversimplified, especially in the > presence of BCP128. It was interesting that RFC 4928 is not cited, > when it contains a whole section on current ECMP practices at > http://tools.ietf.org/html/bcp128#section-2. Further, this section > describes how in addition to IP addresses, some cases use the label > stack (alone or in combination) as input into the hash for multipath. Both RFC4928 (BCP128) and RFC4385 are cited. RFC4928 section 2 is a little dated and represents the LCD in roughly 2004 or so when this draft was first introduced. In response to private email comments from Shane Anante the paragraph you pointed out as oversimplified had already been expanded. A lot more is now said about the so-called 5-tuple commonly used and the use of other fields. There is now a new section "2.3.5. Fields Used for Multipath" which we can put a forward reference to. > 2.3.1. Pseudowire Control Word > > Within the core of a network some form of multipath is almost certain > to be used. Multipath techniques deployed today are likely to be > looking beneath the label stack for an opportunity to hash on IP > addresses. > > A pseudowire encapsulated at a network edge must have a means to > prevent reordering within the core if the pseudowire will be crossing > a network core, or any part of a network topology where multipath is > used. > > Not supporting the ability to encapsulate a pseudowire with a control > word may lock a product out from consideration. A pseudowire > capability without control word support might be sufficient for > applications which are strictly both intra-metro and low bandwidth. > However a provider with other applications will very likely not > tolerate having equipment which can only support a subset of their > pseudowire needs. > > While I agree with this text, I wonder if it is attempting to set up a > new requirement. For example, although not 2119-capitalized, "A > pseudowire encapsulated at a network edge must have a means to prevent > reordering within the core". PWE3 has been discussing this topic, but > today's specs include PW Types for which a CW is optional. Similarly, > recommendations are already at this > http://tools.ietf.org/html/bcp128#section-3. What Andy said ... BTW- Andy has sent quite a lot of private email about PW which will be reflected in the next iteration. > 2.3.2. Pseudowire Flow Label > > ... > Any pseudowire which does not carry a flow label is in effect a > single microflow (in [RFC2475] terms). > > This is a bit of a corner-case nit, but for completeness: this is not > the case for IP L2 Transport PW without its optional CW (without flow > label) http://tools.ietf.org/html/rfc4447#section-4.1. People use L2TP? :-) OK - PW with MPLS PSN, but then again this is an MPLS document. I don't see what point you are trying to make. > 2.3.2. Pseudowire Flow Label > > 2.3.3. MPLS Entropy Label > > (see Section 2.3) > > This is an editorial nit, but for readability -- it confused me to see > a pointer to S2.3 within S2.3.x (as if there is an (apparent) reading > loop). I'll change the reference to "2.3.5. Fields in Multipath" which is new. BTW- that section starts by saying "Inspecting the IP payload provides the most entropy in provider networks. The practice of looking past the bottom of stack label for an IP payload is well accepted and documented in [RFC4928] and in other RFCs." just to be clear that the reason for inclusion in an MPLS document is that you need to look under the MPLS label stack for this purpose. > 3. Questions for Suppliers > > Q#10 Are reserved labels included in the label stack hash? They > MUST NOT be included. > > Could a citation be included for this MUST NOT? Or is this document > adding this requirement? I think there was a mention in RFC 6790, but > RFC4928/BCP128 says: Eliminated the double negative. It now says "Are reserved labels excluded from the label stack hash? They MUST be excluded [RFC6790]." RFC 6790 is cited elsewhere but is now cited here as well. > Any reserved label, no > matter where it is located in the stack, may be included in the > computation for load balancing. Modification of the label stack > between packets of a single flow could result in re-ordering that > flow. That is, were an explicit null or a router-alert label to be > > added to a packet, that packet could take a different path through > the network. > > 4. Forwarding Compliance and Performance Testing > > I wonder if this complete section should be progressed independently > in a separate document. If your "wondering" becomes the WG concensus, then I'm OK with that. My preference is to keep this brief summary of necessary testing with the requirements and expand on details of specific tests in BMWG. > Again, this is an useful well-written document, thanks! > > -- Carlos. Thanks for the comments, here in MPLS as well as in BMWG. The following changes have been edited into (my local copy) of the draft and are likely to make the next iteration (unless Kireeti objects). 1. Expanded a bit on reserved labels. Mention TP OAM (to be expanded on in later sections). Mention PTP and NTP. 2. Defer inclusion of "special purpose labels" for now. 3. The paragraph introducing multipath had already been expanded. 4. Andy already sent two rounds of extensive comments on PW. I have yet to edit in the second round. 5. Clarified PW without flow label to mean PW carried over MPLS without flow label (though I don't really agree that we need that clarification). 6. Fixed reference to 2.3 in 2.3.3. It now refers to the new section "2.3.5. Fields in Multipath". 7. Changed "MUST NOT be included" to "MUST exclude" in two places where reserved labels in hash are discussed. Referenced RFC6790 in both places. I may send out a 01 without Andy's latest rounds of comments, then following shortly after with an 02. This would be a better basis for discussion. I'll see what Kireeti thinks of sending this out vs waiting for all of the changes to get edited in and then sending out an 01. We still have off list discussions on other topics such as TP OAM with changes pending. Curtis > On Oct 8, 2012, at 8:30 PM, Kireeti Kompella > wrote: > > Hi Folks, > > I'd spoken on the issue of deep label stacks at the last IETF, and > there was interest from chip suppliers, vendors and service providers. > Curtis just submitted the draft; it goes beyond just deep label > stacks. There are suggestions in the draft on aspects of implementing > MPLS forwarding, as well as questions to ask regarding an > implementation, and things to test. > > Please read and comment to the list. > > If you (that includes MPLS WG chairs and ADs) could also formulate > your thoughts on what type of doc (Info, BCP, PS) this should be, that > would be very helpful in moving this discussion forward. > > Thanks, > Kireeti. From xuxiaohu@huawei.com Thu Dec 20 02:15:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53C721F8502 for ; Thu, 20 Dec 2012 02:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=-0.973, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrwCaXzJ6hjP for ; Thu, 20 Dec 2012 02:15:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 124C621F8CCE for ; Thu, 20 Dec 2012 02:15:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOA06729; Thu, 20 Dec 2012 10:15:04 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:14:34 +0000 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 10:14:38 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 18:13:59 +0800 From: Xuxiaohu To: Shane Amante Thread-Topic: Discussion on how to transport MPLS over UDP tunnels Thread-Index: AQHN3pq6dxmEvHStBkqLkCyKFyfQFw== Date: Thu, 20 Dec 2012 10:13:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-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.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] Discussion on how to transport MPLS over UDP tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:15:09 -0000 SGkgU2hhbmUsDQoNClRoYW5rcyBmb3IgeW91ciBmdXJ0aGVyIGNvbW1lbnRzIGFuZCBwbGVhc2Ug c2VlIG15IHJlc3BvbnNlIGlubGluZS4NCg0KTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxp bmUgYWNjb3JkaW5nIHRvIExvYSdzIHN1Z2dlc3Rpb24uDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0K PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMjI6MzgNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCz rcvNOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFmdC14dS1tcGxzLWluLXVkcEB0 b29scy5pZXRmLm9yZzsNCj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmcNCj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8g bWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQNCj4gDQo+IFhpYW9odSwNCj4gDQo+IE9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gLS0tLS3Tyrz+1K28/i0tLS0t DQo+ID4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0 XQ0KPiA+PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMTE6NTgNCj4gPj4gytW8/sjLOiBSb2dl cnMsIEpvc2gNCj4gPj4gs63LzTogU2hhaHJhbSBEYXZhcmk7IFh1eGlhb2h1OyBkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsNCj4gPj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3 ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcA0KPiBhbg0KPiA+PiBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4NCj4gPj4NCj4gPj4gT24gRGVjIDE4LCAy MDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+ DQo+ID4+IHdyb3RlOg0KPiA+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8g bm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzIHNvbHV0aW9uDQo+ID4+PiBhZGRyZXNzZXMgaW4gcHJh Y3RpY2UgYW55IGxvbmdlci4NCj4gPj4NCj4gPj4gKzEuICBQbGVhc2UgZG8gbm90IGRlZmluZSB5 ZXQgYW5vdGhlciBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbi4gIFRoZQ0KPiBJRVRGDQo+ID4+ IGFscmVhZHkgc3RhbmRhcmRpemVkIE1QTFMgb3ZlciBHUkUuICBUaGUgSUVURiBoYXMgYWxzbyBz dGFuZGFyZGl6ZWQNCj4gTVBMUw0KPiA+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBz ZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4gPj4gbGFyZ2Ugb3Bl cmF0b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBvZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mIEwz VlBOIG92ZXINCj4gYW4NCj4gPj4gSVAtb25seSBuZXR3b3JrLg0KPiA+DQo+ID4gSGkgU2hhbmUs DQo+ID4NCj4gPiBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBs b3ltZW50cyBvZiBNUExTIG92ZXIgSVAgaW4gYXQNCj4gbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9w ZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkgdmFsdWFibGUgdG8gdGhvc2UN Cj4gcGVvcGxlIHdobyBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGljYXRpb24gb2YgTVBM UyBvdmVyIElQIGluIHRvZGF5J3MgU1ANCj4gbmV0d29ya3MuDQo+ID4NCj4gPj4gU2VlOiBSRkMn cyA0NDU0LCA0NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYzDQo+ID4+IFtOT1RF OiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2 DQo+IHRpbWVmcmFtZSFdDQo+ID4+ICAgICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0 ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMgbWF5IGJlDQo+ID4+IGNhcnJpZWQgb3ZlciBM MlRQdjMNCj4gPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFz dCBvbmUgdmVuZG9yIGhhcw0KPiBpbXBsZW1lbnRlZA0KPiA+PiBJUFZQTidzIG92ZXIgTDJUUHYz Og0KPiA+PiBodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJl L2d1aWRlL2NzZ2wzdnBuLmh0bWwNCj4gPg0KPiA+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmluZyB0 aGUgYWJvdmUgaW5mb3JtYXRpb24uIEFzIG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0DQo+IEFORCBv dGhlciBkcmFmdHMsIHRoZSBtZWNoYW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9u IG9uIHRoZSBTZXNzaW9uDQo+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBL ZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgYXMgZGVmaW5lZCBpbg0KPiBbUkZDIDU2NDBdIGlz IG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuDQo+ IA0KPiBGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nlc3MsIGluIHRoZSByZWxhdGl2ZWx5IHJlY2VudCBw YXN0LCBpbiByZXF1ZXN0aW5nIGEgY29yZQ0KPiByb3V0ZXIgdmVuZG9yIHRvIHN1cHBvcnQgY2hh bmdlcyB0byB0aGUgaW5wdXQta2V5cyB1c2VkIGluIGhhc2ggY2FsY3VsYXRpb25zIGluDQo+IF9l eGlzdGluZ18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2ZWx5KSB0aHJvdWdo b3V0IG15IG5ldHdvcmsuDQo+IEZ1cnRoZXIsIEkgc3VzcGVjdCB0aGF0IG1vc3QgbGFyZ2UgbmV0 d29yayBvcGVyYXRvcnMgYXJlIHNhdnZ5IGZvbGtzIGFuZA0KPiB1bmRlcnN0YW5kIHRoZSBpbnRl cm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuICBBcyBhIHJlc3VsdCwg dGhvc2UNCj4gc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3QgdGVjaG5pY2Fs bHkgcG9zc2libGUgaW4gdGhpcyByZWdhcmQuDQo+IFRodXMsIGl0IG1heSBiZSBhIHF1ZXN0aW9u IG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhlaXIgSFcNCj4gc3VwcGxpZXIo cykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0byBhY2hp ZXZlIHRoZWlyDQo+IGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBub3Qg ZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxvdy4NCg0KQ291bGQgeW91IHBsZWFzZSBicmll Zmx5IGV4cGxhaW4gaG93IHRvIG1ha2UgdGhlIGFib3ZlIGNoYW5nZSBpbiBFWElTVElORyBoYXJk d2FyZSBvZiBhbHJlYWR5IGRlcGxveWVkIGNvcmUgcm91dGVycz8NCg0KPiA+IEluIGNvbnRyYXN0 LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mIGJhbGFu Y2luZyBJUA0KPiB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1 cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUNCj4gTVBMUy1pbi1VRFAgZW5jYXBzdWxh dGlvbiwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkgb2YN Cj4gbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJl cXVpcmluZyBhbnkgY2hhbmdlIHRvDQo+IHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRp b24gb2YgdGhpcyBkcmFmdC4NCj4gDQo+IElmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBu b3QgZW5jYXBzdWxhdGUgdGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoDQo+IHVzZXMg VURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQoNCklmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0 bHksIHlvdSBwcmVmZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLVVEUCBpbnN0ZWFkIG9mIE1Q TFMtaW4tVURQLCByaWdodD8NCg0KPiBJTUhPLCBhIGJldHRlciBwcm9wb3NhbCBtYXkgYmUgdG8g Y29uc2lkZXIgYSBbbWlub3JdICg/KSBjaGFuZ2UgdG8gUkZDIDM5MzEsDQo+IHdoaWNoIHdvdWxk IGFsbG93IHRoZSBjb25uZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFja2V0cyAobm90IGNvbnRyb2wg cGFja2V0cykNCj4gdG8gdXNlIGEgdmFyeWluZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291 cmNlIElQIGFkZHJlc3NlcyksIGJhc2VkIG9uIGEgaGFzaA0KPiBjYWxjdWxhdGlvbiwgdG8gYWNo aWV2ZSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgb3ZlciBleGlzdGluZyBlcXVpcG1lbnQgaW4gYW4N Cj4gSVAtb25seSBjb3JlLiAgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVudGF0aW9ucyB3b3VsZCBi ZSBiZXR0ZXIgb2ZmIGp1c3QgdXNpbmcNCj4gdGhlICJTZXNzaW9uIElEIiAoYW5kICJDb29raWUi KSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlwbGV4b3IgdG8gYXNzb2NpYXRlDQo+IGluY29taW5nIHBh Y2tldHMgd2l0aCB0aGUgYXNzb2NpYXRlZCBMMlRQIENvbnRyb2wgQ2hhbm5lbC4gIEluIGZhY3Qs IGl0J3Mgbm90DQo+IGNsZWFyIHRvIG1lIHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG1h eSAvYWxyZWFkeS8gZG8gdGhpcywgbWFraW5nIGFueQ0KPiAiY2hlY2siIG9uIHRoZSBpbmNvbWlu ZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtDQo+IGltcGxlbWVu dGF0aW9ucy4NCj4gDQo+IFRoZSBiZWF1dHkgb2YgdGhlIGFib3ZlIGFwcHJvYWNoIGlzOg0KPiAx KSBJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIGFib3ZlIGlzIG1vc3QgbGlrZWx5IGEgY2hhbmdlIHRo YXQgaXMgbGltaXRlZCB0byB0aGUNCj4gImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBvZiBl eGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KPiBIZWNrLCBpdCBtYXkg ZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2Mw0KPiBpbXBs ZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQg b24gdGhhdCkuDQoNCklNSE8sIG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBM Uy1pbi1VRFAsICB0aGUgaGFyZHdhcmUgb2YgUEUgcm91dGVycyBuZWVkcyB0byBiZSB1cGdyYWRl ZCwgZS5nLiwgaW5ncmVzcyBQRSByb3V0ZXJzIG5lZWQgdG8gZmlsbCBpbiBhbiBlbnRyb3B5IHZh bHVlIGluIHRoZSBzb3VyY2UgcG9ydCBmaWVsZCBvZiBVRFAgaGVhZGVycy4NCg0KPiAyKSBUaGVy ZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNz aW9uIElEIiBhbmQNCj4gIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJU UHYzIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlDQo+IGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1 b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gLS0tc25pcC0tLQ0KPiAgICBM MlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAzMi1i aXQgU2Vzc2lvbg0KPiAgICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVz ZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KPiAgICAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xKSwg cHJvdmlkZXMgYW4gYWRkaXRpb25hbCBjaGVjayB0byBlbnN1cmUNCj4gICAgdGhhdCBhbiBhcnJp dmluZyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yIHRoZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+ICAg IFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4 dHJhIGd1YXJhbnRlZQ0KPiAgICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVyZm9y bWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZQ0KPiAgICBTZXNzaW9uIElEIGl0c2VsZiB3YXMgbm90 IGNvcnJ1cHRlZCBpbiB0cmFuc2l0Lg0KPiAtLS1zbmlwLS0tDQo+IC4uLiBpbiByZWdhcmQgdG8g dGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBrbm93IHRoZSBTZWN1cml0eSBBcmVhIGZvbGtzIGhhdmUs IGluIHRoZQ0KPiBwYXN0LCBoYWQgL3N1YnN0YW50aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1 bGF0aW9uIG9mIE1QTFMgb3ZlciBJUCB0cmFuc3BvcnQuDQo+IEluIGZhY3QsIHRoaXMgaXMgd2h5 IHlvdSBzZWUgdGV4dCBpbiBTZWN0aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YgUkZDIDQ2NjUuDQo+ IChUaGVyZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVz ZSBNUExTIGZvciB0cmFuc3BvcnQpLg0KPiBXaGlsZSBJJ20gbm90IHN1cmUgdGhhdCBTZWN1cml0 eSBBcmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0byBkYWlseSB0cmFmZmljIG9uDQo+IHRo ZSBNUExTIFdHIG1haWxpbmcgbGlzdCwgSSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJu IHdpbGwgYXJpc2UgaWYvd2hlbiB0aGlzDQo+IGRyYWZ0IGdvZXMgdG8gdGhlIElFU0cgLi4uDQoN CklmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVy ZW5jZSBvZiBNUExTLWluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBoYXMgYW4gYWRkZWQgc2Vj dXJpdHkgZmVhdHVyZS4gSWYgdGhhdCBpcyBzbyBjb25jZXJuZWQsIGNhbiB5b3UgZXhwbGFpbiB3 aHkgTVBMUy1pbi1HUkUgaXMgZmFyIG1vcmUgcG9wdWxhciB0aGFuIE1QTFMtaW4tTDJUUCBpbiBw cmFjdGljZT8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gMykgRmluYWxseSwgdGhpcyBh cHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1wbGVtZW50IEwyVFAs IGZvcg0KPiB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50 aXJlIGluZHVzdHJ5IHRvIHN1cHBvcnQNCj4gTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVp ciBwcm9kdWN0IGxpbmVzLg0KPiANCj4gLXNoYW5lDQo+IA0KPiANCj4gPg0KPiA+IEJlc3QgcmVn YXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBm b3IgTVBMUyBvdmVyIElQLCB0aGVuIGNsZWFybHkgaXQgd291bGQgaGF2ZQ0KPiBiZWVuDQo+ID4+ IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhl ciBNUExTIG92ZXINCj4gR1JFIG9yDQo+ID4+IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUgdGhl cmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSSB3b3VsZCBub3RlDQo+IHRoYXQNCj4gPj4g dGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBhbiBvdXQgd2FzIHRoZXJlIGFy ZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4gPj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25lIGdldHMg ZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+ID4+IGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5n IHdpdGhpbiB0aGUgZGF0YSBwbGFuZSwgbmFtZWx5Og0KPiA+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0 ZQ0KPiA+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPiA+PiAuLi4gdG8gbmFtZSwgYnV0 IGEgZmV3LiAgVGhvc2UgaGF2ZSB0ZW5kZWQgdG8gYmUgcXVpdGUgY29tcGVsbGluZw0KPiBhcmd1 bWVudHMNCj4gPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fw c3VsYXRpb24vc3dpdGNoaW5nLg0KPiA+Pg0KPiA+PiAtc2hhbmUNCj4gPj4NCj4gPj4NCj4gPj4+ IC1Kb3NoDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IE9uIDEyLzE4LzEyIDEyOjMxIEFNLCAiU2hhaHJh bSBEYXZhcmkiIDxkYXZhcmlAYnJvYWRjb20uY29tPg0KPiB3cm90ZToNCj4gPj4+DQo+ID4+Pj4g Rm9yIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0 aGVyZSBpcyBubyBuZWVkDQo+ID4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4gPj4+Pg0KPiA+Pj4+IFJl Z2FyZHMsDQo+ID4+Pj4gU2hhaHJhbQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiBEZWMgMTcs IDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+IHdy b3RlOg0KPiA+Pj4+DQo+ID4+Pj4+IFNoYWhyYW0sDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMgZHJh ZnQgaXMgT05MWSBpbnRlbmRlZCB0byBwcm92aWRlIGEgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRp b24NCj4gPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJp bGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4gPj4+Pj4gb3BlcmF0b3JzIHdobyBoYXBwZW4gdG8gcmVx dWlyZSB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+ID4+Pj4+IGFjcm9z cyBJUCBuZXR3b3Jrcy4gSSBiZWxpZXZlIE1QTFMtYmFzZWQgVlBOIG92ZXIgSVAsIE5WR1JFIGFu ZA0KPiBWWExBTg0KPiA+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVz ZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPiA+Pj4+PiBpdCdzIG1lYW5pbmds ZXNzIG9mIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQDQo+ ID4+Pj4+IG5ldHdvcmtzIGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVk IHRvIE1QTFMgb3ZlciBJUA0KPiA+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUg bW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5DQo+IHNvLg0KPiA+Pj4+Pg0KPiA+ Pj4+PiBCeSB0aGUgd2F5LCBpdCBzZWVtcyB0aGlzDQo+ID4+Pj4+IChodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+ Pj4+IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBzdWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZv bGxvd2luZyBhcmd1bWVudA0KPiA+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNl ZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhIGNlbnRlcnMpLiBJDQo+ID4+Pj4+IGhhZCB0aG91 Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkg c2lsZW50DQo+ID4+Pj4+IHRpbGwgbm93Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTaWdoLCBJIGRpZG4n dCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+DQo+ID4+Pj4+IFhp YW9odQ0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+PiC3orz+ yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g tPqx7Q0KPiA+PiBTLg0KPiA+Pj4+Pj4gRGF2YXJpDQo+ID4+Pj4+PiC3osvNyrG85DogMjAxMsTq MTLUwjE1yNUgMTM6MzQNCj4gPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+Pj4+Pj4g s63LzTogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7 DQo+ID4+Pj4+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+Pj4+Pj4g1vfM4jogUmU6 IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZQ0KPiA+Pj4+Pj4g ZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPj4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1 bWVudA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNl IGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+ID4+Pj4+PiBtb2Rlcm4gbWV0cm8N Cj4gPj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQgaXRzIG9ubHkg cHJhY3RpY2FsIGFwcGxpY2F0aW9uDQo+ID4+Pj4+PiBpbiBpbiBkYXRhDQo+ID4+Pj4+PiBjZW50 ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVyIHNvbHV0aW9ucyBzdWNoIGFz IE5WR1JFDQo+IGFuZA0KPiA+Pj4+Pj4gVlhMQU4uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSXQgc2Vl bXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBieXBhc3MgdGhlIE5WTzMgc29sdXRpb24gc2Vs ZWN0aW9uDQo+ID4+Pj4+PiBwcm9jZXNzDQo+ID4+Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0 IGluIE1QTFMgV0cuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+IFNoYWhy YW0NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAx IEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhpcyBpcyB0byBzdGFydCBh ICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+Pj4+Pj4+IGRyYWZ0LXh1LW1wbHMtaW4t dWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4gPj4+Pj4+PiBEdWUg dG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRoIG9u ZSB3ZWVrLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAo c3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMNCj4gd29ya2luZw0KPiA+Pj4+Pj4+IGdy b3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuIHRlY2hu aWNhbA0KPiA+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwg ZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPiA+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaG91 bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0N Cj4gPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24g dGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBu b3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5DQo+ID4+ Pj4+Pj4gZGlzY2xvc2VkLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVy c2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFINCj4gPj4+Pj4+ PiBwb2xsKQ0KPiA+Pj4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2Yg dGhlIGF1dGhvcnMuIE1hcnNoYWxsIGhhcw0KPiA+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50 ZXJhY3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0NCj4gPj4+ Pj4+PiBvZiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJz IGhhcyB0cmllZCB0bw0KPiA+Pj4+Pj4+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMs IHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbiB0aGUgSVBSDQo+ID4+Pj4+Pj4gcG9sbC4NCj4gPj4+ Pj4+PiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBGcm9tIHZlcnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxs IGFzIGENCj4gPj4+Pj4+PiBjby1hdXRob3IuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiAvTG9hDQo+ ID4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+ID4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBl bWFpbDoNCj4gPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+ID4+Pj4+Pj4gU3Ig U3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4+ Pj4+Pj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEw IDcxNyA1MiAxMw0KPiA+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+PiBtcGxzQGlldGYu b3JnDQo+ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRp bWUgV2FybmVyIENhYmxlDQo+ID4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4gPj4gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29s ZWx5IGZvcg0KPiB0aGUNCj4gPj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZQ0KPiA+PiBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 DQo+IGRpc3NlbWluYXRpb24sDQo+ID4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQNCj4gPj4gYXR0YWNobWVu dHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UNCj4gPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPiA+PiBwZXJtYW5lbnRseSBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHBy aW50b3V0Lg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+PiBtcGxzQGlldGYub3JnDQo+ID4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4NCj4gPg0K PiANCg0K From lucy.yong@huawei.com Thu Dec 20 07:39:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6249321F891C for ; Thu, 20 Dec 2012 07:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=-2.529, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYNFSvQVEkSJ for ; Thu, 20 Dec 2012 07:38:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2541C21F8910 for ; Thu, 20 Dec 2012 07:38:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR48020; Thu, 20 Dec 2012 15:38:56 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 15:38:42 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 15:38:55 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 07:38:50 -0800 From: Lucy yong To: Shane Amante Thread-Topic: MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9ng== Date: Thu, 20 Dec 2012 15:38:49 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.202] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:39:01 -0000 SGkgU2hhbmUsDQoNCkkgdW5kZXJzdGFuZCBvcGVyYXRvciBjb25jZXJuIG9uIGEgbmV3IGVuY2Fw c3VsYXRpb24gdG8gYW4gZXhpc3RpbmcgbmV0d29yay4gDQoNCkhvd2V2ZXIsIE1QTFMtaW4tVURQ IGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9NUExTIG5ldHdvcmsgYXQg YWxsLg0KTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVyIHRvIGJlIGRl Y291cGxlZCBmcm9tIE1QTFMgc2VydmVyIGxheWVyIGFuZCB1c2UgTVBMUyBjbGllbnQgbGF5ZXIg YXMgb3ZlcmxheSBuZXR3b3JrIGFuZCBhbiBJR1AgYXMgYSB1bmRlcmx5aW5nIG5ldHdvcmsgZm9y IHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBmb3IgREMuIFlvdSBtYXkgYXJndWUgd2h5 IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBMUyBsYXllciBvdmVyIGFuIElHUCB1bmRl cmxpbmcgbmV0d29yay4gV2UgaGF2ZSBwb2ludGVkIG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJy ZW50IHJvdXRlcnMgaW4gREMgYmFyZWx5IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5n IGFuZCBNUExTLWluLUdSRSBhcmUgYmFyZWx5IHVzZWQgaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0 IG9mIHJvdXRlcnMgaW4gREMgcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkIGJhbGFuY2luZyBu b3cuICANCg0KRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQIGVuY2Fw c3VsYXRpb24gaGFzIGFkdmFudGFnZSBvdmVyIEdSRSBlbmNhcHN1bGF0aW9uIHRvby4gSW4gVURQ IGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZSBoZWFkZXIgZGVjb3VwbGVzIHRoZSBvdmVybGF5IGFu ZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRlciBoZWFkZXIgYW5kIG92ZXJs YXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFkZXIsIHdoaWNoIHVuZGVybHlpbmcg bmV0d29yayB1c2VzIG9ubHkuIEhvd2V2ZXIsIEdSRSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9y IHRoZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRy b3B5LiBGb3IgbG9hZCBiYWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdv cmsgdXNlcyBHUkUgaGVhZGVyIHRvby4gSW4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5IGFu ZCB1bmRlcmx5aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5jZSBpdCBoYXMgbm90IHVzZWQgYSBs b3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaCBjb3Vw bGluZy4NCg0KQXMgdGhlIGluZHVzdHJ5IG1vdmVzIHRvd2FyZCBuZXR3b3JrIHZpcnR1YWxpemF0 aW9uIG92ZXJsYXkgYW5kIGRlY291cGxlcyBvdmVybGF5IG5ldHdvcmtzIGZyb20gdGhlIHVuZGVy bHlpbmcgbmV0d29yay4gQSBjbGVhciBzZXBhcmF0aW9uIG9mIG92ZXJsYXkgaGVhZGVyIGFuZCB1 bmRlcmx5aW5nIGhlYWRlciBpcyBhICJNVVNUIiBpbiBteSBvcGluaW9uLiBJZiB3ZSBjb3VudCBH UkUgYXMgdGhlIG92ZXJsYXkgaGVhZGVyLCB0aGVuIGZvciBJUHY0IHVuZGVybHlpbmcgbmV0d29y aywgdGhlcmUgaXMgbm8gZmllbGQgZm9yIHRoZSBmbG93IGVudHJvcHkuIFRoaXMgaXMgdGhlIHJl YXNvbiB3ZSBwcm9wb3NlIHRoZSBVRFAgZW5jYXBzdWxhdGlvbjogZm9yIGFuIElHUCBiYXNlZCB1 bmRlcmx5aW5nIG5ldHdvcmsuIEluIGZhY3QsIGl0IGNhbiBzdXBwb3J0IGFueSBvdmVybGF5IG5l dHdvcmsgYmVzaWRlIE1QTFMgY2xpZW50IGxheWVyIChlLmcuIFZYTEFOLCBMMlRQLWluLVVEUCwg ZXRjKS4gDQoNCllvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVEUCBpbnN0ZWFk LiBZZXMsIE1QTFMtaW4tTDJUUC1pbi1VRFAgc2NoZW1hIGFsc28gcHJvdmlkZXMgYSBvdmVybGF5 IChMMlRQKSBhbmQgdW5kZXJseWluZyAoSVApIG5ldHdvcmsgZGVjb3VwbGluZy4gTDJUUCBwcm90 b2NvbCAocmZjMzkzMSkgcHJvdmlkZXMgZ29vZCBzZWN1cml0eSBtZWNoYW5pc20gYW5kIGhhcyB0 aGUgZW1iZWRkZWQgY29udHJvbCBmdW5jdGlvbiB0b28uIFRoZXJlZm9yZSwgc29tZW9uZSBjYW4g dXNlIGl0IGZvciBNUExTIGNsaWVudCBsYXllciBvdmVyIEludGVybmV0LiBUbyBoYXZlIE1QTFMg Y2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybGluZyBuZXR3b3JrLCBJTU86IE1QTFMtaW4t TDJUUC1pbi1VRFAgaXMgYSBvdmVya2lsbCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZCBh IHNjaGVtYSB0byBzdXBwb3J0IElHUCB1bmRlcmx5aW5nIHRyYW5zcG9ydCB3aXRob3V0IHRvdWNo aW5nIGEgb3ZlcmxheSBoZWFkZXIuIFVEUCBlbmNhcHN1bGF0aW9uIGlzIHRoZSBiZXN0IGNob2lj ZSB0byBhY2NvbXBsaXNoIHRoYXQgYW5kIG1pbmltaXplIHRoZSBjaGFuZ2VzIG9uIGV4aXN0aW5n IHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVycywgbm8gY2hhbmdlIG9uIHRyYW5z aXQgcm91dGVycy4NCg0KUmVnYXJkcywNCkx1Y3kgDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0N Cj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDQ6MTQgQU0NCj4gVG86IFNoYW5l IEFtYW50ZQ0KPiBDYzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IERpc2N1c3Npb24gb24gaG93IHRvIHRyYW5zcG9ydCBN UExTIG92ZXIgVURQIHR1bm5lbHMNCj4gDQo+IEhpIFNoYW5lLA0KPiANCj4gVGhhbmtzIGZvciB5 b3VyIGZ1cnRoZXIgY29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0K PiANCj4gTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdz IHN1Z2dlc3Rpb24uDQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ILeivP7IyzogU2hh bmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0KPiA+ILeiy83KsbzkOiAy MDEyxOoxMtTCMTnI1SAyMjozOA0KPiA+IMrVvP7IyzogWHV4aWFvaHUNCj4gPiCzrcvNOiBSb2dl cnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFmdC14dS1tcGxzLWluLQ0KPiB1ZHBAdG9vbHMu aWV0Zi5vcmc7DQo+ID4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcN Cj4gPiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBt YWtlIGRyYWZ0LXh1LQ0KPiBtcGxzLWluLXVkcCBhbg0KPiA+IG1wbHMgd29ya2luZyBncm91cCBk b2N1bWVudA0KPiA+DQo+ID4gWGlhb2h1LA0KPiA+DQo+ID4gT24gRGVjIDE4LCAyMDEyLCBhdCAx MTo1MCBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IC0tLS0t 08q8/tStvP4tLS0tLQ0KPiA+ID4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVA Y2FzdGxlcG9pbnQubmV0XQ0KPiA+ID4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0K PiA+ID4+IMrVvP7IyzogUm9nZXJzLCBKb3NoDQo+ID4gPj4gs63LzTogU2hhaHJhbSBEYXZhcmk7 IFh1eGlhb2h1OyBkcmFmdC14dS1tcGxzLWluLQ0KPiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4g Pj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+PiDW98zi OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0 LXh1LQ0KPiBtcGxzLWluLXVkcA0KPiA+IGFuDQo+ID4gPj4gbXBscyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IE9uIERlYyAxOCwgMjAxMiwgYXQgODo1MCBB TSwgIlJvZ2VycywgSm9zaCINCj4gPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KPiA+ID4+IHdy b3RlOg0KPiA+ID4+PiBJIHNoYXJlIHlvdXIgU1AgcGVyc3BlY3RpdmUsIGFuZCBkbyBub3Qgc2Vl IHRoZSBwcm9ibGVtIHRoaXMNCj4gc29sdXRpb24NCj4gPiA+Pj4gYWRkcmVzc2VzIGluIHByYWN0 aWNlIGFueSBsb25nZXIuDQo+ID4gPj4NCj4gPiA+PiArMS4gIFBsZWFzZSBkbyBub3QgZGVmaW5l IHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0aW9uLg0KPiBUaGUNCj4gPiBJRVRG DQo+ID4gPj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhh cyBhbHNvDQo+IHN0YW5kYXJkaXplZA0KPiA+IE1QTFMNCj4gPiA+PiBvdmVyIEwyVFB2My9VRFAv SVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBvbmUsDQo+IHZl cnkNCj4gPiA+PiBsYXJnZSBvcGVyYXRvciBuZXR3b3JrIHRoYXQgSSdtIGF3YXJlIG9mIHRvIHN1 cHBvcnQgY2FycmlhZ2Ugb2YNCj4gTDNWUE4gb3Zlcg0KPiA+IGFuDQo+ID4gPj4gSVAtb25seSBu ZXR3b3JrLg0KPiA+ID4NCj4gPiA+IEhpIFNoYW5lLA0KPiA+ID4NCj4gPiA+IFRoYW5rIHlvdSBm b3IgdGVsbGluZyB1cyB0aGVyZSBhcmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3Zlcg0K PiBJUCBpbiBhdA0KPiA+IGxlYXN0IG9uZSwgdmVyeSBsYXJnZSBvcGVyYXRvciBuZXR3b3JrLiBU aGlzIGZhY3QgbXVzdCBiZSB2ZXJ5DQo+IHZhbHVhYmxlIHRvIHRob3NlDQo+ID4gcGVvcGxlIHdo byBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGlu DQo+IHRvZGF5J3MgU1ANCj4gPiBuZXR3b3Jrcy4NCj4gPiA+DQo+ID4gPj4gU2VlOiBSRkMncyA0 NDU0LCA0NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYzDQo+ID4gPj4gW05PVEU6 IHRoZSBkYXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJhY2sgaW4gdGhlIDIwMDYN Cj4gPiB0aW1lZnJhbWUhXQ0KPiA+ID4+ICAgICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJl bGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4gbWF5IGJlDQo+ID4gPj4gY2Fycmll ZCBvdmVyIEwyVFB2Mw0KPiA+ID4+ICAgICBBbmQsIGhlcmUncyBldmlkZW5jZSBzaG93aW5nIHRo YXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMNCj4gPiBpbXBsZW1lbnRlZA0KPiA+ID4+IElQVlBO J3Mgb3ZlciBMMlRQdjM6DQo+ID4gPj4NCj4gaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9j cy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQo+ID4gPg0KPiA+ID4gVGhh bmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlvbmVk IGluDQo+IHRoaXMgZHJhZnQNCj4gPiBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNtIG9m IHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUNCj4gU2Vzc2lvbg0KPiA+IElEIGZp ZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFk ZXIgYXMNCj4gZGVmaW5lZCBpbg0KPiA+IFtSRkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0 ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNvIGZhci4NCj4gPg0KPiA+IEZXSVcsIEkgaGF2 ZSBoYWQgc3VjY2VzcywgaW4gdGhlIHJlbGF0aXZlbHkgcmVjZW50IHBhc3QsIGluDQo+IHJlcXVl c3RpbmcgYSBjb3JlDQo+ID4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhl IGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+IGNhbGN1bGF0aW9ucyBpbg0KPiA+IF9leGlzdGlu Z18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15 DQo+IG5ldHdvcmsuDQo+ID4gRnVydGhlciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3 b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3MNCj4gYW5kDQo+ID4gdW5kZXJzdGFuZCB0aGUg aW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPiBy ZXN1bHQsIHRob3NlDQo+ID4gc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3Qg dGVjaG5pY2FsbHkgcG9zc2libGUgaW4gdGhpcw0KPiByZWdhcmQuDQo+ID4gVGh1cywgaXQgbWF5 IGJlIGEgcXVlc3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVpcg0K PiBIVw0KPiA+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlhdGUgY2hhbmdlcyBpbiB0aGVp ciBlcXVpcG1lbnQgdG8gYWNoaWV2ZQ0KPiB0aGVpcg0KPiA+IGJ1c2luZXNzIGdvYWxzLiAgOi0p ICBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZQ0KPiBiZWxv dy4NCj4gDQo+IENvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBleHBsYWluIGhvdyB0byBtYWtlIHRo ZSBhYm92ZSBjaGFuZ2UgaW4NCj4gRVhJU1RJTkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBkZXBsb3ll ZCBjb3JlIHJvdXRlcnM/DQo+IA0KPiA+ID4gSW4gY29udHJhc3QsIG1vc3QgZXhpc3RpbmcgY29y ZSByb3V0ZXJzIGFyZSBhbHJlYWR5IGNhcGFibGUgb2YNCj4gYmFsYW5jaW5nIElQDQo+ID4gdHJh ZmZpYyBmbG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFj a2V0cy4gQnkNCj4gdXNpbmcgdGhlDQo+ID4gTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiwgdGhl IGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nDQo+IGNhcGFiaWxpdHkgb2YNCj4gPiBt b3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJhZ2VkIHdpdGhvdXQgcmVxdWly aW5nIGFueQ0KPiBjaGFuZ2UgdG8NCj4gPiB0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBtb3RpdmF0 aW9uIG9mIHRoaXMgZHJhZnQuDQo+ID4NCj4gPiBJZiB0aGlzIGlzIGEgY29uY2VybiwgdGhlbiB3 aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFmZmljIGluDQo+IE1QTFMvTDJUUHYzLCB3aGljaA0K PiA+IHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+IA0KPiBJZiBJIHVuZGVyc3Rh bmQgaXQgY29ycmVjdGx5LCB5b3UgcHJlZmVyIHRvIHVzZSBNUExTLWluLUwyVFB2My1pbi1VRFAN Cj4gaW5zdGVhZCBvZiBNUExTLWluLVVEUCwgcmlnaHQ/DQo+IA0KPiA+IElNSE8sIGEgYmV0dGVy IHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0KPiBS RkMgMzkzMSwNCj4gPiB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1c2VkIGZvciBk YXRhIHBhY2tldHMgKG5vdCBjb250cm9sDQo+IHBhY2tldHMpDQo+ID4gdG8gdXNlIGEgdmFyeWlu ZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksIGJhc2VkDQo+ IG9uIGEgaGFzaA0KPiA+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2FkLWJhbGFu Y2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudA0KPiBpbiBhbg0KPiA+IElQLW9ubHkgY29yZS4g IEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYmV0dGVyIG9mZg0KPiBq dXN0IHVzaW5nDQo+ID4gdGhlICJTZXNzaW9uIElEIiAoYW5kICJDb29raWUiKSBmaWVsZHMgYXMg dGhlIGRlbXVsdGlwbGV4b3IgdG8NCj4gYXNzb2NpYXRlDQo+ID4gaW5jb21pbmcgcGFja2V0cyB3 aXRoIHRoZSBhc3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwNCj4gaXQn cyBub3QNCj4gPiBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkg L2FscmVhZHkvIGRvIHRoaXMsDQo+IG1ha2luZyBhbnkNCj4gPiAiY2hlY2siIG9uIHRoZSBpbmNv bWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtDQo+ID4gaW1w bGVtZW50YXRpb25zLg0KPiA+DQo+ID4gVGhlIGJlYXV0eSBvZiB0aGUgYWJvdmUgYXBwcm9hY2gg aXM6DQo+ID4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBh IGNoYW5nZSB0aGF0IGlzDQo+IGxpbWl0ZWQgdG8gdGhlDQo+ID4gImNvbnRyb2wgY2hhbm5lbCIg KHNvZnR3YXJlKSBvZiBleGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gaW1wbGVtZW50YXRpb25z Lg0KPiA+IEhlY2ssIGl0IG1heSBldmVuIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhp c3RpbmcgTDJUUHYzDQo+ID4gaW1wbGVtZW50YXRpb25zLiAgKEwyVFB2MyBpbXBsZW1lbnRvcnMg d291bGQgbmVlZCB0byBjb21tZW50IG9uIHRoYXQpLg0KPiANCj4gSU1ITywgbm8gbWF0dGVyIE1Q TFMtaW4tTDJUUHYzLWluLVVEUCBvciBNUExTLWluLVVEUCwgIHRoZSBoYXJkd2FyZSBvZg0KPiBQ RSByb3V0ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdyZXNzIFBFIHJvdXRlcnMg bmVlZCB0byBmaWxsDQo+IGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZp ZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiANCj4gPiAyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFk ZGVkIHNlY3VyaXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uDQo+IElEIiBhbmQNCj4gPiAi Q29va2llIiBmaWVsZHMgdG8gZW5zdXJlIHRoZSByZWNlaXZlZCBMMlRQdjMgcGFja2V0IGlzIGlu dGVuZGVkIGZvcg0KPiB0aGUNCj4gPiBpZGVudGlmaWVkIHNlc3Npb24uICBRdW90aW5nIGZyb20g U2VjdGlvbiA4LjIgb2YgUkZDIDM5MzE6DQo+ID4gLS0tc25pcC0tLQ0KPiA+ICAgIEwyVFB2MyBw cm92aWRlcyB0cmFmZmljIHNlcGFyYXRpb24gZm9yIGl0cyBWUE5zIHZpYSBhIDMyLWJpdA0KPiBT ZXNzaW9uDQo+ID4gICAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRlci4gIFdoZW4gcHJlc2Vu dCwgdGhlIEwyVFB2MyBDb29raWUNCj4gPiAgICAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xKSwg cHJvdmlkZXMgYW4gYWRkaXRpb25hbCBjaGVjayB0byBlbnN1cmUNCj4gPiAgICB0aGF0IGFuIGFy cml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4NCj4g PiAgICBUaHVzLCB1c2Ugb2YgYSBDb29raWUgd2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBh biBleHRyYQ0KPiBndWFyYW50ZWUNCj4gPiAgICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3 YXMgcGVyZm9ybWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZQ0KPiA+ICAgIFNlc3Npb24gSUQgaXRz ZWxmIHdhcyBub3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQo+ID4gLS0tc25pcC0tLQ0KPiA+IC4u LiBpbiByZWdhcmQgdG8gdGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBrbm93IHRoZSBTZWN1cml0eSBB cmVhIGZvbGtzDQo+IGhhdmUsIGluIHRoZQ0KPiA+IHBhc3QsIGhhZCAvc3Vic3RhbnRpYWwvIGNv bmNlcm5zIGFib3V0IGVuY2Fwc3VsYXRpb24gb2YgTVBMUyBvdmVyIElQDQo+IHRyYW5zcG9ydC4N Cj4gPiBJbiBmYWN0LCB0aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQgaW4gU2VjdGlvbiA3LjYsICJT ZWN1cml0eSIsIG9mIFJGQw0KPiA0NjY1Lg0KPiA+IChUaGVyZSdzIGxpa2VseSBzaW1pbGFyIGxh bmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZvcg0KPiB0cmFuc3BvcnQpLg0K PiA+IFdoaWxlIEknbSBub3Qgc3VyZSB0aGF0IFNlY3VyaXR5IEFyZWEgZm9sa3MgcGF5IG11Y2gg YXR0ZW50aW9uIHRvDQo+IGRhaWx5IHRyYWZmaWMgb24NCj4gPiB0aGUgTVBMUyBXRyBtYWlsaW5n IGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsDQo+IGFyaXNlIGlm L3doZW4gdGhpcw0KPiA+IGRyYWZ0IGdvZXMgdG8gdGhlIElFU0cgLi4uDQo+IA0KPiBJZiBJIHVu ZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGUgcmVhc29uIGZvciB5b3VyIHByZWZlcmVuY2Ugb2Yg TVBMUy0NCj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0 eSBmZWF0dXJlLiBJZiB0aGF0IGlzDQo+IHNvIGNvbmNlcm5lZCwgY2FuIHlvdSBleHBsYWluIHdo eSBNUExTLWluLUdSRSBpcyBmYXIgbW9yZSBwb3B1bGFyIHRoYW4NCj4gTVBMUy1pbi1MMlRQIGlu IHByYWN0aWNlPw0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4gDQo+ID4gMykgRmlu YWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1w bGVtZW50DQo+IEwyVFAsIGZvcg0KPiA+IHR1bm5lbGluZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBu b3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG8NCj4gc3VwcG9ydA0KPiA+IE1QTFMvVURQ IGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIgcHJvZHVjdCBsaW5lcy4NCj4gPg0KPiA+IC1zaGFuZQ0K PiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gPiBYaWFvaHUNCj4gPiA+ DQo+ID4gPj4gSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3ZlciBJUCwgdGhl biBjbGVhcmx5IGl0IHdvdWxkDQo+IGhhdmUNCj4gPiBiZWVuDQo+ID4gPj4gbW9yZSB3aWRlbHkg aW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMsIHdpdGggZWl0aGVyIE1QTFMNCj4gb3Zl cg0KPiA+IEdSRSBvcg0KPiA+ID4+IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUgdGhlcmUncyBh IHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSSB3b3VsZA0KPiBub3RlDQo+ID4gdGhhdA0KPiA+ID4+ IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBh cmUgc2V2ZXJhbCwNCj4gcHJhY3RpY2FsDQo+ID4gPj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25l IGdldHMgZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+ID4gPj4gZW5jYXBzdWxhdGlvbi9z d2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+ID4gPj4gLSBNUExTIEZh c3QgUmUtUm91dGUNCj4gPiA+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPiA+ID4+IC4u LiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21w ZWxsaW5nDQo+ID4gYXJndW1lbnRzDQo+ID4gPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8g c3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPiA+ID4+DQo+ID4gPj4gLXNo YW5lDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+PiAtSm9zaA0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ ID4+PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2Fk Y29tLmNvbT4NCj4gPiB3cm90ZToNCj4gPiA+Pj4NCj4gPiA+Pj4+IEZvciBzZXJ2aWNlIHByb3Zp ZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQIGlzIGxlZ2FjeSBhbmQgdGhlcmUgaXMNCj4gbm8gbmVl ZA0KPiA+ID4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBSZWdhcmRzLA0K PiA+ID4+Pj4gU2hhaHJhbQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBPbiBEZWMgMTcs IDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4g d3JvdGU6DQo+ID4gPj4+Pg0KPiA+ID4+Pj4+IFNoYWhyYW0sDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+ PiBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUA0K PiBlbmNhcHN1bGF0aW9uDQo+ID4gPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxh bmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gdGhvc2UNCj4gPiA+Pj4+PiBvcGVyYXRv cnMgd2hvIGhhcHBlbiB0byByZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uDQo+ IHRyYWZmaWMNCj4gPiA+Pj4+PiBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJh c2VkIFZQTiBvdmVyIElQLCBOVkdSRSBhbmQNCj4gPiBWWExBTg0KPiA+ID4+Pj4+IGVhY2ggaGF2 ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQgdXNlIGNhc2VzLiBJZiB5b3UgYWJzb2x1dGVseQ0K PiBiZWxpZXZlDQo+ID4gPj4+Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBM UyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+IGFjcm9zcyBJUA0KPiA+ID4+Pj4+IG5ldHdvcmtzIGFu ZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMgb3Zlcg0KPiBJ UA0KPiA+ID4+Pj4+IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0 b3JpYyBzdGF0dXMsIHBsZWFzZQ0KPiBzYXkNCj4gPiBzby4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4gPiA+Pj4+PiAoaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9udm8zL2N1cnJlbnQvbXNnMDE4NjQuaHRtbCkgaXMNCj4g PiA+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRo ZSBmb2xsb3dpbmcNCj4gYXJndW1lbnQNCj4gPiA+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3Qg TVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+IGNlbnRlcnMpLiBJDQo+ID4g Pj4+Pj4gaGFkIHRob3VnaHQgeW91IHdvdWxkIHNwZWFrIHVwIGF0IHRoYXQgdGltZS4gU2FkbHks DQo+IHN1cnByaXNpbmdseSBzaWxlbnQNCj4gPiA+Pj4+PiB0aWxsIG5vdy4NCj4gPiA+Pj4+Pg0K PiA+ID4+Pj4+IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lz ZS4NCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+IFhpYW9odQ0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4+IC0t LS0t08q8/tStvP4tLS0tLQ0KPiA+ID4+Pj4+PiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gtPoNCj4gse0NCj4gPiA+PiBTLg0KPiA+ ID4+Pj4+PiBEYXZhcmkNCj4gPiA+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNcjVIDEzOjM0 DQo+ID4gPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+ID4+Pj4+PiCzrcvNOiBkcmFm dC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsNCj4gPiA+Pj4+ Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4g1vfM4jogUmU6IFttcGxz XSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZQ0KPiA+ID4+Pj4+PiBkcmFm dC14dS1tcGxzLWluLXVkcCBhbg0KPiA+ID4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2lu Y2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGluDQo+IHRvZGF5J3MNCj4gPiA+Pj4+Pj4gbW9kZXJu IG1ldHJvDQo+ID4gPj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQg aXRzIG9ubHkgcHJhY3RpY2FsDQo+IGFwcGxpY2F0aW9uDQo+ID4gPj4+Pj4+IGluIGluIGRhdGEN Cj4gPiA+Pj4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBz b2x1dGlvbnMgc3VjaCBhcw0KPiBOVkdSRQ0KPiA+IGFuZA0KPiA+ID4+Pj4+PiBWWExBTi4NCj4g PiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4gSXQgc2VlbXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBi eXBhc3MgdGhlIE5WTzMgc29sdXRpb24NCj4gc2VsZWN0aW9uDQo+ID4gPj4+Pj4+IHByb2Nlc3MN Cj4gPiA+Pj4+Pj4gYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KPiA+ID4+Pj4+ Pg0KPiA+ID4+Pj4+PiBSZWdhcmRzLA0KPiA+ID4+Pj4+PiBTaGFocmFtDQo+ID4gPj4+Pj4+DQo+ ID4gPj4+Pj4+DQo+ID4gPj4+Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51PiB3cm90ZToNCj4gPiA+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IFdvcmtp bmcgZ3JvdXAsDQo+ID4gPj4+Pj4+Pg0KPiA+ID4+Pj4+Pj4gVGhpcyBpcyB0byBzdGFydCBhICJ0 d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+ID4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11 ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+ID4+Pj4+Pj4gRHVl IHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0aA0K PiBvbmUgd2Vlay4NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscw0KPiA+IHdvcmtpbmcNCj4g PiA+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBn aXZlIGFuDQo+IHRlY2huaWNhbA0KPiA+ID4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBw b3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiB0aGluayB0aGF0DQo+ID4gPj4+ Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91 cA0KPiBkb2N1bWVudC4NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBK YW51YXJ5IDA3LCAyMDEzLg0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJ UFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4gPiA+Pj4+Pj4+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBB bGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXAN Cj4gbWFpbGluZyBsaXN0DQo+ID4gPj4+Pj4+PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBh bnkgb3RoZXIgSVBSIGNsYWltcyB0aGFuIHRob3NlDQo+IGFscmVhZHkNCj4gPiA+Pj4+Pj4+IGRp c2Nsb3NlZC4NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+PiBIb3dldmVyLCB1cCB0byB2ZXJzaW9u IC0wMyAodGhlIGRvY3VtZW50IHRoYXQgd2UgdXNlZCBmb3IgdGhlDQo+IElQUg0KPiA+ID4+Pj4+ Pj4gcG9sbCkNCj4gPiA+Pj4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUg b2YgdGhlIGF1dGhvcnMuIE1hcnNoYWxsDQo+IGhhcw0KPiA+ID4+Pj4+Pj4gZGlzY29udGludWVk IGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZQ0KPiBhdXRob3Ig dGVhbQ0KPiA+ID4+Pj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5n IGdyb3VwIGNoYWlycyBoYXMNCj4gdHJpZWQgdG8NCj4gPiA+Pj4+Pj4+IGNvbnRhY3QgTWFyc2hh bGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbiB0aGUNCj4gSVBSDQo+ ID4gPj4+Pj4+PiBwb2xsLg0KPiA+ID4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0 aGlzLg0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhv cnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPiA+ID4+Pj4+Pj4gY28tYXV0aG9y Lg0KPiA+ID4+Pj4+Pj4NCj4gPiA+Pj4+Pj4+IC9Mb2ENCj4gPiA+Pj4+Pj4+IChtcGxzIHdnIGNv LWNoYWlyKQ0KPiA+ID4+Pj4+Pj4gLS0NCj4gPiA+Pj4+Pj4+DQo+ID4gPj4+Pj4+Pg0KPiA+ID4+ Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDoNCj4gPiA+ Pj4+Pj4gbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NCj4gPiA+Pj4+Pj4+IFNyIFN0cmF0ZWd5 IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+ID4+Pj4+Pj4g RXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1 MiAxMw0KPiA+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArNDYgNzY3IDcyIDkyIDEzDQo+ID4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g PiA+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0K PiA+ID4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g PiA+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+ IG1wbHNAaWV0Zi5vcmcNCj4gPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiBUaGlzIEUtbWFpbCBhbmQgYW55 IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcg0KPiBDYWJsZQ0KPiA+ ID4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yDQo+IHN1YmplY3QgdG8NCj4gPiA+PiBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPiBzb2xlbHkgZm9yDQo+ ID4gdGhlDQo+ID4gPj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBp dCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPiBhcmUgbm90IHRoZQ0KPiA+ID4+IGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdA0KPiBh bnkNCj4gPiBkaXNzZW1pbmF0aW9uLA0KPiA+ID4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cw0KPiBvZiBhbmQNCj4gPiA+ PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUNCj4gdW5sYXdmdWwuIElmIHlvdQ0KPiA+ID4+IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBpbW1lZGlhdGVseSBhbmQN Cj4gPiA+PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQNCj4gYW55IHByaW50b3V0Lg0KPiA+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+PiBtcGxzIG1haWxpbmcgbGlz dA0KPiA+ID4+PiBtcGxzQGlldGYub3JnDQo+ID4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4+DQo+ID4gPg0KPiA+DQoNCg== From cpignata@cisco.com Thu Dec 20 07:49:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3591221F8462 for ; Thu, 20 Dec 2012 07:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.178 X-Spam-Level: X-Spam-Status: No, score=-110.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JT092Pixv6w for ; Thu, 20 Dec 2012 07:49:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92E2721F8FF7 for ; Thu, 20 Dec 2012 07:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12246; q=dns/txt; s=iport; t=1356018544; x=1357228144; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vlsuE3gwUSV738MG1gFnM1he4XC7K4SyMrGqa2i2r8U=; b=B3VDB93QsDdoQqrARvwzVVK4HJa7pG4RI09QLEuiqZY3trBcMlRBxUp7 4pQjUUf/0TqyS74KbKsFWqSWZCQAjES8PzDW4z6s8UjdUYjEwEWIELD8T Tiz5PL3VKfXHEi9JVYU913L8MECb9gKl5VR6qUw/mBK+GLM4xhEqaWqhh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABcy01CtJXG9/2dsb2JhbABEvW4Wc4IXBwEBAQMBOi0HCQIFCwIBCBgKFAkHIREUEQIEDgUIhUEHgjEDCQYMr1wNiVWLaWkLg1dhA5JYgV2CcoobhRGCdIFtNQ X-IronPort-AV: E=Sophos;i="4.84,324,1355097600"; d="scan'208";a="152108145" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2012 15:49:01 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBKFn1Nb029010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 15:49:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 09:49:01 -0600 From: "Carlos Pignataro (cpignata)" To: "" Thread-Topic: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt Thread-Index: AQHN3kYT1pBvDgYtvUO7JXu4csIevpgiOxcA Date: Thu, 20 Dec 2012 15:49:01 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> References: <201212200008.qBK083C6010247@gateway1.orleans.occnc.com> In-Reply-To: <201212200008.qBK083C6010247@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <902EC7050E14154F9447E63168D1BC15@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 15:49:06 -0000 Hi, Curtis, Thanks for the response -- please see inline, skipping responses as implici= t Ack. On Dec 19, 2012, at 7:08 PM, Curtis Villamizar wrote: >=20 > Hi Carlos, >=20 > I see Andy and Kireeti already replied. >=20 > In message <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.co= m> > "Carlos Pignataro (cpignata)" writes: >>=20 >> Hi, Kireeti, >>=20 >> This is a very nicely written document that covers important aspects. >>=20 >> One early comment is that, in a way, this seems to actually be >> multi-part document, including requirements, as well as compliance and >> performance testing. One early question is whether it makes sense to >> take each part separately (even in different WGs, with one as a BCP in >> mpls in other in bmwg continuation of rfc5695). >>=20 >> I also agree with Andy's comments about some PW specific pieces to this. >>=20 >> Some more specific comments, hopefully these are clear and useful: >=20 > The sections with questions to ask and testing are intentionally terse > and serve only as outlines. This is to put a summary in one place. > If BMWG wants to launch one or more documents to cover the testing in > detailed benchmark specifications, they are more than welcome to do > so. That is why we gave Al a heads up and why Al gave the BMWG > mailing list a heads up. >=20 One concern with the terse specification of testing cases is that they coul= d use quite different methodology -- for example, how is the determination = required in T#10 performed? > Of course, if there is consensus to break up this document into more > than one, I'm OK with that approach. >=20 >> 2.1. Forwarding Basics >>=20 >> Should this section also include forwarding specifics about reserved >> labels, and in particular RA. >=20 > ... what Kireeti said. >=20 > Yes we could reference the reserved label list and also if there is > new work on "special purpose labels" we can reference that work too. >=20 > So far RFC 3032 specifies RA and the NULL labels (RFC 3032 is > obviously cited), the update to NULL is in RFC 4182 (cited), and GAL > is defined in RFC 5586. We also cover EL and ELI (RFC 6790) in some > detail. At this point that covers it for reserved labels. We can > explicitly point out RA. >=20 > We didn't cover OAM Alert Label #14 RFC3429 as use of ITU-T Y.1711 is > strongly discouraged today. Y.1711 doesn't work at all for multipath > and all service providers use multipath. >=20 > When Kireeti's "special purpose labels" draft becomes a WG item we can > point to "special purpose labels". I'm not sure what the WG concensus > is on that. We still have 4-6 and 8-12 to assign, which should be > plenty IMHO, but the extension mechanism can't hurt (too much). >=20 > Its been pointed out in private email that some TP OAM functions > require hardware support (DM, LM, and to a lesser extent CC/CV). The > most challenging may be LM. Also PTP and NTP benefit from hardware > support and the TICTOC work should be reflected here. >=20 >> 2.3. MPLS Multipath Techniques >>=20 >> ... >>=20 >> The most common multipath techniques are ECMP applied at the IP >> forwarding level, Ethernet LAG with inspection of the IP payload, and >> multipath on links carrying both IP and MPLS, where the IP header is >> inspected below the MPLS label stack. In most core networks, the >> vast majority of traffic is MPLS encapsulated. >>=20 >> In order to support an adequately even load distribution across >> multiple links, IP addresses must be used. Common practice today is >> to reinspect the IP addresses at each LSR and use the label stack and >> IP addresses in a hash performed at each LSR. >>=20 >> This description might appear oversimplified, especially in the >> presence of BCP128. It was interesting that RFC 4928 is not cited, >> when it contains a whole section on current ECMP practices at >> http://tools.ietf.org/html/bcp128#section-2. Further, this section >> describes how in addition to IP addresses, some cases use the label >> stack (alone or in combination) as input into the hash for multipath. >=20 > Both RFC4928 (BCP128) and RFC4385 are cited. RFC4928 section 2 is a > little dated and represents the LCD in roughly 2004 or so when this > draft was first introduced. >=20 > In response to private email comments from Shane Anante the > paragraph you pointed out as oversimplified had already been expanded. > A lot more is now said about the so-called 5-tuple commonly used and > the use of other fields. There is now a new section "2.3.5. Fields > Used for Multipath" which we can put a forward reference to. >=20 >> 2.3.1. Pseudowire Control Word >>=20 >> Within the core of a network some form of multipath is almost certain >> to be used. Multipath techniques deployed today are likely to be >> looking beneath the label stack for an opportunity to hash on IP >> addresses. >>=20 >> A pseudowire encapsulated at a network edge must have a means to >> prevent reordering within the core if the pseudowire will be crossing >> a network core, or any part of a network topology where multipath is >> used. >>=20 >> Not supporting the ability to encapsulate a pseudowire with a control >> word may lock a product out from consideration. A pseudowire >> capability without control word support might be sufficient for >> applications which are strictly both intra-metro and low bandwidth. >> However a provider with other applications will very likely not >> tolerate having equipment which can only support a subset of their >> pseudowire needs. >>=20 >> While I agree with this text, I wonder if it is attempting to set up a >> new requirement. For example, although not 2119-capitalized, "A >> pseudowire encapsulated at a network edge must have a means to prevent >> reordering within the core". PWE3 has been discussing this topic, but >> today's specs include PW Types for which a CW is optional. Similarly, >> recommendations are already at this >> http://tools.ietf.org/html/bcp128#section-3. >=20 > What Andy said ... >=20 > BTW- Andy has sent quite a lot of private email about PW which will be > reflected in the next iteration. Thanks. >=20 >> 2.3.2. Pseudowire Flow Label >>=20 >> ... >> Any pseudowire which does not carry a flow label is in effect a >> single microflow (in [RFC2475] terms). >>=20 >> This is a bit of a corner-case nit, but for completeness: this is not >> the case for IP L2 Transport PW without its optional CW (without flow >> label) http://tools.ietf.org/html/rfc4447#section-4.1. >=20 > People use L2TP? :-) >=20 Very much so -- but that is orthogonal to my comment, which is about IP L2 = and not L2TP. > OK - PW with MPLS PSN, but then again this is an MPLS document. >=20 > I don't see what point you are trying to make. Sorry if I managed to confuse you. Let me try again -- it is a nit. RFC 4447 (PW setup using LDP) defines in Section 4.1 (pointer included abov= e) the "IP Layer 2 Transport" Pseudowire (PW Type 0x000B). This is a PW FEC= , that when used without CW looks in the DP as an RFC 3032 MPLS encapsulate= d IP datagram. It's used in arp-med, ipls, etc. I was just pointing out that for that particular PW, the multipath is as if= IP payload directly on MPLS (since it is in the DP). I do not intend to co= nvolute the description and remove generalization to somehow cover this, bu= t I thought I'd bring it up in case. >=20 >> 2.3.2. Pseudowire Flow Label >>=20 >> 2.3.3. MPLS Entropy Label >>=20 >> (see Section 2.3) >>=20 >> This is an editorial nit, but for readability -- it confused me to see >> a pointer to S2.3 within S2.3.x (as if there is an (apparent) reading >> loop). >=20 > I'll change the reference to "2.3.5. Fields in Multipath" which > is new. BTW- that section starts by saying "Inspecting the IP payload > provides the most entropy in provider networks. The practice of > looking past the bottom of stack label for an IP payload is well > accepted and documented in [RFC4928] and in other RFCs." just to be > clear that the reason for inclusion in an MPLS document is that you > need to look under the MPLS label stack for this purpose. >=20 Thanks. >> 3. Questions for Suppliers >>=20 >> Q#10 Are reserved labels included in the label stack hash? They >> MUST NOT be included. >>=20 >> Could a citation be included for this MUST NOT? Or is this document >> adding this requirement? I think there was a mention in RFC 6790, but >> RFC4928/BCP128 says: >=20 > Eliminated the double negative. It now says "Are reserved labels > excluded from the label stack hash? They MUST be excluded [RFC6790]." >=20 > RFC 6790 is cited elsewhere but is now cited here as well. >=20 >> Any reserved label, no >> matter where it is located in the stack, may be included in the >> computation for load balancing. Modification of the label stack >> between packets of a single flow could result in re-ordering that >> flow. That is, were an explicit null or a router-alert label to be >>=20 >> added to a packet, that packet could take a different path through >> the network. >>=20 >> 4. Forwarding Compliance and Performance Testing >>=20 >> I wonder if this complete section should be progressed independently >> in a separate document. >=20 > If your "wondering" becomes the WG concensus, then I'm OK with that. >=20 > My preference is to keep this brief summary of necessary testing with > the requirements and expand on details of specific tests in BMWG. >=20 >> Again, this is an useful well-written document, thanks! >>=20 >> -- Carlos. >=20 > Thanks for the comments, here in MPLS as well as in BMWG. >=20 > The following changes have been edited into (my local copy) of the > draft and are likely to make the next iteration (unless Kireeti > objects). >=20 > 1. Expanded a bit on reserved labels. Mention TP OAM (to be > expanded on in later sections). Mention PTP and NTP. >=20 > 2. Defer inclusion of "special purpose labels" for now. >=20 > 3. The paragraph introducing multipath had already been expanded. >=20 > 4. Andy already sent two rounds of extensive comments on PW. I > have yet to edit in the second round. >=20 > 5. Clarified PW without flow label to mean PW carried over MPLS > without flow label (though I don't really agree that we need > that clarification). >=20 > 6. Fixed reference to 2.3 in 2.3.3. It now refers to the new > section "2.3.5. Fields in Multipath". >=20 > 7. Changed "MUST NOT be included" to "MUST exclude" in two places > where reserved labels in hash are discussed. Referenced RFC6790 > in both places. >=20 > I may send out a 01 without Andy's latest rounds of comments, then > following shortly after with an 02. This would be a better basis for > discussion. I'll see what Kireeti thinks of sending this out vs > waiting for all of the changes to get edited in and then sending out > an 01. We still have off list discussions on other topics such as TP > OAM with changes pending. >=20 Thanks much. -- Carlos. > Curtis >=20 >=20 >> On Oct 8, 2012, at 8:30 PM, Kireeti Kompella > wrote: >>=20 >> Hi Folks, >>=20 >> I'd spoken on the issue of deep label stacks at the last IETF, and >> there was interest from chip suppliers, vendors and service providers. >> Curtis just submitted the draft; it goes beyond just deep label >> stacks. There are suggestions in the draft on aspects of implementing >> MPLS forwarding, as well as questions to ask regarding an >> implementation, and things to test. >>=20 >> Please read and comment to the list. >>=20 >> If you (that includes MPLS WG chairs and ADs) could also formulate >> your thoughts on what type of doc (Info, BCP, PS) this should be, that >> would be very helpful in moving this discussion forward. >>=20 >> Thanks, >> Kireeti. >=20 From davari@broadcom.com Thu Dec 20 08:34:12 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4621F86B0 for ; Thu, 20 Dec 2012 08:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=-1.887, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buuXQ+bT5bCn for ; Thu, 20 Dec 2012 08:34:11 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF721F84F0 for ; Thu, 20 Dec 2012 08:34:09 -0800 (PST) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 20 Dec 2012 08:31:58 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 20 Dec 2012 08:33:53 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 20 Dec 2012 08:33:32 -0800 From: "Shahram Davari" To: "Lucy yong" Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3s+/R6wH2496W026x2QpZjBKZw== Date: Thu, 20 Dec 2012 16:33:31 +0000 Message-ID: <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CCDE2F41ZK1727477-01-01 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:34:12 -0000 TmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBjb25z ZW50ZWQgIGluIE5WTzMgV0cuDQoNClJlZ2FyZHMsDQpTaGFocmFtDQoNCg0KT24gRGVjIDIwLCAy MDEyLCBhdCA3OjM5IEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3Rl Og0KDQo+IEhpIFNoYW5lLA0KPiANCj4gSSB1bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4gb24g YSBuZXcgZW5jYXBzdWxhdGlvbiB0byBhbiBleGlzdGluZyBuZXR3b3JrLiANCj4gDQo+IEhvd2V2 ZXIsIE1QTFMtaW4tVURQIGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9N UExTIG5ldHdvcmsgYXQgYWxsLg0KPiBNUExTLWluLVVEUCBpcyB0byBlbmFibGUgTVBMUyBjbGll bnQgbGF5ZXIgdG8gYmUgZGVjb3VwbGVkIGZyb20gTVBMUyBzZXJ2ZXIgbGF5ZXIgYW5kIHVzZSBN UExTIGNsaWVudCBsYXllciBhcyBvdmVybGF5IG5ldHdvcmsgYW5kIGFuIElHUCBhcyBhIHVuZGVy bHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBTdWNoIGFwcGxpY2F0aW9uIGlzIGZvciBEQy4g WW91IG1heSBhcmd1ZSB3aHkgbm90IHVzZSB0aGUgR1JFIHdoaWNoIGlzIGZvciBNUExTIGxheWVy IG92ZXIgYW4gSUdQIHVuZGVybGluZyBuZXR3b3JrLiBXZSBoYXZlIHBvaW50ZWQgb3V0IGluIHRo ZSBkcmFmdCB0aGF0IGN1cnJlbnQgcm91dGVycyBpbiBEQyBiYXJlbHkgc3VwcG9ydCBHUkUgYmFz ZWQgbG9hZCBiYWxhbmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkgdXNlZCBpbiBTUCBu ZXR3b3JrcyB0b28uIE1vc3Qgb2Ygcm91dGVycyBpbiBEQyBwZXJmb3JtIHVwZCBwb3J0IGJhc2Vk IGxvYWQgYmFsYW5jaW5nIG5vdy4gIA0KPiANCj4gRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNw ZWN0aXZlLCB0aGUgVURQIGVuY2Fwc3VsYXRpb24gaGFzIGFkdmFudGFnZSBvdmVyIEdSRSBlbmNh cHN1bGF0aW9uIHRvby4gSW4gVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZSBoZWFkZXIgZGVj b3VwbGVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBv dXRlciBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFk ZXIsIHdoaWNoIHVuZGVybHlpbmcgbmV0d29yayB1c2VzIG9ubHkuIEhvd2V2ZXIsIEdSRSBoZWFk ZXIgaGFzIHRoZSBmaWVsZHMgZm9yIHRoZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtl eSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3IgbG9hZCBiYWxhbmNpbmcsIGl0IHJlcXVpcmVz IHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBHUkUgaGVhZGVyIHRvby4gSW4gc2hvcnQsIEdS RSB0aWVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5j ZSBpdCBoYXMgbm90IHVzZWQgYSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNh ZHZhbnRhZ2Ugb2Ygc3VjaCBjb3VwbGluZy4NCj4gDQo+IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0 b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGFuZCBkZWNvdXBsZXMgb3Zlcmxh eSBuZXR3b3JrcyBmcm9tIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsuIEEgY2xlYXIgc2VwYXJhdGlv biBvZiBvdmVybGF5IGhlYWRlciBhbmQgdW5kZXJseWluZyBoZWFkZXIgaXMgYSAiTVVTVCIgaW4g bXkgb3Bpbmlvbi4gSWYgd2UgY291bnQgR1JFIGFzIHRoZSBvdmVybGF5IGhlYWRlciwgdGhlbiBm b3IgSVB2NCB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUgZmxv dyBlbnRyb3B5LiBUaGlzIGlzIHRoZSByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVuY2Fwc3Vs YXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZyBuZXR3b3JrLiBJbiBmYWN0LCBpdCBj YW4gc3VwcG9ydCBhbnkgb3ZlcmxheSBuZXR3b3JrIGJlc2lkZSBNUExTIGNsaWVudCBsYXllciAo ZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAsIGV0YykuIA0KPiANCj4gWW91IHBvaW50IG91dCB1c2lu ZyBNUExTLWluLUwyVFAtaW4tVURQIGluc3RlYWQuIFllcywgTVBMUy1pbi1MMlRQLWluLVVEUCBz Y2hlbWEgYWxzbyBwcm92aWRlcyBhIG92ZXJsYXkgKEwyVFApIGFuZCB1bmRlcmx5aW5nIChJUCkg bmV0d29yayBkZWNvdXBsaW5nLiBMMlRQIHByb3RvY29sIChyZmMzOTMxKSBwcm92aWRlcyBnb29k IHNlY3VyaXR5IG1lY2hhbmlzbSBhbmQgaGFzIHRoZSBlbWJlZGRlZCBjb250cm9sIGZ1bmN0aW9u IHRvby4gVGhlcmVmb3JlLCBzb21lb25lIGNhbiB1c2UgaXQgZm9yIE1QTFMgY2xpZW50IGxheWVy IG92ZXIgSW50ZXJuZXQuIFRvIGhhdmUgTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5k ZXJsaW5nIG5ldHdvcmssIElNTzogTVBMUy1pbi1MMlRQLWluLVVEUCBpcyBhIG92ZXJraWxsIGFu ZCB0b28gY29tcGxleC4gSGVyZSB3ZSBuZWVkIGEgc2NoZW1hIHRvIHN1cHBvcnQgSUdQIHVuZGVy bHlpbmcgdHJhbnNwb3J0IHdpdGhvdXQgdG91Y2hpbmcgYSBvdmVybGF5IGhlYWRlci4gVURQIGVu Y2Fwc3VsYXRpb24gaXMgdGhlIGJlc3QgY2hvaWNlIHRvIGFjY29tcGxpc2ggdGhhdCBhbmQgbWlu aW1pemUgdGhlIGNoYW5nZXMgb24gZXhpc3Rpbmcgcm91dGVycywgZS5nLiBjaGFuZ2UgYXQgZWRn ZSByb3V0ZXJzLCBubyBjaGFuZ2Ugb24gdHJhbnNpdCByb3V0ZXJzLg0KPiANCj4gUmVnYXJkcywN Cj4gTHVjeSANCj4gDQo+IA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+PiBTZW50OiBUaHVy c2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNDoxNCBBTQ0KPj4gVG86IFNoYW5lIEFtYW50ZQ0KPj4g Q2M6IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRv b2xzLmlldGYub3JnOw0KPj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmcNCj4+IFN1YmplY3Q6IERpc2N1c3Npb24gb24gaG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIg VURQIHR1bm5lbHMNCj4+IA0KPj4gSGkgU2hhbmUsDQo+PiANCj4+IFRoYW5rcyBmb3IgeW91ciBm dXJ0aGVyIGNvbW1lbnRzIGFuZCBwbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZS4NCj4+IA0K Pj4gTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdzIHN1 Z2dlc3Rpb24uDQo+PiANCj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3orz+yMs6IFNoYW5l IEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4+PiC3osvNyrG85DogMjAx MsTqMTLUwjE5yNUgMjI6MzgNCj4+PiDK1bz+yMs6IFh1eGlhb2h1DQo+Pj4gs63LzTogUm9nZXJz LCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi0NCj4+IHVkcEB0b29scy5p ZXRmLm9yZzsNCj4+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1h a2UgZHJhZnQteHUtDQo+PiBtcGxzLWluLXVkcCBhbg0KPj4+IG1wbHMgd29ya2luZyBncm91cCBk b2N1bWVudA0KPj4+IA0KPj4+IFhpYW9odSwNCj4+PiANCj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0 IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4gLS0t LS3Tyrz+1K28/i0tLS0tDQo+Pj4+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5l QGNhc3RsZXBvaW50Lm5ldF0NCj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0K Pj4+Pj4gytW8/sjLOiBSb2dlcnMsIEpvc2gNCj4+Pj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBY dXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi0NCj4+IHVkcEB0b29scy5pZXRmLm9yZzsNCj4+Pj4+ IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+Pj4+PiDW98ziOiBS ZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1 LQ0KPj4gbXBscy1pbi11ZHANCj4+PiBhbg0KPj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAi Um9nZXJzLCBKb3NoIg0KPj4gPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KPj4+Pj4gd3JvdGU6 DQo+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUg cHJvYmxlbSB0aGlzDQo+PiBzb2x1dGlvbg0KPj4+Pj4+IGFkZHJlc3NlcyBpbiBwcmFjdGljZSBh bnkgbG9uZ2VyLg0KPj4+Pj4gDQo+Pj4+PiArMS4gIFBsZWFzZSBkbyBub3QgZGVmaW5lIHlldCBh bm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0aW9uLg0KPj4gVGhlDQo+Pj4gSUVURg0KPj4+ Pj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNv DQo+PiBzdGFuZGFyZGl6ZWQNCj4+PiBNUExTDQo+Pj4+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdo aWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBvbmUsDQo+PiB2ZXJ5DQo+ Pj4+PiBsYXJnZSBvcGVyYXRvciBuZXR3b3JrIHRoYXQgSSdtIGF3YXJlIG9mIHRvIHN1cHBvcnQg Y2FycmlhZ2Ugb2YNCj4+IEwzVlBOIG92ZXINCj4+PiBhbg0KPj4+Pj4gSVAtb25seSBuZXR3b3Jr Lg0KPj4+PiANCj4+Pj4gSGkgU2hhbmUsDQo+Pj4+IA0KPj4+PiBUaGFuayB5b3UgZm9yIHRlbGxp bmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXINCj4+IElQIGlu IGF0DQo+Pj4gbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFj dCBtdXN0IGJlIHZlcnkNCj4+IHZhbHVhYmxlIHRvIHRob3NlDQo+Pj4gcGVvcGxlIHdobyBoYWQg YmVsaWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluDQo+PiB0 b2RheSdzIFNQDQo+Pj4gbmV0d29ya3MuDQo+Pj4+IA0KPj4+Pj4gU2VlOiBSRkMncyA0NDU0LCA0 NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYzDQo+Pj4+PiBbTk9URTogdGhlIGRh dGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUgMjAwNg0KPj4+IHRp bWVmcmFtZSFdDQo+Pj4+PiAgICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g VlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4+IG1heSBiZQ0KPj4+Pj4gY2FycmllZCBvdmVyIEwy VFB2Mw0KPj4+Pj4gICAgQW5kLCBoZXJlJ3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0 IG9uZSB2ZW5kb3IgaGFzDQo+Pj4gaW1wbGVtZW50ZWQNCj4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQ djM6DQo+PiBodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJl L2d1aWRlL2NzZ2wzdnBuLmh0bWwNCj4+Pj4gDQo+Pj4+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmlu ZyB0aGUgYWJvdmUgaW5mb3JtYXRpb24uIEFzIG1lbnRpb25lZCBpbg0KPj4gdGhpcyBkcmFmdA0K Pj4+IEFORCBvdGhlciBkcmFmdHMsIHRoZSBtZWNoYW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNh bGN1bGF0aW9uIG9uIHRoZQ0KPj4gU2Vzc2lvbg0KPj4+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMg aGVhZGVyIG9yIHRoZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgYXMNCj4+IGRlZmluZWQg aW4NCj4+PiBbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0aW5nIGNv cmUgcm91dGVycyBzbyBmYXIuDQo+Pj4gDQo+Pj4gRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBp biB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4NCj4+IHJlcXVlc3RpbmcgYSBjb3JlDQo+ Pj4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNl ZCBpbiBoYXNoDQo+PiBjYWxjdWxhdGlvbnMgaW4NCj4+PiBfZXhpc3RpbmdfIGhhcmR3YXJlLCBh bHJlYWR5IGRlcGxveWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteQ0KPj4gbmV0d29yay4N Cj4+PiBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0b3Jz IGFyZSBzYXZ2eSBmb2xrcw0KPj4gYW5kDQo+Pj4gdW5kZXJzdGFuZCB0aGUgaW50ZXJuYWwgYXJj aGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPj4gcmVzdWx0LCB0aG9z ZQ0KPj4+IHNhbWUgb3BlcmF0b3JzIGtub3cgd2hhdCBpcyBhbmQgaXMgbm90IHRlY2huaWNhbGx5 IHBvc3NpYmxlIGluIHRoaXMNCj4+IHJlZ2FyZC4NCj4+PiBUaHVzLCBpdCBtYXkgYmUgYSBxdWVz dGlvbiBvZiAibWV0aG9kcyIgbmVjZXNzYXJ5IHRvIGNvbnZpbmNlIHRoZWlyDQo+PiBIVw0KPj4+ IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlhdGUgY2hhbmdlcyBpbiB0aGVpciBlcXVpcG1l bnQgdG8gYWNoaWV2ZQ0KPj4gdGhlaXINCj4+PiBidXNpbmVzcyBnb2Fscy4gIDotKSAgSG93ZXZl ciwgdGhpcyBtYXkgbm90IGV2ZW4gYmUgbmVjZXNzYXJ5IC4uLiBzZWUNCj4+IGJlbG93Lg0KPj4g DQo+PiBDb3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJv dmUgY2hhbmdlIGluDQo+PiBFWElTVElORyBoYXJkd2FyZSBvZiBhbHJlYWR5IGRlcGxveWVkIGNv cmUgcm91dGVycz8NCj4+IA0KPj4+PiBJbiBjb250cmFzdCwgbW9zdCBleGlzdGluZyBjb3JlIHJv dXRlcnMgYXJlIGFscmVhZHkgY2FwYWJsZSBvZg0KPj4gYmFsYW5jaW5nIElQDQo+Pj4gdHJhZmZp YyBmbG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFja2V0 cy4gQnkNCj4+IHVzaW5nIHRoZQ0KPj4+IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBh bHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJhbGFuY2luZw0KPj4gY2FwYWJpbGl0eSBvZg0KPj4+IG1v c3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIGNhbiBiZSBsZXZlcmFnZWQgd2l0aG91dCByZXF1aXJp bmcgYW55DQo+PiBjaGFuZ2UgdG8NCj4+PiB0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBtb3RpdmF0 aW9uIG9mIHRoaXMgZHJhZnQuDQo+Pj4gDQo+Pj4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4g d2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbg0KPj4gTVBMUy9MMlRQdjMsIHdoaWNo DQo+Pj4gdXNlcyBVRFAvSVAsIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4+IA0KPj4gSWYgSSB1bmRl cnN0YW5kIGl0IGNvcnJlY3RseSwgeW91IHByZWZlciB0byB1c2UgTVBMUy1pbi1MMlRQdjMtaW4t VURQDQo+PiBpbnN0ZWFkIG9mIE1QTFMtaW4tVURQLCByaWdodD8NCj4+IA0KPj4+IElNSE8sIGEg YmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0 bw0KPj4gUkZDIDM5MzEsDQo+Pj4gd2hpY2ggd291bGQgYWxsb3cgdGhlIGNvbm5lY3Rpb24gdXNl ZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbA0KPj4gcGFja2V0cykNCj4+PiB0byB1c2Ug YSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwg YmFzZWQNCj4+IG9uIGEgaGFzaA0KPj4+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBs b2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudA0KPj4gaW4gYW4NCj4+PiBJUC1v bmx5IGNvcmUuICBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRl ciBvZmYNCj4+IGp1c3QgdXNpbmcNCj4+PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIp IGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0bw0KPj4gYXNzb2NpYXRlDQo+Pj4gaW5jb21p bmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4g ZmFjdCwNCj4+IGl0J3Mgbm90DQo+Pj4gY2xlYXIgdG8gbWUgdGhhdCBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLA0KPj4gbWFraW5nIGFueQ0KPj4+ICJjaGVj ayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1z eXN0ZW0NCj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4gDQo+Pj4gVGhlIGJlYXV0eSBvZiB0aGUg YWJvdmUgYXBwcm9hY2ggaXM6DQo+Pj4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBp cyBtb3N0IGxpa2VseSBhIGNoYW5nZSB0aGF0IGlzDQo+PiBsaW1pdGVkIHRvIHRoZQ0KPj4+ICJj b250cm9sIGNoYW5uZWwiIChzb2Z0d2FyZSkgb2YgZXhpc3RpbmcgTDJUUCBlbmQtc3lzdGVtDQo+ PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4gSGVjaywgaXQgbWF5IGV2ZW4gYmUgYmFja3dhcmRzIGNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBMMlRQdjMNCj4+PiBpbXBsZW1lbnRhdGlvbnMuICAoTDJU UHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQgb24gdGhhdCkuDQo+PiANCj4+ IElNSE8sIG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsICB0 aGUgaGFyZHdhcmUgb2YNCj4+IFBFIHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUuZy4s IGluZ3Jlc3MgUEUgcm91dGVycyBuZWVkIHRvIGZpbGwNCj4+IGluIGFuIGVudHJvcHkgdmFsdWUg aW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPj4gDQo+Pj4gMikgVGhl cmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBieSB1c2luZyAiU2Vz c2lvbg0KPj4gSUQiIGFuZA0KPj4+ICJDb29raWUiIGZpZWxkcyB0byBlbnN1cmUgdGhlIHJlY2Vp dmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yDQo+PiB0aGUNCj4+PiBpZGVudGlmaWVk IHNlc3Npb24uICBRdW90aW5nIGZyb20gU2VjdGlvbiA4LjIgb2YgUkZDIDM5MzE6DQo+Pj4gLS0t c25pcC0tLQ0KPj4+ICAgTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRz IFZQTnMgdmlhIGEgMzItYml0DQo+PiBTZXNzaW9uDQo+Pj4gICBJRCBpbiB0aGUgTDJUUHYzIGRh dGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KPj4+ICAgKGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8gZW5z dXJlDQo+Pj4gICB0aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlk ZW50aWZpZWQgc2Vzc2lvbi4NCj4+PiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBT ZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhDQo+PiBndWFyYW50ZWUNCj4+PiAgIHRoYXQgdGhl IFNlc3Npb24gSUQgbG9va3VwIHdhcyBwZXJmb3JtZWQgcHJvcGVybHkgYW5kIHRoYXQgdGhlDQo+ Pj4gICBTZXNzaW9uIElEIGl0c2VsZiB3YXMgbm90IGNvcnJ1cHRlZCBpbiB0cmFuc2l0Lg0KPj4+ IC0tLXNuaXAtLS0NCj4+PiAuLi4gaW4gcmVnYXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkg a25vdyB0aGUgU2VjdXJpdHkgQXJlYSBmb2xrcw0KPj4gaGF2ZSwgaW4gdGhlDQo+Pj4gcGFzdCwg aGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92 ZXIgSVANCj4+IHRyYW5zcG9ydC4NCj4+PiBJbiBmYWN0LCB0aGlzIGlzIHdoeSB5b3Ugc2VlIHRl eHQgaW4gU2VjdGlvbiA3LjYsICJTZWN1cml0eSIsIG9mIFJGQw0KPj4gNDY2NS4NCj4+PiAoVGhl cmUncyBsaWtlbHkgc2ltaWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhhdCB1c2UgTVBM UyBmb3INCj4+IHRyYW5zcG9ydCkuDQo+Pj4gV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJp dHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8NCj4+IGRhaWx5IHRyYWZmaWMgb24N Cj4+PiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMg Y29uY2VybiB3aWxsDQo+PiBhcmlzZSBpZi93aGVuIHRoaXMNCj4+PiBkcmFmdCBnb2VzIHRvIHRo ZSBJRVNHIC4uLg0KPj4gDQo+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGUgcmVh c29uIGZvciB5b3VyIHByZWZlcmVuY2Ugb2YgTVBMUy0NCj4+IGluLUwyVFB2My1pbi1VRFAgaXMg dGhhdCBpdCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdCBpcw0KPj4gc28g Y29uY2VybmVkLCBjYW4geW91IGV4cGxhaW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBv cHVsYXIgdGhhbg0KPj4gTVBMUy1pbi1MMlRQIGluIHByYWN0aWNlPw0KPj4gDQo+PiBCZXN0IHJl Z2FyZHMsDQo+PiBYaWFvaHUNCj4+IA0KPj4+IDMpIEZpbmFsbHksIHRoaXMgYXBwcm9hY2ggb25s eSBhZmZlY3RzIHRoZSBlbmQtc3lzdGVtcyB0aGF0IGltcGxlbWVudA0KPj4gTDJUUCwgZm9yDQo+ Pj4gdHVubmVsaW5nIG9mIE1QTFMvSVAsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFuIGVudGlyZSBp bmR1c3RyeSB0bw0KPj4gc3VwcG9ydA0KPj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4gdGhl aXIgcHJvZHVjdCBsaW5lcy4NCj4+PiANCj4+PiAtc2hhbmUNCj4+PiANCj4+PiANCj4+Pj4gDQo+ Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4gWGlhb2h1DQo+Pj4+IA0KPj4+Pj4gSWYgdGhlcmUgd2Fz IG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0IHdvdWxkDQo+ PiBoYXZlDQo+Pj4gYmVlbg0KPj4+Pj4gbW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBt ZW50IHZlbmRvcnMsIHdpdGggZWl0aGVyIE1QTFMNCj4+IG92ZXINCj4+PiBHUkUgb3INCj4+Pj4+ IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkp LiAgSSB3b3VsZA0KPj4gbm90ZQ0KPj4+IHRoYXQNCj4+Pj4+IHRoZSBtb3N0IGxpa2VseSByZWFz b25zIHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmUgc2V2ZXJhbCwNCj4+IHByYWN0 aWNhbA0KPj4+Pj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25lIGdldHMgZnJvbSBnb2luZyB3aXRo IG5hdGl2ZSBNUExTDQo+Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4gdGhlIGRh dGEgcGxhbmUsIG5hbWVseToNCj4+Pj4+IC0gTVBMUyBGYXN0IFJlLVJvdXRlDQo+Pj4+PiAtIE1Q TFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4+Pj4gLi4uIHRvIG5hbWUsIGJ1dCBhIGZldy4gIFRo b3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxpbmcNCj4+PiBhcmd1bWVudHMNCj4+ Pj4+IHRvICd1cGdyYWRlJyBuZXR3b3JrIEhXIHRvIHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0aW9u L3N3aXRjaGluZy4NCj4+Pj4+IA0KPj4+Pj4gLXNoYW5lDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4+ IC1Kb3NoDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJT aGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb20+DQo+Pj4gd3JvdGU6DQo+Pj4+Pj4g DQo+Pj4+Pj4+IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQIGlzIGxl Z2FjeSBhbmQgdGhlcmUgaXMNCj4+IG5vIG5lZWQNCj4+Pj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1 eGlhb2h1QGh1YXdlaS5jb20+DQo+Pj4gd3JvdGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gU2hhaHJh bSwNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHBy b3ZpZGUgYSBNUExTLW92ZXItSVANCj4+IGVuY2Fwc3VsYXRpb24NCj4+Pj4+Pj4+IG1ldGhvZCB3 aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRvDQo+PiB0 aG9zZQ0KPj4+Pj4+Pj4gb3BlcmF0b3JzIHdobyBoYXBwZW4gdG8gcmVxdWlyZSB0cmFuc3BvcnRp bmcgTVBMUyBhcHBsaWNhdGlvbg0KPj4gdHJhZmZpYw0KPj4+Pj4+Pj4gYWNyb3NzIElQIG5ldHdv cmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5kDQo+Pj4gVlhM QU4NCj4+Pj4+Pj4+IGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQgdXNlIGNhc2Vz LiBJZiB5b3UgYWJzb2x1dGVseQ0KPj4gYmVsaWV2ZQ0KPj4+Pj4+Pj4gaXQncyBtZWFuaW5nbGVz cyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+PiBhY3Jvc3MgSVAN Cj4+Pj4+Pj4+IG5ldHdvcmtzIGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxh dGVkIHRvIE1QTFMgb3Zlcg0KPj4gSVANCj4+Pj4+Pj4+IHR1bm5lbGluZyBtZWNoYW5pc21zIHNo b3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMsIHBsZWFzZQ0KPj4gc2F5DQo+Pj4gc28u DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+Pj4+ IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+PiBhcmNoaXZlL3dlYi9udm8zL2N1cnJlbnQv bXNnMDE4NjQuaHRtbCkgaXMNCj4+Pj4+Pj4+IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBzdWl0YWJs ZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZw0KPj4gYXJndW1lbnQNCj4+Pj4+Pj4+IChp LmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEN Cj4+IGNlbnRlcnMpLiBJDQo+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAg YXQgdGhhdCB0aW1lLiBTYWRseSwNCj4+IHN1cnByaXNpbmdseSBzaWxlbnQNCj4+Pj4+Pj4+IHRp bGwgbm93Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5 IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFhpYW9odQ0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+Pj4+Pj4+Pj4gt6K8/sjLOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6DQo+PiCx 7Q0KPj4+Pj4gUy4NCj4+Pj4+Pj4+PiBEYXZhcmkNCj4+Pj4+Pj4+PiC3osvNyrG85DogMjAxMsTq MTLUwjE1yNUgMTM6MzQNCj4+Pj4+Pj4+PiDK1bz+yMs6IExvYSBBbmRlcnNzb24NCj4+Pj4+Pj4+ PiCzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9y ZzsNCj4+Pj4+Pj4+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+Pj4+INb3zOI6 IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UNCj4+Pj4+ Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPj4+Pj4+Pj4+IG1wbHMgd29ya2luZyBncm91 cCBkb2N1bWVudA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRy YWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbg0KPj4gdG9kYXkncw0KPj4+Pj4+Pj4+ IG1vZGVybiBtZXRybw0KPj4+Pj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50 LCBhbmQgaXRzIG9ubHkgcHJhY3RpY2FsDQo+PiBhcHBsaWNhdGlvbg0KPj4+Pj4+Pj4+IGluIGlu IGRhdGENCj4+Pj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90 aGVyIHNvbHV0aW9ucyBzdWNoIGFzDQo+PiBOVkdSRQ0KPj4+IGFuZA0KPj4+Pj4+Pj4+IFZYTEFO Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcg dG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uDQo+PiBzZWxlY3Rpb24NCj4+Pj4+Pj4+PiBwcm9j ZXNzDQo+Pj4+Pj4+Pj4gYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFu ZGVyc3NvbiA8bG9hQHBpLm51PiB3cm90ZToNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gV29ya2lu ZyBncm91cCwNCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdv IHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAt MDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPj4+Pj4+Pj4+PiBEdWUgdG8g dGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRoDQo+PiBv bmUgd2Vlay4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzDQo+Pj4gd29ya2luZw0KPj4+Pj4+ Pj4+PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBh bg0KPj4gdGVjaG5pY2FsDQo+Pj4+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9u b3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UNCj4+IHRoaW5rIHRoYXQNCj4+Pj4+Pj4+Pj4g dGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4+ IGRvY3VtZW50Lg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFy eSAwNywgMjAxMy4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xh aW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvMTk0MS8gLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gQWxsIHRoZSBh Y3RpdmUgY28tYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+PiBtYWls aW5nIGxpc3QNCj4+Pj4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVy IElQUiBjbGFpbXMgdGhhbiB0aG9zZQ0KPj4gYWxyZWFkeQ0KPj4+Pj4+Pj4+PiBkaXNjbG9zZWQu DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIb3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAodGhl IGRvY3VtZW50IHRoYXQgd2UgdXNlZCBmb3IgdGhlDQo+PiBJUFINCj4+Pj4+Pj4+Pj4gcG9sbCkN Cj4+Pj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0 aG9ycy4gTWFyc2hhbGwNCj4+IGhhcw0KPj4+Pj4+Pj4+PiBkaXNjb250aW51ZWQgYWxsIGludGVy YWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+PiBhdXRob3IgdGVhbQ0KPj4+ Pj4+Pj4+PiBvZiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hh aXJzIGhhcw0KPj4gdHJpZWQgdG8NCj4+Pj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhl ciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZQ0KPj4gSVBSDQo+Pj4+Pj4+Pj4+ IHBvbGwuDQo+Pj4+Pj4+Pj4+IFdlIGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy4NCj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0 byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPj4+Pj4+Pj4+PiBjby1hdXRob3IuDQo+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPj4+Pj4+ Pj4+PiAtLQ0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IExvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQo+Pj4+Pj4+Pj4gbG9hLmFuZGVyc3Nv bkBlcmljc3Nvbi5jb20NCj4+Pj4+Pj4+Pj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5h Z2VyICAgICAgICAgICAgbG9hQHBpLm51DQo+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAg ICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCj4+Pj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+ Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gbXBscyBt YWlsaW5nIGxpc3QNCj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBU aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lcg0KPj4gQ2FibGUNCj4+Pj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yDQo+PiBzdWJqZWN0IHRvDQo+Pj4+PiBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZA0KPj4gc29sZWx5IGZvcg0KPj4+IHRoZQ0KPj4+Pj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPj4gYXJlIG5vdCB0aGUN Cj4+Pj4+IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdA0KPj4gYW55DQo+Pj4gZGlzc2VtaW5hdGlvbiwNCj4+Pj4+IGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50 cw0KPj4gb2YgYW5kDQo+Pj4+PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUNCj4+IHVubGF3ZnVsLiBJZiB5b3UNCj4+Pj4+IGhhdmUg cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K Pj4gaW1tZWRpYXRlbHkgYW5kDQo+Pj4+PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQNCj4+IGFueSBwcmludG91dC4NCj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g bXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCg== From lucy.yong@huawei.com Thu Dec 20 08:55:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36D21F88C5 for ; Thu, 20 Dec 2012 08:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-2.471, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttGyTI-+e-xc for ; Thu, 20 Dec 2012 08:55:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93C7D21F8770 for ; Thu, 20 Dec 2012 08:55:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOA36644; Thu, 20 Dec 2012 16:55:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 16:55:15 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 16:55:28 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 08:55:26 -0800 From: Lucy yong To: Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiaAqA//99ORA= Date: Thu, 20 Dec 2012 16:55:24 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com> In-Reply-To: <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.202] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 16:55:47 -0000 TmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGlzIGRpc2N1c3NlZCB1bmRlciBudm8zIFdH LiBUaGlzIGRvZXMgbm90IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJv dG9jb2wgZm9yIGEgdW5kZXJseWluZyBuZXR3b3JrIG9yIGEgbmV3IHByb3RvY29sIGZvciBhIG92 ZXJsYXkgbmV0d29yay4gSW4gZmFjdCwgcGVvcGxlIHRoZXJlIGFpbSBvbiBsZXZlcmFnZSBzdGFu ZGFyZCBuZXR3b3JrIHByb3RvY29scyB0byBhY2NvbXBsaXNoIHRoZW0uIElNTzogdGhlc2UgZXhw YW5zaW9ucyBvbiBhbiBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtl ZCBvdXQgaW4gdGhlIHByb3RvY29sIFdHIGdyb3VwLCBpdCBzaG91bGQgbm90IGdpdmUgbnZvMyBX RyBmcmVlIHJpZ2h0IHRvIGVuaGFuY2UgdGhlc2UgcHJvdG9jb2xzLiBGb3IgYSBicmFuZCBuZXcg cHJvdG9jb2wgZm9yIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSwgbnZvMyBXRyBtYXkg YmUgdGhlIHBsYWNlIHRvIHN0YXJ0Lg0KDQpMdWN5ICANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBTaGFocmFtIERhdmFyaSBbbWFpbHRvOmRhdmFyaUBicm9hZGNvbS5j b21dDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiAxMDozNCBBTQ0KPiBUbzog THVjeSB5b25nDQo+IENjOiBTaGFuZSBBbWFudGU7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnOyBtcGxzQGlldGYub3JnOw0KPiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVy bHlpbmcgbmV0d29yaw0KPiANCj4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IG11c3Qg YmUgZGlzY3Vzc2VkIGFuZCBjb25zZW50ZWQgIGluIE5WTzMNCj4gV0cuDQo+IA0KPiBSZWdhcmRz LA0KPiBTaGFocmFtDQo+IA0KPiANCj4gT24gRGVjIDIwLCAyMDEyLCBhdCA3OjM5IEFNLCAiTHVj eSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBIaSBTaGFuZSwN Cj4gPg0KPiA+IEkgdW5kZXJzdGFuZCBvcGVyYXRvciBjb25jZXJuIG9uIGEgbmV3IGVuY2Fwc3Vs YXRpb24gdG8gYW4gZXhpc3RpbmcNCj4gbmV0d29yay4NCj4gPg0KPiA+IEhvd2V2ZXIsIE1QTFMt aW4tVURQIGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9NUExTDQo+IG5l dHdvcmsgYXQgYWxsLg0KPiA+IE1QTFMtaW4tVURQIGlzIHRvIGVuYWJsZSBNUExTIGNsaWVudCBs YXllciB0byBiZSBkZWNvdXBsZWQgZnJvbSBNUExTDQo+IHNlcnZlciBsYXllciBhbmQgdXNlIE1Q TFMgY2xpZW50IGxheWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFzDQo+IGEgdW5k ZXJseWluZyBuZXR3b3JrIGZvciB0cmFuc3BvcnQuIFN1Y2ggYXBwbGljYXRpb24gaXMgZm9yIERD LiBZb3UgbWF5DQo+IGFyZ3VlIHdoeSBub3QgdXNlIHRoZSBHUkUgd2hpY2ggaXMgZm9yIE1QTFMg bGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJsaW5nDQo+IG5ldHdvcmsuIFdlIGhhdmUgcG9pbnRlZCBv dXQgaW4gdGhlIGRyYWZ0IHRoYXQgY3VycmVudCByb3V0ZXJzIGluIERDDQo+IGJhcmVseSBzdXBw b3J0IEdSRSBiYXNlZCBsb2FkIGJhbGFuY2luZyBhbmQgTVBMUy1pbi1HUkUgYXJlIGJhcmVseSB1 c2VkDQo+IGluIFNQIG5ldHdvcmtzIHRvby4gTW9zdCBvZiByb3V0ZXJzIGluIERDIHBlcmZvcm0g dXBkIHBvcnQgYmFzZWQgbG9hZA0KPiBiYWxhbmNpbmcgbm93Lg0KPiA+DQo+ID4gRnJvbSB0aGUg YXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQIGVuY2Fwc3VsYXRpb24gaGFzDQo+IGFk dmFudGFnZSBvdmVyIEdSRSBlbmNhcHN1bGF0aW9uIHRvby4gSW4gVURQIGVuY2Fwc3VsYXRpb24s IHRoZSBmcmFtZQ0KPiBoZWFkZXIgZGVjb3VwbGVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5n IG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRlcg0KPiBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVy LiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFkZXIsIHdoaWNoDQo+IHVuZGVybHlpbmcgbmV0d29y ayB1c2VzIG9ubHkuIEhvd2V2ZXIsIEdSRSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9yDQo+IHRo ZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5 LiBGb3IgbG9hZA0KPiBiYWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdv cmsgdXNlcyBHUkUgaGVhZGVyIHRvby4gSW4NCj4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5 IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5jZSBpdA0KPiBoYXMgbm90IHVz ZWQgYSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3Vj aA0KPiBjb3VwbGluZy4NCj4gPg0KPiA+IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0b3dhcmQgbmV0 d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGFuZA0KPiBkZWNvdXBsZXMgb3ZlcmxheSBuZXR3 b3JrcyBmcm9tIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsuIEEgY2xlYXINCj4gc2VwYXJhdGlvbiBv ZiBvdmVybGF5IGhlYWRlciBhbmQgdW5kZXJseWluZyBoZWFkZXIgaXMgYSAiTVVTVCIgaW4gbXkN Cj4gb3Bpbmlvbi4gSWYgd2UgY291bnQgR1JFIGFzIHRoZSBvdmVybGF5IGhlYWRlciwgdGhlbiBm b3IgSVB2NA0KPiB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUg ZmxvdyBlbnRyb3B5LiBUaGlzIGlzIHRoZQ0KPiByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVu Y2Fwc3VsYXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZw0KPiBuZXR3b3JrLiBJbiBm YWN0LCBpdCBjYW4gc3VwcG9ydCBhbnkgb3ZlcmxheSBuZXR3b3JrIGJlc2lkZSBNUExTIGNsaWVu dA0KPiBsYXllciAoZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAsIGV0YykuDQo+ID4NCj4gPiBZb3Ug cG9pbnQgb3V0IHVzaW5nIE1QTFMtaW4tTDJUUC1pbi1VRFAgaW5zdGVhZC4gWWVzLCBNUExTLWlu LUwyVFAtDQo+IGluLVVEUCBzY2hlbWEgYWxzbyBwcm92aWRlcyBhIG92ZXJsYXkgKEwyVFApIGFu ZCB1bmRlcmx5aW5nIChJUCkNCj4gbmV0d29yayBkZWNvdXBsaW5nLiBMMlRQIHByb3RvY29sIChy ZmMzOTMxKSBwcm92aWRlcyBnb29kIHNlY3VyaXR5DQo+IG1lY2hhbmlzbSBhbmQgaGFzIHRoZSBl bWJlZGRlZCBjb250cm9sIGZ1bmN0aW9uIHRvby4gVGhlcmVmb3JlLCBzb21lb25lDQo+IGNhbiB1 c2UgaXQgZm9yIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgSW50ZXJuZXQuIFRvIGhhdmUgTVBMUyBj bGllbnQNCj4gbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJsaW5nIG5ldHdvcmssIElNTzogTVBMUy1p bi1MMlRQLWluLVVEUCBpcyBhDQo+IG92ZXJraWxsIGFuZCB0b28gY29tcGxleC4gSGVyZSB3ZSBu ZWVkIGEgc2NoZW1hIHRvIHN1cHBvcnQgSUdQDQo+IHVuZGVybHlpbmcgdHJhbnNwb3J0IHdpdGhv dXQgdG91Y2hpbmcgYSBvdmVybGF5IGhlYWRlci4gVURQDQo+IGVuY2Fwc3VsYXRpb24gaXMgdGhl IGJlc3QgY2hvaWNlIHRvIGFjY29tcGxpc2ggdGhhdCBhbmQgbWluaW1pemUgdGhlDQo+IGNoYW5n ZXMgb24gZXhpc3Rpbmcgcm91dGVycywgZS5nLiBjaGFuZ2UgYXQgZWRnZSByb3V0ZXJzLCBubyBj aGFuZ2Ugb24NCj4gdHJhbnNpdCByb3V0ZXJzLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBMdWN5 DQo+ID4NCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPj4gU2VudDogVGh1 cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDQ6MTQgQU0NCj4gPj4gVG86IFNoYW5lIEFtYW50ZQ0K PiA+PiBDYzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi0N Cj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPiA+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBEaXNjdXNzaW9uIG9uIGhvdyB0byB0cmFuc3Bv cnQgTVBMUyBvdmVyIFVEUCB0dW5uZWxzDQo+ID4+DQo+ID4+IEhpIFNoYW5lLA0KPiA+Pg0KPiA+ PiBUaGFua3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXNw b25zZSBpbmxpbmUuDQo+ID4+DQo+ID4+IE5vdGU6IEkgY2hhbmdlZCB0aGUgc3ViamVjdCBsaW5l IGFjY29yZGluZyB0byBMb2EncyBzdWdnZXN0aW9uLg0KPiA+Pg0KPiA+Pj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+ID4+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBv aW50Lm5ldF0NCj4gPj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAyMjozOA0KPiA+Pj4gytW8 /sjLOiBYdXhpYW9odQ0KPiA+Pj4gs63LzTogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsg ZHJhZnQteHUtbXBscy1pbi0NCj4gPj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPiA+Pj4gbXBsc0Bp ZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+INb3zOI6IFJlOiBbbXBs c10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+ IG1wbHMtaW4tdWRwIGFuDQo+ID4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+ DQo+ID4+PiBYaWFvaHUsDQo+ID4+Pg0KPiA+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCAxMTo1MCBQ TSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ID4+Pj4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2Fz dGxlcG9pbnQubmV0XQ0KPiA+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMTE6NTgNCj4g Pj4+Pj4gytW8/sjLOiBSb2dlcnMsIEpvc2gNCj4gPj4+Pj4gs63LzTogU2hhaHJhbSBEYXZhcmk7 IFh1eGlhb2h1OyBkcmFmdC14dS1tcGxzLWluLQ0KPiA+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ ID4+Pj4+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4+Pj4+ INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2Ug ZHJhZnQteHUtDQo+ID4+IG1wbHMtaW4tdWRwDQo+ID4+PiBhbg0KPiA+Pj4+PiBtcGxzIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gRGVjIDE4LCAy MDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIg0KPiA+PiA8am9zaC5yb2dlcnNAdHdjYWJs ZS5jb20+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0 aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+IHNvbHV0aW9uDQo+ID4+ Pj4+PiBhZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCj4gPj4+Pj4NCj4gPj4+Pj4g KzEuICBQbGVhc2UgZG8gbm90IGRlZmluZSB5ZXQgYW5vdGhlciBNUExTLW92ZXItSVAgZW5jYXBz dWxhdGlvbi4NCj4gPj4gVGhlDQo+ID4+PiBJRVRGDQo+ID4+Pj4+IGFscmVhZHkgc3RhbmRhcmRp emVkIE1QTFMgb3ZlciBHUkUuICBUaGUgSUVURiBoYXMgYWxzbw0KPiA+PiBzdGFuZGFyZGl6ZWQN Cj4gPj4+IE1QTFMNCj4gPj4+Pj4gb3ZlciBMMlRQdjMvVURQL0lQLCB3aGljaCBoYWQgc2VlbiBz b21lIGRlcGxveW1lbnQgaW4gYXQgbGVhc3QNCj4gb25lLA0KPiA+PiB2ZXJ5DQo+ID4+Pj4+IGxh cmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFn ZSBvZg0KPiA+PiBMM1ZQTiBvdmVyDQo+ID4+PiBhbg0KPiA+Pj4+PiBJUC1vbmx5IG5ldHdvcmsu DQo+ID4+Pj4NCj4gPj4+PiBIaSBTaGFuZSwNCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rIHlvdSBmb3Ig dGVsbGluZyB1cyB0aGVyZSBhcmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3Zlcg0KPiA+ PiBJUCBpbiBhdA0KPiA+Pj4gbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsu IFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkNCj4gPj4gdmFsdWFibGUgdG8gdGhvc2UNCj4gPj4+IHBl b3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1QTFMgb3Zl ciBJUCBpbg0KPiA+PiB0b2RheSdzIFNQDQo+ID4+PiBuZXR3b3Jrcy4NCj4gPj4+Pg0KPiA+Pj4+ PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMN Cj4gPj4+Pj4gW05PVEU6IHRoZSBkYXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJh Y2sgaW4gdGhlIDIwMDYNCj4gPj4+IHRpbWVmcmFtZSFdDQo+ID4+Pj4+ICAgIFJGQyA0NjY1IGZv ciByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBWUExTIHRoYXQgc2F5IHRoYXQgVlBMUw0KPiA+PiBt YXkgYmUNCj4gPj4+Pj4gY2FycmllZCBvdmVyIEwyVFB2Mw0KPiA+Pj4+PiAgICBBbmQsIGhlcmUn cyBldmlkZW5jZSBzaG93aW5nIHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMNCj4gPj4+IGlt cGxlbWVudGVkDQo+ID4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+ID4+DQo+IGh0dHA6Ly93 d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4u aHRtbA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBp bmZvcm1hdGlvbi4gQXMgbWVudGlvbmVkIGluDQo+ID4+IHRoaXMgZHJhZnQNCj4gPj4+IEFORCBv dGhlciBkcmFmdHMsIHRoZSBtZWNoYW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9u IG9uDQo+IHRoZQ0KPiA+PiBTZXNzaW9uDQo+ID4+PiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhl YWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzDQo+ID4+IGRlZmluZWQg aW4NCj4gPj4+IFtSRkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3Rpbmcg Y29yZSByb3V0ZXJzIHNvIGZhci4NCj4gPj4+DQo+ID4+PiBGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nl c3MsIGluIHRoZSByZWxhdGl2ZWx5IHJlY2VudCBwYXN0LCBpbg0KPiA+PiByZXF1ZXN0aW5nIGEg Y29yZQ0KPiA+Pj4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0 LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4+IGNhbGN1bGF0aW9ucyBpbg0KPiA+Pj4gX2V4aXN0aW5n XyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQgbXkN Cj4gPj4gbmV0d29yay4NCj4gPj4+IEZ1cnRoZXIsIEkgc3VzcGVjdCB0aGF0IG1vc3QgbGFyZ2Ug bmV0d29yayBvcGVyYXRvcnMgYXJlIHNhdnZ5DQo+IGZvbGtzDQo+ID4+IGFuZA0KPiA+Pj4gdW5k ZXJzdGFuZCB0aGUgaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxs LiAgQXMgYQ0KPiA+PiByZXN1bHQsIHRob3NlDQo+ID4+PiBzYW1lIG9wZXJhdG9ycyBrbm93IHdo YXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzDQo+ID4+IHJlZ2Fy ZC4NCj4gPj4+IFRodXMsIGl0IG1heSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3Nh cnkgdG8gY29udmluY2UgdGhlaXINCj4gPj4gSFcNCj4gPj4+IHN1cHBsaWVyKHMpIHRvIG1ha2Ug YXBwcm9wcmlhdGUgY2hhbmdlcyBpbiB0aGVpciBlcXVpcG1lbnQgdG8NCj4gYWNoaWV2ZQ0KPiA+ PiB0aGVpcg0KPiA+Pj4gYnVzaW5lc3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5v dCBldmVuIGJlIG5lY2Vzc2FyeSAuLi4NCj4gc2VlDQo+ID4+IGJlbG93Lg0KPiA+Pg0KPiA+PiBD b3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJvdmUgY2hh bmdlIGluDQo+ID4+IEVYSVNUSU5HIGhhcmR3YXJlIG9mIGFscmVhZHkgZGVwbG95ZWQgY29yZSBy b3V0ZXJzPw0KPiA+Pg0KPiA+Pj4+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91 dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mDQo+ID4+IGJhbGFuY2luZyBJUA0KPiA+Pj4gdHJh ZmZpYyBmbG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFj a2V0cy4NCj4gQnkNCj4gPj4gdXNpbmcgdGhlDQo+ID4+PiBNUExTLWluLVVEUCBlbmNhcHN1bGF0 aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmcNCj4gPj4gY2FwYWJpbGl0 eSBvZg0KPiA+Pj4gbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3 aXRob3V0IHJlcXVpcmluZyBhbnkNCj4gPj4gY2hhbmdlIHRvDQo+ID4+PiB0aGVtLiBUaGF0IGlz IHRoZSBtYWpvciBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gSWYgdGhp cyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbg0K PiA+PiBNUExTL0wyVFB2Mywgd2hpY2gNCj4gPj4+IHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3Qg cGxhY2U/DQo+ID4+DQo+ID4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHlvdSBwcmVm ZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLQ0KPiBVRFANCj4gPj4gaW5zdGVhZCBvZiBNUExT LWluLVVEUCwgcmlnaHQ/DQo+ID4+DQo+ID4+PiBJTUhPLCBhIGJldHRlciBwcm9wb3NhbCBtYXkg YmUgdG8gY29uc2lkZXIgYSBbbWlub3JdICg/KSBjaGFuZ2UgdG8NCj4gPj4gUkZDIDM5MzEsDQo+ ID4+PiB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1c2VkIGZvciBkYXRhIHBhY2tl dHMgKG5vdCBjb250cm9sDQo+ID4+IHBhY2tldHMpDQo+ID4+PiB0byB1c2UgYSB2YXJ5aW5nIHNl dCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwNCj4gYmFzZWQNCj4g Pj4gb24gYSBoYXNoDQo+ID4+PiBjYWxjdWxhdGlvbiwgdG8gYWNoaWV2ZSBiZXR0ZXIgbG9hZC1i YWxhbmNpbmcgb3ZlciBleGlzdGluZw0KPiBlcXVpcG1lbnQNCj4gPj4gaW4gYW4NCj4gPj4+IElQ LW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYmV0 dGVyIG9mZg0KPiA+PiBqdXN0IHVzaW5nDQo+ID4+PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNv b2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0bw0KPiA+PiBhc3NvY2lhdGUNCj4g Pj4+IGluY29taW5nIHBhY2tldHMgd2l0aCB0aGUgYXNzb2NpYXRlZCBMMlRQIENvbnRyb2wgQ2hh bm5lbC4gIEluIGZhY3QsDQo+ID4+IGl0J3Mgbm90DQo+ID4+PiBjbGVhciB0byBtZSB0aGF0IGV4 aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkgL2FscmVhZHkvIGRvIHRoaXMsDQo+ID4+IG1ha2lu ZyBhbnkNCj4gPj4+ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNz YXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+IGltcGxlbWVudGF0aW9ucy4NCj4gPj4+DQo+ ID4+PiBUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCj4gPj4+IDEpIEkgd291 bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcw0K PiA+PiBsaW1pdGVkIHRvIHRoZQ0KPiA+Pj4gImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBv ZiBleGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4g SGVjaywgaXQgbWF5IGV2ZW4gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBM MlRQdjMNCj4gPj4+IGltcGxlbWVudGF0aW9ucy4gIChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxk IG5lZWQgdG8gY29tbWVudCBvbg0KPiB0aGF0KS4NCj4gPj4NCj4gPj4gSU1ITywgbm8gbWF0dGVy IE1QTFMtaW4tTDJUUHYzLWluLVVEUCBvciBNUExTLWluLVVEUCwgIHRoZSBoYXJkd2FyZQ0KPiBv Zg0KPiA+PiBQRSByb3V0ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdyZXNzIFBF IHJvdXRlcnMgbmVlZCB0bw0KPiBmaWxsDQo+ID4+IGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhl IHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiA+Pg0KPiA+Pj4gMikgVGhlcmUg aXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBieSB1c2luZyAiU2Vzc2lv bg0KPiA+PiBJRCIgYW5kDQo+ID4+PiAiQ29va2llIiBmaWVsZHMgdG8gZW5zdXJlIHRoZSByZWNl aXZlZCBMMlRQdjMgcGFja2V0IGlzIGludGVuZGVkDQo+IGZvcg0KPiA+PiB0aGUNCj4gPj4+IGlk ZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToN Cj4gPj4+IC0tLXNuaXAtLS0NCj4gPj4+ICAgTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJh dGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzItYml0DQo+ID4+IFNlc3Npb24NCj4gPj4+ICAgSUQg aW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRlci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29r aWUNCj4gPj4+ICAgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0 aW9uYWwgY2hlY2sgdG8NCj4gZW5zdXJlDQo+ID4+PiAgIHRoYXQgYW4gYXJyaXZpbmcgcGFja2V0 IGlzIGludGVuZGVkIGZvciB0aGUgaWRlbnRpZmllZCBzZXNzaW9uLg0KPiA+Pj4gICBUaHVzLCB1 c2Ugb2YgYSBDb29raWUgd2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0KPiA+ PiBndWFyYW50ZWUNCj4gPj4+ICAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZv cm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCj4gPj4+ICAgU2Vzc2lvbiBJRCBpdHNlbGYgd2Fz IG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC4NCj4gPj4+IC0tLXNuaXAtLS0NCj4gPj4+IC4uLiBp biByZWdhcmQgdG8gdGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBrbm93IHRoZSBTZWN1cml0eSBBcmVh DQo+IGZvbGtzDQo+ID4+IGhhdmUsIGluIHRoZQ0KPiA+Pj4gcGFzdCwgaGFkIC9zdWJzdGFudGlh bC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXINCj4gSVANCj4gPj4g dHJhbnNwb3J0Lg0KPiA+Pj4gSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGluIFNl Y3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZg0KPiBSRkMNCj4gPj4gNDY2NS4NCj4gPj4+IChUaGVy ZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExT IGZvcg0KPiA+PiB0cmFuc3BvcnQpLg0KPiA+Pj4gV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2Vj dXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8NCj4gPj4gZGFpbHkgdHJhZmZp YyBvbg0KPiA+Pj4gdGhlIE1QTFMgV0cgbWFpbGluZyBsaXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVu dCB0aGlzIGNvbmNlcm4gd2lsbA0KPiA+PiBhcmlzZSBpZi93aGVuIHRoaXMNCj4gPj4+IGRyYWZ0 IGdvZXMgdG8gdGhlIElFU0cgLi4uDQo+ID4+DQo+ID4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3Jy ZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5jZSBvZg0KPiBNUExTLQ0KPiA+PiBp bi1MMlRQdjMtaW4tVURQIGlzIHRoYXQgaXQgaGFzIGFuIGFkZGVkIHNlY3VyaXR5IGZlYXR1cmUu IElmIHRoYXQNCj4gaXMNCj4gPj4gc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxhaW4gd2h5IE1Q TFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXINCj4gdGhhbg0KPiA+PiBNUExTLWluLUwyVFAg aW4gcHJhY3RpY2U/DQo+ID4+DQo+ID4+IEJlc3QgcmVnYXJkcywNCj4gPj4gWGlhb2h1DQo+ID4+ DQo+ID4+PiAzKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5 c3RlbXMgdGhhdA0KPiBpbXBsZW1lbnQNCj4gPj4gTDJUUCwgZm9yDQo+ID4+PiB0dW5uZWxpbmcg b2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJlIGluZHVzdHJ5IHRvDQo+ ID4+IHN1cHBvcnQNCj4gPj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIgcHJvZHVj dCBsaW5lcy4NCj4gPj4+DQo+ID4+PiAtc2hhbmUNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+ Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+IFhpYW9odQ0KPiA+Pj4+DQo+ID4+Pj4+IElmIHRoZXJl IHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92ZXIgSVAsIHRoZW4gY2xlYXJseSBpdA0KPiB3 b3VsZA0KPiA+PiBoYXZlDQo+ID4+PiBiZWVuDQo+ID4+Pj4+IG1vcmUgd2lkZWx5IGltcGxlbWVu dGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExTDQo+ID4+IG92ZXINCj4g Pj4+IEdSRSBvcg0KPiA+Pj4+PiBNUExTIG92ZXIgTDJUUHYzLiAgKFdoZXJlIHRoZXJlJ3MgYSB3 aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkNCj4gd291bGQNCj4gPj4gbm90ZQ0KPiA+Pj4gdGhhdA0K PiA+Pj4+PiB0aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBub3QgcGFuIG91dCB3YXMg dGhlcmUgYXJlDQo+IHNldmVyYWwsDQo+ID4+IHByYWN0aWNhbA0KPiA+Pj4+PiBvcGVyYXRpb25h bCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdvaW5nIHdpdGggbmF0aXZlIE1QTFMNCj4gPj4+Pj4g ZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+ ID4+Pj4+IC0gTVBMUyBGYXN0IFJlLVJvdXRlDQo+ID4+Pj4+IC0gTVBMUyBUcmFmZmljIEVuZ2lu ZWVyaW5nDQo+ID4+Pj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRl ZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nDQo+ID4+PiBhcmd1bWVudHMNCj4gPj4+Pj4gdG8gJ3Vw Z3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5n Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtc2hhbmUNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC1K b3NoDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE9uIDEyLzE4LzEyIDEyOjMxIEFNLCAi U2hhaHJhbSBEYXZhcmkiIDxkYXZhcmlAYnJvYWRjb20uY29tPg0KPiA+Pj4gd3JvdGU6DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4+IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQ IGlzIGxlZ2FjeSBhbmQgdGhlcmUNCj4gaXMNCj4gPj4gbm8gbmVlZA0KPiA+Pj4+Pj4+IHRvIGlt cHJvdmUgaXQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pj4+IFNoYWhy YW0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVjIDE3LCAyMDEyLCBhdCA4 OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiA+Pj4gd3JvdGU6DQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gU2hhaHJhbSwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhp cyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVANCj4gPj4g ZW5jYXBzdWxhdGlvbg0KPiA+Pj4+Pj4+PiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2FkLWJhbGFu Y2luZyBhcHBsaWNhYmlsaXR5IHNvIGZhciB0bw0KPiA+PiB0aG9zZQ0KPiA+Pj4+Pj4+PiBvcGVy YXRvcnMgd2hvIGhhcHBlbiB0byByZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9u DQo+ID4+IHRyYWZmaWMNCj4gPj4+Pj4+Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUg TVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4gYW5kDQo+ID4+PiBWWExBTg0KPiA+Pj4+ Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91 DQo+IGFic29sdXRlbHkNCj4gPj4gYmVsaWV2ZQ0KPiA+Pj4+Pj4+PiBpdCdzIG1lYW5pbmdsZXNz IG9mIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMNCj4gPj4gYWNyb3NzIElQ DQo+ID4+Pj4+Pj4+IG5ldHdvcmtzIGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyBy ZWxhdGVkIHRvIE1QTFMNCj4gb3Zlcg0KPiA+PiBJUA0KPiA+Pj4+Pj4+PiB0dW5uZWxpbmcgbWVj aGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLA0KPiBwbGVhc2UNCj4g Pj4gc2F5DQo+ID4+PiBzby4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQnkgdGhlIHdheSwgaXQg c2VlbXMgdGhpcw0KPiA+Pj4+Pj4+PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiA+PiBh cmNoaXZlL3dlYi9udm8zL2N1cnJlbnQvbXNnMDE4NjQuaHRtbCkgaXMNCj4gPj4+Pj4+Pj4ganVz dCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9sbG93aW5n DQo+ID4+IGFyZ3VtZW50DQo+ID4+Pj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJh c2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGENCj4gPj4gY2VudGVycykuIEkNCj4gPj4+Pj4+ Pj4gaGFkIHRob3VnaHQgeW91IHdvdWxkIHNwZWFrIHVwIGF0IHRoYXQgdGltZS4gU2FkbHksDQo+ ID4+IHN1cnByaXNpbmdseSBzaWxlbnQNCj4gPj4+Pj4+Pj4gdGlsbCBub3cuDQo+ID4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVy d2lzZS4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gWGlhb2h1DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4+Pj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPiC0+g0KPiA+PiCx7Q0K PiA+Pj4+PiBTLg0KPiA+Pj4+Pj4+Pj4gRGF2YXJpDQo+ID4+Pj4+Pj4+PiC3osvNyrG85DogMjAx MsTqMTLUwjE1yNUgMTM6MzQNCj4gPj4+Pj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+ Pj4+Pj4+Pj4gs63LzTogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNA aWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+Pj4+ Pj4+Pj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8g bWFrZQ0KPiA+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPj4+Pj4+Pj4+IG1w bHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEkgZG9u J3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbg0KPiA+ PiB0b2RheSdzDQo+ID4+Pj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4gPj4+Pj4+Pj4+IGFuZCBjb3Jl LCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQgaXRzIG9ubHkgcHJhY3RpY2FsDQo+ID4+IGFw cGxpY2F0aW9uDQo+ID4+Pj4+Pj4+PiBpbiBpbiBkYXRhDQo+ID4+Pj4+Pj4+PiBjZW50ZXIsIHdo aWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVyIHNvbHV0aW9ucyBzdWNoIGFzDQo+ID4+ IE5WR1JFDQo+ID4+PiBhbmQNCj4gPj4+Pj4+Pj4+IFZYTEFOLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8z IHNvbHV0aW9uDQo+ID4+IHNlbGVjdGlvbg0KPiA+Pj4+Pj4+Pj4gcHJvY2Vzcw0KPiA+Pj4+Pj4+ Pj4gYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFuZGVy c3NvbiA8bG9hQHBpLm51PiB3cm90ZToNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gV29ya2lu ZyBncm91cCwNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAi dHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWlu LXVkcC0wNiBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4g RHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0 aA0KPiA+PiBvbmUgd2Vlay4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzDQo+ID4+PiB3 b3JraW5nDQo+ID4+Pj4+Pj4+Pj4gZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzIGF0IGlldGYub3Jn KS4gUGxlYXNlIGdpdmUgYW4NCj4gPj4gdGVjaG5pY2FsDQo+ID4+Pj4+Pj4+Pj4gbW90aXZhdGlv biBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiA+PiB0 aGluayB0aGF0DQo+ID4+Pj4+Pj4+Pj4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRl ZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gPj4gZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KPiA+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQg LQ0KPiA+Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4N Cj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFz IHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cA0KPiA+PiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ Pj4+PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWltcyB0aGFu IHRob3NlDQo+ID4+IGFscmVhZHkNCj4gPj4+Pj4+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+PiBIb3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAodGhlIGRvY3VtZW50 IHRoYXQgd2UgdXNlZCBmb3INCj4gdGhlDQo+ID4+IElQUg0KPiA+Pj4+Pj4+Pj4+IHBvbGwpDQo+ ID4+Pj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0 aG9ycy4gTWFyc2hhbGwNCj4gPj4gaGFzDQo+ID4+Pj4+Pj4+Pj4gZGlzY29udGludWVkIGFsbCBp bnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZQ0KPiA+PiBhdXRob3IgdGVh bQ0KPiA+Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBn cm91cCBjaGFpcnMgaGFzDQo+ID4+IHRyaWVkIHRvDQo+ID4+Pj4+Pj4+Pj4gY29udGFjdCBNYXJz aGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uDQo+IHRoZQ0KPiA+ PiBJUFINCj4gPj4+Pj4+Pj4+PiBwb2xsLg0KPiA+Pj4+Pj4+Pj4+IFdlIGhhdmUgaGFkIG5vIHN1 Y2Nlc3MgaW4gdGhpcy4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAt MDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPiA+Pj4+Pj4+ Pj4+IGNvLWF1dGhvci4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IC9Mb2ENCj4gPj4+Pj4+ Pj4+PiAobXBscyB3ZyBjby1jaGFpcikNCj4gPj4+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAg ICAgICAgIGVtYWlsOg0KPiA+Pj4+Pj4+Pj4gbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NCj4g Pj4+Pj4+Pj4+PiBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBs b2FAcGkubnUNCj4gPj4+Pj4+Pj4+PiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAg ICAgIHBob25lOiArNDYgMTAgNzE3IDUyDQo+IDEzDQo+ID4+Pj4+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCj4gPj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+PiBtcGxzQGlldGYub3Jn DQo+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gbXBsc0BpZXRmLm9y Zw0KPiA+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4gPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0K PiA+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcg0KPiA+PiBDYWJsZQ0KPiA+Pj4+PiBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv cg0KPiA+PiBzdWJqZWN0IHRvDQo+ID4+Pj4+IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBX YXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkDQo+ID4+IHNvbGVseSBmb3INCj4g Pj4+IHRoZQ0KPiA+Pj4+PiB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91DQo+ID4+IGFyZSBub3QgdGhlDQo+ID4+Pj4+IGludGVu ZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhh dA0KPiA+PiBhbnkNCj4gPj4+IGRpc3NlbWluYXRpb24sDQo+ID4+Pj4+IGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZQ0KPiBjb250ZW50cw0K PiA+PiBvZiBhbmQNCj4gPj4+Pj4gYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlDQo+ID4+IHVubGF3ZnVsLiBJZiB5b3UNCj4gPj4+Pj4g aGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyDQo+ID4+IGltbWVkaWF0ZWx5IGFuZA0KPiA+Pj4+PiBwZXJtYW5lbnRseSBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQNCj4gPj4gYW55IHByaW50 b3V0Lg0KPiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBtcGxzQGlldGYub3Jn DQo+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From davari@broadcom.com Thu Dec 20 09:31:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1C021F8939 for ; Thu, 20 Dec 2012 09:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-1.808, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ7EwSPCDy-6 for ; Thu, 20 Dec 2012 09:31:17 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 12AA221F88E1 for ; Thu, 20 Dec 2012 09:31:17 -0800 (PST) Received: from [10.16.192.232] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 20 Dec 2012 09:26:25 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Thu, 20 Dec 2012 09:31:08 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 20 Dec 2012 09:30:56 -0800 From: "Shahram Davari" To: "Lucy yong" Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3s+/R6wH2496W026x2QpZjBKZ5gibhgA//+D0HA= Date: Thu, 20 Dec 2012 17:30:55 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CCD95CB39W15011315-01-01 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:31:18 -0000 UGxlYXNlIGRvbid0IG1peCB1cCB0aGluZ3MuIFRoZSBNUExTIHByb3RvY29sIGRlc2lnbiBJIGFn cmVlIG11c3QgYmUgZG9uZSBieSBNUExTIFdHLiBCdXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIg eW91ciBwcm9wb3NhbCBtZWV0cyB0aGUgbmV0d29yayB2aXJ0dWFsaXphdGlvbiByZXF1aXJlbWVu dHMuIA0KDQpUaGUgTlZPMyB0YXNrIGlzIHRvIGRvY3VtZW50IHRoZSBpc3N1ZXMsIHJlcXVpcmVt ZW50cyBhbmQgZnJhbWV3b3JrIGZvciBOdk8zLiBUaGVuIGlmIE1QTFMgb3ZlciBJUCBsb29rcyBs aWtlIGEgc3VpdGFibGUgc29sdXRpb24gdGhhdCBtZWV0cyB0aGUgcmVxdWlyZW1lbnRzIHN1Y2gg YXMgdGhlIHNjYWxlLCBtb2JpbGl0eSwgZXRjLCB0aGVuIHRoZXkgd2lsbCBhc2sgTVBMUyBXRyBm b3IgcHJvdG9jb2wgZGVzaWduLg0KDQpTbyBiZWZvcmUgcHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJ IHRoaW5rIHlvdSBzaG91bGQgdGFrZSBpdCB0byBOVk8zIFdHIGFuZCBjb252aW5jZSB0aGVtIHRo aXMgc29sdXRpb24gbWVldHMgdGhlaXIgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsuIA0KDQpX ZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0aW9ucyBmb3IgdGhl IHNhbWUgcHJvYmxlbSwgZG8gd2U/DQoNCi1TaGFocmFtDQoNCg0KDQpSZWdhcmRzLA0KU2hhaHJh bQ0KDQoNCk9uIERlYyAyMCwgMjAxMiwgYXQgODo1NiBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9u Z0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPiBOZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkg aXMgZGlzY3Vzc2VkIHVuZGVyIG52bzMgV0cuIFRoaXMgZG9lcyBub3QgbWVhbiB0aGF0IG52bzMg V0cgaGFzIHRvIGRlc2lnbiBhIG5ldyBwcm90b2NvbCBmb3IgYSB1bmRlcmx5aW5nIG5ldHdvcmsg b3IgYSBuZXcgcHJvdG9jb2wgZm9yIGEgb3ZlcmxheSBuZXR3b3JrLiBJbiBmYWN0LCBwZW9wbGUg dGhlcmUgYWltIG9uIGxldmVyYWdlIHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29t cGxpc2ggdGhlbS4gSU1POiB0aGVzZSBleHBhbnNpb25zIG9uIGFuIGV4aXN0aW5nIHN0YW5kYXJk IHByb3RvY29sIGhhdmUgdG8gYmUgd29ya2VkIG91dCBpbiB0aGUgcHJvdG9jb2wgV0cgZ3JvdXAs IGl0IHNob3VsZCBub3QgZ2l2ZSBudm8zIFdHIGZyZWUgcmlnaHQgdG8gZW5oYW5jZSB0aGVzZSBw cm90b2NvbHMuIEZvciBhIGJyYW5kIG5ldyBwcm90b2NvbCBmb3IgbmV0d29yayB2aXJ0dWFsaXph dGlvbiBvdmVybGF5LCBudm8zIFdHIG1heSBiZSB0aGUgcGxhY2UgdG8gc3RhcnQuDQo+IA0KPiBM dWN5ICANCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogU2hhaHJh bSBEYXZhcmkgW21haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tXQ0KPj4gU2VudDogVGh1cnNkYXks IERlY2VtYmVyIDIwLCAyMDEyIDEwOjM0IEFNDQo+PiBUbzogTHVjeSB5b25nDQo+PiBDYzogU2hh bmUgQW1hbnRlOyBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRm Lm9yZzsNCj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW21w bHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KPj4g DQo+PiBOZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgbXVzdCBiZSBkaXNjdXNzZWQgYW5k IGNvbnNlbnRlZCAgaW4gTlZPMw0KPj4gV0cuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBTaGFocmFt DQo+PiANCj4+IA0KPj4gT24gRGVjIDIwLCAyMDEyLCBhdCA3OjM5IEFNLCAiTHVjeSB5b25nIiA8 bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+Pj4gSGkgU2hhbmUsDQo+Pj4gDQo+ Pj4gSSB1bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBzdWxhdGlvbiB0 byBhbiBleGlzdGluZw0KPj4gbmV0d29yay4NCj4+PiANCj4+PiBIb3dldmVyLCBNUExTLWluLVVE UCBkb2VzIG5vdCBhaW0gb24gY2hhbmdpbmcgZXhpc3RpbmcgU1AgSVAvTVBMUw0KPj4gbmV0d29y ayBhdCBhbGwuDQo+Pj4gTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVy IHRvIGJlIGRlY291cGxlZCBmcm9tIE1QTFMNCj4+IHNlcnZlciBsYXllciBhbmQgdXNlIE1QTFMg Y2xpZW50IGxheWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFzDQo+PiBhIHVuZGVy bHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBTdWNoIGFwcGxpY2F0aW9uIGlzIGZvciBEQy4g WW91IG1heQ0KPj4gYXJndWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBMUyBs YXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcNCj4+IG5ldHdvcmsuIFdlIGhhdmUgcG9pbnRlZCBv dXQgaW4gdGhlIGRyYWZ0IHRoYXQgY3VycmVudCByb3V0ZXJzIGluIERDDQo+PiBiYXJlbHkgc3Vw cG9ydCBHUkUgYmFzZWQgbG9hZCBiYWxhbmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkg dXNlZA0KPj4gaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRlcnMgaW4gREMgcGVyZm9y bSB1cGQgcG9ydCBiYXNlZCBsb2FkDQo+PiBiYWxhbmNpbmcgbm93Lg0KPj4+IA0KPj4+IEZyb20g dGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhlIFVEUCBlbmNhcHN1bGF0aW9uIGhhcw0K Pj4gYWR2YW50YWdlIG92ZXIgR1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5jYXBzdWxh dGlvbiwgdGhlIGZyYW1lDQo+PiBoZWFkZXIgZGVjb3VwbGVzIHRoZSBvdmVybGF5IGFuZCB1bmRl cmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRlcg0KPj4gaGVhZGVyIGFuZCBvdmVybGF5 IGhlYWRlci4gVURQIGJlbG9uZ3MgdG8gb3V0ZXIgaGVhZGVyLCB3aGljaA0KPj4gdW5kZXJseWlu ZyBuZXR3b3JrIHVzZXMgb25seS4gSG93ZXZlciwgR1JFIGhlYWRlciBoYXMgdGhlIGZpZWxkcyBm b3INCj4+IHRoZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxv dyBlbnRyb3B5LiBGb3IgbG9hZA0KPj4gYmFsYW5jaW5nLCBpdCByZXF1aXJlcyB0aGUgdW5kZXJs eWluZyBuZXR3b3JrIHVzZXMgR1JFIGhlYWRlciB0b28uIEluDQo+PiBzaG9ydCwgR1JFIHRpZXMg dGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29ya3MgdG9nZXRoZXIuIFNpbmNlIGl0DQo+ PiBoYXMgbm90IHVzZWQgYSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZh bnRhZ2Ugb2Ygc3VjaA0KPj4gY291cGxpbmcuDQo+Pj4gDQo+Pj4gQXMgdGhlIGluZHVzdHJ5IG1v dmVzIHRvd2FyZCBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgYW5kDQo+PiBkZWNvdXBs ZXMgb3ZlcmxheSBuZXR3b3JrcyBmcm9tIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsuIEEgY2xlYXIN Cj4+IHNlcGFyYXRpb24gb2Ygb3ZlcmxheSBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlz IGEgIk1VU1QiIGluIG15DQo+PiBvcGluaW9uLiBJZiB3ZSBjb3VudCBHUkUgYXMgdGhlIG92ZXJs YXkgaGVhZGVyLCB0aGVuIGZvciBJUHY0DQo+PiB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlz IG5vIGZpZWxkIGZvciB0aGUgZmxvdyBlbnRyb3B5LiBUaGlzIGlzIHRoZQ0KPj4gcmVhc29uIHdl IHByb3Bvc2UgdGhlIFVEUCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVybHlp bmcNCj4+IG5ldHdvcmsuIEluIGZhY3QsIGl0IGNhbiBzdXBwb3J0IGFueSBvdmVybGF5IG5ldHdv cmsgYmVzaWRlIE1QTFMgY2xpZW50DQo+PiBsYXllciAoZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAs IGV0YykuDQo+Pj4gDQo+Pj4gWW91IHBvaW50IG91dCB1c2luZyBNUExTLWluLUwyVFAtaW4tVURQ IGluc3RlYWQuIFllcywgTVBMUy1pbi1MMlRQLQ0KPj4gaW4tVURQIHNjaGVtYSBhbHNvIHByb3Zp ZGVzIGEgb3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKQ0KPj4gbmV0d29yayBkZWNv dXBsaW5nLiBMMlRQIHByb3RvY29sIChyZmMzOTMxKSBwcm92aWRlcyBnb29kIHNlY3VyaXR5DQo+ PiBtZWNoYW5pc20gYW5kIGhhcyB0aGUgZW1iZWRkZWQgY29udHJvbCBmdW5jdGlvbiB0b28uIFRo ZXJlZm9yZSwgc29tZW9uZQ0KPj4gY2FuIHVzZSBpdCBmb3IgTVBMUyBjbGllbnQgbGF5ZXIgb3Zl ciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudA0KPj4gbGF5ZXIgb3ZlciBhbiBJR1AgdW5k ZXJsaW5nIG5ldHdvcmssIElNTzogTVBMUy1pbi1MMlRQLWluLVVEUCBpcyBhDQo+PiBvdmVya2ls bCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZCBhIHNjaGVtYSB0byBzdXBwb3J0IElHUA0K Pj4gdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0aG91dCB0b3VjaGluZyBhIG92ZXJsYXkgaGVhZGVy LiBVRFANCj4+IGVuY2Fwc3VsYXRpb24gaXMgdGhlIGJlc3QgY2hvaWNlIHRvIGFjY29tcGxpc2gg dGhhdCBhbmQgbWluaW1pemUgdGhlDQo+PiBjaGFuZ2VzIG9uIGV4aXN0aW5nIHJvdXRlcnMsIGUu Zy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVycywgbm8gY2hhbmdlIG9uDQo+PiB0cmFuc2l0IHJvdXRl cnMuDQo+Pj4gDQo+Pj4gUmVnYXJkcywNCj4+PiBMdWN5DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFh1eGlhb2h1IFttYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4+Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAy MDEyIDQ6MTQgQU0NCj4+Pj4gVG86IFNoYW5lIEFtYW50ZQ0KPj4+PiBDYzogUm9nZXJzLCBKb3No OyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi0NCj4+IHVkcEB0b29scy5pZXRmLm9y ZzsNCj4+Pj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4g U3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cgdG8gdHJhbnNwb3J0IE1QTFMgb3ZlciBVRFAgdHVu bmVscw0KPj4+PiANCj4+Pj4gSGkgU2hhbmUsDQo+Pj4+IA0KPj4+PiBUaGFua3MgZm9yIHlvdXIg ZnVydGhlciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuDQo+Pj4+ IA0KPj4+PiBOb3RlOiBJIGNoYW5nZWQgdGhlIHN1YmplY3QgbGluZSBhY2NvcmRpbmcgdG8gTG9h J3Mgc3VnZ2VzdGlvbi4NCj4+Pj4gDQo+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+Pj4+ILei vP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0KPj4+Pj4g t6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDIyOjM4DQo+Pj4+PiDK1bz+yMs6IFh1eGlhb2h1DQo+ Pj4+PiCzrcvNOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFmdC14dS1tcGxzLWlu LQ0KPj4+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZw0KPj4+Pj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBp ZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS0NCj4+Pj4gbXBscy1pbi11ZHAgYW4N Cj4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPj4+Pj4gDQo+Pj4+PiBYaWFvaHUs DQo+Pj4+PiANCj4+Pj4+IE9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1IDx4 dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+ Pj4+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0N Cj4+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDExOjU4DQo+Pj4+Pj4+IMrVvP7Iyzog Um9nZXJzLCBKb3NoDQo+Pj4+Pj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJh ZnQteHUtbXBscy1pbi0NCj4+Pj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPj4+Pj4+PiBtcGxzQGll dGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPj4+Pj4+PiDW98ziOiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LQ0KPj4+ PiBtcGxzLWluLXVkcA0KPj4+Pj4gYW4NCj4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50DQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUw IEFNLCAiUm9nZXJzLCBKb3NoIg0KPj4+PiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+DQo+Pj4+ Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8g bm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+Pj4+IHNvbHV0aW9uDQo+Pj4+Pj4+PiBhZGRyZXNz ZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICsxLiAgUGxlYXNl IGRvIG5vdCBkZWZpbmUgeWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uDQo+ Pj4+IFRoZQ0KPj4+Pj4gSUVURg0KPj4+Pj4+PiBhbHJlYWR5IHN0YW5kYXJkaXplZCBNUExTIG92 ZXIgR1JFLiAgVGhlIElFVEYgaGFzIGFsc28NCj4+Pj4gc3RhbmRhcmRpemVkDQo+Pj4+PiBNUExT DQo+Pj4+Pj4+IG92ZXIgTDJUUHYzL1VEUC9JUCwgd2hpY2ggaGFkIHNlZW4gc29tZSBkZXBsb3lt ZW50IGluIGF0IGxlYXN0DQo+PiBvbmUsDQo+Pj4+IHZlcnkNCj4+Pj4+Pj4gbGFyZ2Ugb3BlcmF0 b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBvZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mDQo+Pj4+ IEwzVlBOIG92ZXINCj4+Pj4+IGFuDQo+Pj4+Pj4+IElQLW9ubHkgbmV0d29yay4NCj4+Pj4+PiAN Cj4+Pj4+PiBIaSBTaGFuZSwNCj4+Pj4+PiANCj4+Pj4+PiBUaGFuayB5b3UgZm9yIHRlbGxpbmcg dXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXINCj4+Pj4gSVAgaW4g YXQNCj4+Pj4+IGxlYXN0IG9uZSwgdmVyeSBsYXJnZSBvcGVyYXRvciBuZXR3b3JrLiBUaGlzIGZh Y3QgbXVzdCBiZSB2ZXJ5DQo+Pj4+IHZhbHVhYmxlIHRvIHRob3NlDQo+Pj4+PiBwZW9wbGUgd2hv IGhhZCBiZWxpZXZlZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlvbiBvZiBNUExTIG92ZXIgSVAgaW4N Cj4+Pj4gdG9kYXkncyBTUA0KPj4+Pj4gbmV0d29ya3MuDQo+Pj4+Pj4gDQo+Pj4+Pj4+IFNlZTog UkZDJ3MgNDQ1NCwgNDcxOSwgNDU5MSwgNDM0OSBmb3IgUFdFMyBvdmVyIEwyVFB2Mw0KPj4+Pj4+ PiBbTk9URTogdGhlIGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0 aGUgMjAwNg0KPj4+Pj4gdGltZWZyYW1lIV0NCj4+Pj4+Pj4gICBSRkMgNDY2NSBmb3IgcmVxdWly ZW1lbnRzIHJlbGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4+Pj4gbWF5IGJlDQo+ Pj4+Pj4+IGNhcnJpZWQgb3ZlciBMMlRQdjMNCj4+Pj4+Pj4gICBBbmQsIGhlcmUncyBldmlkZW5j ZSBzaG93aW5nIHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMNCj4+Pj4+IGltcGxlbWVudGVk DQo+Pj4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+PiBodHRwOi8vd3d3LmNpc2NvLmNvbS9l bi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJlL2d1aWRlL2NzZ2wzdnBuLmh0bWwNCj4+Pj4+PiAN Cj4+Pj4+PiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0aW9uLiBB cyBtZW50aW9uZWQgaW4NCj4+Pj4gdGhpcyBkcmFmdA0KPj4+Pj4gQU5EIG90aGVyIGRyYWZ0cywg dGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb24gb24NCj4+IHRoZQ0K Pj4+PiBTZXNzaW9uDQo+Pj4+PiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUg S2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzDQo+Pj4+IGRlZmluZWQgaW4NCj4+Pj4+IFtS RkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJz IHNvIGZhci4NCj4+Pj4+IA0KPj4+Pj4gRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUg cmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4NCj4+Pj4gcmVxdWVzdGluZyBhIGNvcmUNCj4+Pj4+ IHJvdXRlciB2ZW5kb3IgdG8gc3VwcG9ydCBjaGFuZ2VzIHRvIHRoZSBpbnB1dC1rZXlzIHVzZWQg aW4gaGFzaA0KPj4+PiBjYWxjdWxhdGlvbnMgaW4NCj4+Pj4+IF9leGlzdGluZ18gaGFyZHdhcmUs IGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15DQo+Pj4+IG5ldHdv cmsuDQo+Pj4+PiBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3Bl cmF0b3JzIGFyZSBzYXZ2eQ0KPj4gZm9sa3MNCj4+Pj4gYW5kDQo+Pj4+PiB1bmRlcnN0YW5kIHRo ZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuICBBcyBhDQo+ Pj4+IHJlc3VsdCwgdGhvc2UNCj4+Pj4+IHNhbWUgb3BlcmF0b3JzIGtub3cgd2hhdCBpcyBhbmQg aXMgbm90IHRlY2huaWNhbGx5IHBvc3NpYmxlIGluIHRoaXMNCj4+Pj4gcmVnYXJkLg0KPj4+Pj4g VGh1cywgaXQgbWF5IGJlIGEgcXVlc3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252 aW5jZSB0aGVpcg0KPj4+PiBIVw0KPj4+Pj4gc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0 ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0bw0KPj4gYWNoaWV2ZQ0KPj4+PiB0aGVpcg0K Pj4+Pj4gYnVzaW5lc3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJl IG5lY2Vzc2FyeSAuLi4NCj4+IHNlZQ0KPj4+PiBiZWxvdy4NCj4+Pj4gDQo+Pj4+IENvdWxkIHlv dSBwbGVhc2UgYnJpZWZseSBleHBsYWluIGhvdyB0byBtYWtlIHRoZSBhYm92ZSBjaGFuZ2UgaW4N Cj4+Pj4gRVhJU1RJTkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/ DQo+Pj4+IA0KPj4+Pj4+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBh cmUgYWxyZWFkeSBjYXBhYmxlIG9mDQo+Pj4+IGJhbGFuY2luZyBJUA0KPj4+Pj4gdHJhZmZpYyBm bG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFja2V0cy4N Cj4+IEJ5DQo+Pj4+IHVzaW5nIHRoZQ0KPj4+Pj4gTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiwg dGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nDQo+Pj4+IGNhcGFiaWxpdHkgb2YN Cj4+Pj4+IG1vc3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIGNhbiBiZSBsZXZlcmFnZWQgd2l0aG91 dCByZXF1aXJpbmcgYW55DQo+Pj4+IGNoYW5nZSB0bw0KPj4+Pj4gdGhlbS4gVGhhdCBpcyB0aGUg bWFqb3IgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPj4+Pj4gDQo+Pj4+PiBJZiB0aGlzIGlz IGEgY29uY2VybiwgdGhlbiB3aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFmZmljIGluDQo+Pj4+ IE1QTFMvTDJUUHYzLCB3aGljaA0KPj4+Pj4gdXNlcyBVRFAvSVAsIGluIHRoZSBmaXJzdCBwbGFj ZT8NCj4+Pj4gDQo+Pj4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHlvdSBwcmVmZXIg dG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLQ0KPj4gVURQDQo+Pj4+IGluc3RlYWQgb2YgTVBMUy1p bi1VRFAsIHJpZ2h0Pw0KPj4+PiANCj4+Pj4+IElNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBi ZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0KPj4+PiBSRkMgMzkzMSwNCj4+ Pj4+IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBjb25uZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFja2V0 cyAobm90IGNvbnRyb2wNCj4+Pj4gcGFja2V0cykNCj4+Pj4+IHRvIHVzZSBhIHZhcnlpbmcgc2V0 IG9mIHNvdXJjZSBwb3J0cyAob3IsIHNvdXJjZSBJUCBhZGRyZXNzZXMpLA0KPj4gYmFzZWQNCj4+ Pj4gb24gYSBoYXNoDQo+Pj4+PiBjYWxjdWxhdGlvbiwgdG8gYWNoaWV2ZSBiZXR0ZXIgbG9hZC1i YWxhbmNpbmcgb3ZlciBleGlzdGluZw0KPj4gZXF1aXBtZW50DQo+Pj4+IGluIGFuDQo+Pj4+PiBJ UC1vbmx5IGNvcmUuICBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJl dHRlciBvZmYNCj4+Pj4ganVzdCB1c2luZw0KPj4+Pj4gdGhlICJTZXNzaW9uIElEIiAoYW5kICJD b29raWUiKSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlwbGV4b3IgdG8NCj4+Pj4gYXNzb2NpYXRlDQo+ Pj4+PiBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9sIENo YW5uZWwuICBJbiBmYWN0LA0KPj4+PiBpdCdzIG5vdA0KPj4+Pj4gY2xlYXIgdG8gbWUgdGhhdCBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLA0KPj4+PiBtYWtp bmcgYW55DQo+Pj4+PiAiY2hlY2siIG9uIHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vz c2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtDQo+Pj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4+PiAN Cj4+Pj4+IFRoZSBiZWF1dHkgb2YgdGhlIGFib3ZlIGFwcHJvYWNoIGlzOg0KPj4+Pj4gMSkgSSB3 b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBhIGNoYW5nZSB0aGF0IGlz DQo+Pj4+IGxpbWl0ZWQgdG8gdGhlDQo+Pj4+PiAiY29udHJvbCBjaGFubmVsIiAoc29mdHdhcmUp IG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbQ0KPj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4+ PiBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5n IEwyVFB2Mw0KPj4+Pj4gaW1wbGVtZW50YXRpb25zLiAgKEwyVFB2MyBpbXBsZW1lbnRvcnMgd291 bGQgbmVlZCB0byBjb21tZW50IG9uDQo+PiB0aGF0KS4NCj4+Pj4gDQo+Pj4+IElNSE8sIG5vIG1h dHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsICB0aGUgaGFyZHdhcmUN Cj4+IG9mDQo+Pj4+IFBFIHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUuZy4sIGluZ3Jl c3MgUEUgcm91dGVycyBuZWVkIHRvDQo+PiBmaWxsDQo+Pj4+IGluIGFuIGVudHJvcHkgdmFsdWUg aW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPj4+PiANCj4+Pj4+IDIp IFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdldHMgYnkgdXNpbmcg IlNlc3Npb24NCj4+Pj4gSUQiIGFuZA0KPj4+Pj4gIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0 aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZA0KPj4gZm9yDQo+Pj4+IHRoZQ0K Pj4+Pj4gaWRlbnRpZmllZCBzZXNzaW9uLiAgUXVvdGluZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJG QyAzOTMxOg0KPj4+Pj4gLS0tc25pcC0tLQ0KPj4+Pj4gIEwyVFB2MyBwcm92aWRlcyB0cmFmZmlj IHNlcGFyYXRpb24gZm9yIGl0cyBWUE5zIHZpYSBhIDMyLWJpdA0KPj4+PiBTZXNzaW9uDQo+Pj4+ PiAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRlci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2 MyBDb29raWUNCj4+Pj4+ICAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xKSwgcHJvdmlkZXMgYW4g YWRkaXRpb25hbCBjaGVjayB0bw0KPj4gZW5zdXJlDQo+Pj4+PiAgdGhhdCBhbiBhcnJpdmluZyBw YWNrZXQgaXMgaW50ZW5kZWQgZm9yIHRoZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+Pj4+PiAgVGh1 cywgdXNlIG9mIGEgQ29va2llIHdpdGggdGhlIFNlc3Npb24gSUQgcHJvdmlkZXMgYW4gZXh0cmEN Cj4+Pj4gZ3VhcmFudGVlDQo+Pj4+PiAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBl cmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCj4+Pj4+ICBTZXNzaW9uIElEIGl0c2VsZiB3 YXMgbm90IGNvcnJ1cHRlZCBpbiB0cmFuc2l0Lg0KPj4+Pj4gLS0tc25pcC0tLQ0KPj4+Pj4gLi4u IGluIHJlZ2FyZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFy ZWENCj4+IGZvbGtzDQo+Pj4+IGhhdmUsIGluIHRoZQ0KPj4+Pj4gcGFzdCwgaGFkIC9zdWJzdGFu dGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXINCj4+IElQDQo+ Pj4+IHRyYW5zcG9ydC4NCj4+Pj4+IEluIGZhY3QsIHRoaXMgaXMgd2h5IHlvdSBzZWUgdGV4dCBp biBTZWN0aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YNCj4+IFJGQw0KPj4+PiA0NjY1Lg0KPj4+Pj4g KFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdXNl IE1QTFMgZm9yDQo+Pj4+IHRyYW5zcG9ydCkuDQo+Pj4+PiBXaGlsZSBJJ20gbm90IHN1cmUgdGhh dCBTZWN1cml0eSBBcmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0KPj4+PiBkYWlseSB0 cmFmZmljIG9uDQo+Pj4+PiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29u ZmlkZW50IHRoaXMgY29uY2VybiB3aWxsDQo+Pj4+IGFyaXNlIGlmL3doZW4gdGhpcw0KPj4+Pj4g ZHJhZnQgZ29lcyB0byB0aGUgSUVTRyAuLi4NCj4+Pj4gDQo+Pj4+IElmIEkgdW5kZXJzdGFuZCBp dCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5jZSBvZg0KPj4gTVBMUy0N Cj4+Pj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0eSBm ZWF0dXJlLiBJZiB0aGF0DQo+PiBpcw0KPj4+PiBzbyBjb25jZXJuZWQsIGNhbiB5b3UgZXhwbGFp biB3aHkgTVBMUy1pbi1HUkUgaXMgZmFyIG1vcmUgcG9wdWxhcg0KPj4gdGhhbg0KPj4+PiBNUExT LWluLUwyVFAgaW4gcHJhY3RpY2U/DQo+Pj4+IA0KPj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+IFhp YW9odQ0KPj4+PiANCj4+Pj4+IDMpIEZpbmFsbHksIHRoaXMgYXBwcm9hY2ggb25seSBhZmZlY3Rz IHRoZSBlbmQtc3lzdGVtcyB0aGF0DQo+PiBpbXBsZW1lbnQNCj4+Pj4gTDJUUCwgZm9yDQo+Pj4+ PiB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJlIGlu ZHVzdHJ5IHRvDQo+Pj4+IHN1cHBvcnQNCj4+Pj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4g dGhlaXIgcHJvZHVjdCBsaW5lcy4NCj4+Pj4+IA0KPj4+Pj4gLXNoYW5lDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4+IA0KPj4+Pj4+IEJlc3QgcmVnYXJkcywNCj4+Pj4+PiBYaWFvaHUNCj4+Pj4+PiAN Cj4+Pj4+Pj4gSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3ZlciBJUCwgdGhl biBjbGVhcmx5IGl0DQo+PiB3b3VsZA0KPj4+PiBoYXZlDQo+Pj4+PiBiZWVuDQo+Pj4+Pj4+IG1v cmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBN UExTDQo+Pj4+IG92ZXINCj4+Pj4+IEdSRSBvcg0KPj4+Pj4+PiBNUExTIG92ZXIgTDJUUHYzLiAg KFdoZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkNCj4+IHdvdWxkDQo+Pj4+ IG5vdGUNCj4+Pj4+IHRoYXQNCj4+Pj4+Pj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBk aWQgbm90IHBhbiBvdXQgd2FzIHRoZXJlIGFyZQ0KPj4gc2V2ZXJhbCwNCj4+Pj4gcHJhY3RpY2Fs DQo+Pj4+Pj4+IG9wZXJhdGlvbmFsIGJlbmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBu YXRpdmUgTVBMUw0KPj4+Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4gdGhlIGRh dGEgcGxhbmUsIG5hbWVseToNCj4+Pj4+Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4+Pj4+Pj4g LSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+Pj4+Pj4gLi4uIHRvIG5hbWUsIGJ1dCBhIGZl dy4gIFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxpbmcNCj4+Pj4+IGFyZ3Vt ZW50cw0KPj4+Pj4+PiB0byAndXBncmFkZScgbmV0d29yayBIVyB0byBzdXBwb3J0IE1QTFMgZW5j YXBzdWxhdGlvbi9zd2l0Y2hpbmcuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAtc2hhbmUNCj4+Pj4+Pj4g DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLUpvc2gNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2FkY29t LmNvbT4NCj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gRm9yIHNlcnZpY2UgcHJv dmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0aGVyZQ0KPj4gaXMNCj4+ Pj4gbm8gbmVlZA0KPj4+Pj4+Pj4+IHRvIGltcHJvdmUgaXQuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gUmVnYXJkcywNCj4+Pj4+Pj4+PiBTaGFocmFtDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDEyLCBhdCA4OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9o dUBodWF3ZWkuY29tPg0KPj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFNoYWhy YW0sDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQg dG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUA0KPj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+ IG1ldGhvZCB3aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFy IHRvDQo+Pj4+IHRob3NlDQo+Pj4+Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVp cmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24NCj4+Pj4gdHJhZmZpYw0KPj4+Pj4+Pj4+ PiBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQLCBO VkdSRQ0KPj4gYW5kDQo+Pj4+PiBWWExBTg0KPj4+Pj4+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3du IGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91DQo+PiBhYnNvbHV0ZWx5DQo+Pj4+IGJl bGlldmUNCj4+Pj4+Pj4+Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBh cHBsaWNhdGlvbiB0cmFmZmljDQo+Pj4+IGFjcm9zcyBJUA0KPj4+Pj4+Pj4+PiBuZXR3b3JrcyBh bmQgdGhlcmVmb3JlIHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBNUExTDQo+PiBvdmVy DQo+Pj4+IElQDQo+Pj4+Pj4+Pj4+IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3Zl ZCB0byBIaXN0b3JpYyBzdGF0dXMsDQo+PiBwbGVhc2UNCj4+Pj4gc2F5DQo+Pj4+PiBzby4NCj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+Pj4+ Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4+Pj4gYXJjaGl2ZS93ZWIvbnZvMy9jdXJy ZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+Pj4+Pj4+Pj4+IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBz dWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZw0KPj4+PiBhcmd1bWVudA0KPj4+ Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJs ZSB0byBkYXRhDQo+Pj4+IGNlbnRlcnMpLiBJDQo+Pj4+Pj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3 b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LA0KPj4+PiBzdXJwcmlzaW5nbHkgc2ls ZW50DQo+Pj4+Pj4+Pj4+IHRpbGwgbm93Lg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gU2lnaCwg SSBkaWRuJ3QgaW50ZW5kIHRvIHNheSB0aGUgYWJvdmUgb3RoZXJ3aXNlLg0KPj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4gWGlhb2h1DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+Pj4+Pj4+Pj4+PiC3orz+yMs6IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCj4+ILT6DQo+Pj4+ILHtDQo+Pj4+Pj4+IFMuDQo+Pj4+ Pj4+Pj4+PiBEYXZhcmkNCj4+Pj4+Pj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzoz NA0KPj4+Pj4+Pj4+Pj4gytW8/sjLOiBMb2EgQW5kZXJzc29uDQo+Pj4+Pj4+Pj4+PiCzrcvNOiBk cmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsNCj4+Pj4+ Pj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+Pj4+Pj4+Pj4+PiDW98ziOiBSZTog W21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+Pj4+Pj4+Pj4+ PiBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPj4+Pj4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50DQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlz IGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbg0KPj4+PiB0b2RheSdzDQo+Pj4+ Pj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4+Pj4+Pj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlz IGRvbWluYW50LCBhbmQgaXRzIG9ubHkgcHJhY3RpY2FsDQo+Pj4+IGFwcGxpY2F0aW9uDQo+Pj4+ Pj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMg Y3Jvd2RlZCB3aXRoIG90aGVyIHNvbHV0aW9ucyBzdWNoIGFzDQo+Pj4+IE5WR1JFDQo+Pj4+PiBh bmQNCj4+Pj4+Pj4+Pj4+IFZYTEFOLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBJdCBzZWVt cyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbg0KPj4+ PiBzZWxlY3Rpb24NCj4+Pj4+Pj4+Pj4+IHByb2Nlc3MNCj4+Pj4+Pj4+Pj4+IGJ5IGFkdmFuY2lu ZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gUmVnYXJk cywNCj4+Pj4+Pj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBw aS5udT4gd3JvdGU6DQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBXb3JraW5nIGdyb3VwLA0K Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsi IHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNiBh cyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+Pj4+Pj4+Pj4+Pj4gRHVlIHRvIHRo ZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0aA0KPj4+PiBv bmUgd2Vlay4NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscw0KPj4+Pj4gd29ya2luZw0K Pj4+Pj4+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFz ZSBnaXZlIGFuDQo+Pj4+IHRlY2huaWNhbA0KPj4+Pj4+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UNCj4+Pj4gdGhpbmsgdGhh dA0KPj4+Pj4+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3 b3JraW5nIGdyb3VwDQo+Pj4+IGRvY3VtZW50Lg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ IFRoaXMgcG9sbCBlbmRzIEphbnVhcnkgMDcsIDIwMTMuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgLQ0KPj4+ Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0 ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXANCj4+Pj4gbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+Pj4g dGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9z ZQ0KPj4+PiBhbHJlYWR5DQo+Pj4+Pj4+Pj4+Pj4gZGlzY2xvc2VkLg0KPj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9jdW1lbnQgdGhh dCB3ZSB1c2VkIGZvcg0KPj4gdGhlDQo+Pj4+IElQUg0KPj4+Pj4+Pj4+Pj4+IHBvbGwpDQo+Pj4+ Pj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9y cy4gTWFyc2hhbGwNCj4+Pj4gaGFzDQo+Pj4+Pj4+Pj4+Pj4gZGlzY29udGludWVkIGFsbCBpbnRl cmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZQ0KPj4+PiBhdXRob3IgdGVhbQ0K Pj4+Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBncm91 cCBjaGFpcnMgaGFzDQo+Pj4+IHRyaWVkIHRvDQo+Pj4+Pj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFs bCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uDQo+PiB0aGUNCj4+Pj4g SVBSDQo+Pj4+Pj4+Pj4+Pj4gcG9sbC4NCj4+Pj4+Pj4+Pj4+PiBXZSBoYXZlIGhhZCBubyBzdWNj ZXNzIGluIHRoaXMuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gRnJvbSB2ZXJzaW9uIC0w NCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBhDQo+Pj4+Pj4+Pj4+ Pj4gY28tYXV0aG9yLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IC9Mb2ENCj4+Pj4+Pj4+ Pj4+PiAobXBscyB3ZyBjby1jaGFpcikNCj4+Pj4+Pj4+Pj4+PiAtLQ0KPj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICAgZW1haWw6DQo+Pj4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0K Pj4+Pj4+Pj4+Pj4+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAg IGxvYUBwaS5udQ0KPj4+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAg ICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTINCj4+IDEzDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KPj4+Pj4+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+IG1wbHNAaWV0Zi5v cmcNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+PiBtcGxzQGlldGYu b3JnDQo+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBtcGxzQGlldGYub3Jn DQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXINCj4+Pj4gQ2FibGUNCj4+Pj4+Pj4g cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh bCwgb3INCj4+Pj4gc3ViamVjdCB0bw0KPj4+Pj4+PiBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPj4+PiBzb2xlbHkgZm9y DQo+Pj4+PiB0aGUNCj4+Pj4+Pj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPj4+PiBhcmUgbm90IHRoZQ0KPj4+Pj4+PiBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQNCj4+Pj4gYW55DQo+Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPj4+Pj4+PiBkaXN0cmlidXRp b24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUNCj4+IGNvbnRl bnRzDQo+Pj4+IG9mIGFuZA0KPj4+Pj4+PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUNCj4+Pj4gdW5sYXdmdWwuIElmIHlvdQ0KPj4+ Pj4+PiBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCj4+Pj4gaW1tZWRpYXRlbHkgYW5kDQo+Pj4+Pj4+IHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZA0KPj4+PiBhbnkg cHJpbnRvdXQuDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IG1wbHNAaWV0 Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4+PiBtcGxzQGlldGYub3JnDQo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From lucy.yong@huawei.com Thu Dec 20 09:48:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFF721F8A78 for ; Thu, 20 Dec 2012 09:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-2.417, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPusRaDGBLpo for ; Thu, 20 Dec 2012 09:48:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D621F89FD for ; Thu, 20 Dec 2012 09:48:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR55426; Thu, 20 Dec 2012 17:48:04 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 17:47:50 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 17:48:03 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 09:47:56 -0800 From: Lucy yong To: Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiaAqA//99ORCAAJLQgP//fIgg Date: Thu, 20 Dec 2012 17:47:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448647D3@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.202] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 17:48:08 -0000 SU1POiB0aGlzIHByb3Bvc2FsIGFyZSB3ZWxsIGFsaWVuIHdpdGggbnZvMyBmcmFtZXdvcmsgYW5k IGRhdGEgcGxhbmUgcmVxdWlyZW1lbnQuDQoNCiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbnZvMy1kYXRhcGxhbmUtcmVxdWlyZW1lbnRzLw0KDQpodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnZvMy1mcmFtZXdvcmsvDQoNClBsZWFz ZSBsZXQgbWUga25vdyBpZiB5b3UgdGhpbmsgdGhpcyBwcm9wb3NhbCBkb2VzIG5vdCBmaXQgaW50 byBudm8zIGZyYW1ld29yayBvciBkYXRhIHBsYW5lIHJlcXVpcmVtZW50Lg0KDQpQbGVhc2UgYWxz byBhd2FyZSB0aGVyZSBhcmUgYWxyZWFkeSB0d28gc29sdXRpb24gZHJhZnQgaW4gbnZvMyB0aGF0 IGNhbiB1c2UgdGhpcyBhcHByb2FjaC4NCg0KTHVjeQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNv bV0NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDExOjMxIEFNDQo+IFRvOiBM dWN5IHlvbmcNCj4gQ2M6IFNoYW5lIEFtYW50ZTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMu aWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJs eWluZyBuZXR3b3JrDQo+IA0KPiBQbGVhc2UgZG9uJ3QgbWl4IHVwIHRoaW5ncy4gVGhlIE1QTFMg cHJvdG9jb2wgZGVzaWduIEkgYWdyZWUgbXVzdCBiZQ0KPiBkb25lIGJ5IE1QTFMgV0cuIEJ1dCB0 aGUgcXVlc3Rpb24gaXMgd2hldGhlciB5b3VyIHByb3Bvc2FsIG1lZXRzIHRoZQ0KPiBuZXR3b3Jr IHZpcnR1YWxpemF0aW9uIHJlcXVpcmVtZW50cy4NCj4gDQo+IFRoZSBOVk8zIHRhc2sgaXMgdG8g ZG9jdW1lbnQgdGhlIGlzc3VlcywgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsgZm9yDQo+IE52 TzMuIFRoZW4gaWYgTVBMUyBvdmVyIElQIGxvb2tzIGxpa2UgYSBzdWl0YWJsZSBzb2x1dGlvbiB0 aGF0IG1lZXRzDQo+IHRoZSByZXF1aXJlbWVudHMgc3VjaCBhcyB0aGUgc2NhbGUsIG1vYmlsaXR5 LCBldGMsIHRoZW4gdGhleSB3aWxsIGFzaw0KPiBNUExTIFdHIGZvciBwcm90b2NvbCBkZXNpZ24u DQo+IA0KPiBTbyBiZWZvcmUgcHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJIHRoaW5rIHlvdSBzaG91 bGQgdGFrZSBpdCB0byBOVk8zIFdHDQo+IGFuZCBjb252aW5jZSB0aGVtIHRoaXMgc29sdXRpb24g bWVldHMgdGhlaXIgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsuDQo+IA0KPiBXZSBkb24ndCB3 YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0aW9ucyBmb3IgdGhlIHNhbWUgcHJv YmxlbSwNCj4gZG8gd2U/DQo+IA0KPiAtU2hhaHJhbQ0KPiANCj4gDQo+IA0KPiBSZWdhcmRzLA0K PiBTaGFocmFtDQo+IA0KPiANCj4gT24gRGVjIDIwLCAyMDEyLCBhdCA4OjU2IEFNLCAiTHVjeSB5 b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPiBOZXR3b3JrIHZpcnR1 YWxpemF0aW9uIG92ZXJsYXkgaXMgZGlzY3Vzc2VkIHVuZGVyIG52bzMgV0cuIFRoaXMgZG9lcw0K PiBub3QgbWVhbiB0aGF0IG52bzMgV0cgaGFzIHRvIGRlc2lnbiBhIG5ldyBwcm90b2NvbCBmb3Ig YSB1bmRlcmx5aW5nDQo+IG5ldHdvcmsgb3IgYSBuZXcgcHJvdG9jb2wgZm9yIGEgb3ZlcmxheSBu ZXR3b3JrLiBJbiBmYWN0LCBwZW9wbGUgdGhlcmUNCj4gYWltIG9uIGxldmVyYWdlIHN0YW5kYXJk IG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29tcGxpc2ggdGhlbS4gSU1POg0KPiB0aGVzZSBleHBh bnNpb25zIG9uIGFuIGV4aXN0aW5nIHN0YW5kYXJkIHByb3RvY29sIGhhdmUgdG8gYmUgd29ya2Vk IG91dA0KPiBpbiB0aGUgcHJvdG9jb2wgV0cgZ3JvdXAsIGl0IHNob3VsZCBub3QgZ2l2ZSBudm8z IFdHIGZyZWUgcmlnaHQgdG8NCj4gZW5oYW5jZSB0aGVzZSBwcm90b2NvbHMuIEZvciBhIGJyYW5k IG5ldyBwcm90b2NvbCBmb3IgbmV0d29yaw0KPiB2aXJ0dWFsaXphdGlvbiBvdmVybGF5LCBudm8z IFdHIG1heSBiZSB0aGUgcGxhY2UgdG8gc3RhcnQuDQo+ID4NCj4gPiBMdWN5DQo+ID4NCj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogU2hhaHJhbSBEYXZhcmkgW21h aWx0bzpkYXZhcmlAYnJvYWRjb20uY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIg MjAsIDIwMTIgMTA6MzQgQU0NCj4gPj4gVG86IEx1Y3kgeW9uZw0KPiA+PiBDYzogU2hhbmUgQW1h bnRlOyBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsN Cj4gPj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFttcGxz XSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCj4gPj4N Cj4gPj4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFu ZCBjb25zZW50ZWQgIGluDQo+IE5WTzMNCj4gPj4gV0cuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ ID4+IFNoYWhyYW0NCj4gPj4NCj4gPj4NCj4gPj4gT24gRGVjIDIwLCAyMDEyLCBhdCA3OjM5IEFN LCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+Pg0KPiA+ Pj4gSGkgU2hhbmUsDQo+ID4+Pg0KPiA+Pj4gSSB1bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4g b24gYSBuZXcgZW5jYXBzdWxhdGlvbiB0byBhbiBleGlzdGluZw0KPiA+PiBuZXR3b3JrLg0KPiA+ Pj4NCj4gPj4+IEhvd2V2ZXIsIE1QTFMtaW4tVURQIGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBl eGlzdGluZyBTUCBJUC9NUExTDQo+ID4+IG5ldHdvcmsgYXQgYWxsLg0KPiA+Pj4gTVBMUy1pbi1V RFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVyIHRvIGJlIGRlY291cGxlZCBmcm9tDQo+ IE1QTFMNCj4gPj4gc2VydmVyIGxheWVyIGFuZCB1c2UgTVBMUyBjbGllbnQgbGF5ZXIgYXMgb3Zl cmxheSBuZXR3b3JrIGFuZCBhbiBJR1ANCj4gYXMNCj4gPj4gYSB1bmRlcmx5aW5nIG5ldHdvcmsg Zm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBmb3IgREMuIFlvdQ0KPiBtYXkNCj4g Pj4gYXJndWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBMUyBsYXllciBvdmVy IGFuIElHUA0KPiB1bmRlcmxpbmcNCj4gPj4gbmV0d29yay4gV2UgaGF2ZSBwb2ludGVkIG91dCBp biB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJvdXRlcnMgaW4gREMNCj4gPj4gYmFyZWx5IHN1cHBv cnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCBNUExTLWluLUdSRSBhcmUgYmFyZWx5DQo+ IHVzZWQNCj4gPj4gaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRlcnMgaW4gREMgcGVy Zm9ybSB1cGQgcG9ydCBiYXNlZA0KPiBsb2FkDQo+ID4+IGJhbGFuY2luZyBub3cuDQo+ID4+Pg0K PiA+Pj4gRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQIGVuY2Fwc3Vs YXRpb24gaGFzDQo+ID4+IGFkdmFudGFnZSBvdmVyIEdSRSBlbmNhcHN1bGF0aW9uIHRvby4gSW4g VURQIGVuY2Fwc3VsYXRpb24sIHRoZQ0KPiBmcmFtZQ0KPiA+PiBoZWFkZXIgZGVjb3VwbGVzIHRo ZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLg0KPiBvdXRlcg0K PiA+PiBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFk ZXIsIHdoaWNoDQo+ID4+IHVuZGVybHlpbmcgbmV0d29yayB1c2VzIG9ubHkuIEhvd2V2ZXIsIEdS RSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9yDQo+ID4+IHRoZSBvdmVybGF5IG5ldHdvcmsgYW5k IHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3INCj4gbG9hZA0KPiA+PiBi YWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBHUkUgaGVh ZGVyIHRvby4NCj4gSW4NCj4gPj4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5IGFuZCB1bmRl cmx5aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5jZQ0KPiBpdA0KPiA+PiBoYXMgbm90IHVzZWQg YSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaA0K PiA+PiBjb3VwbGluZy4NCj4gPj4+DQo+ID4+PiBBcyB0aGUgaW5kdXN0cnkgbW92ZXMgdG93YXJk IG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBhbmQNCj4gPj4gZGVjb3VwbGVzIG92ZXJs YXkgbmV0d29ya3MgZnJvbSB0aGUgdW5kZXJseWluZyBuZXR3b3JrLiBBIGNsZWFyDQo+ID4+IHNl cGFyYXRpb24gb2Ygb3ZlcmxheSBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlzIGEgIk1V U1QiIGluIG15DQo+ID4+IG9waW5pb24uIElmIHdlIGNvdW50IEdSRSBhcyB0aGUgb3ZlcmxheSBo ZWFkZXIsIHRoZW4gZm9yIElQdjQNCj4gPj4gdW5kZXJseWluZyBuZXR3b3JrLCB0aGVyZSBpcyBu byBmaWVsZCBmb3IgdGhlIGZsb3cgZW50cm9weS4gVGhpcyBpcw0KPiB0aGUNCj4gPj4gcmVhc29u IHdlIHByb3Bvc2UgdGhlIFVEUCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVy bHlpbmcNCj4gPj4gbmV0d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkg bmV0d29yayBiZXNpZGUgTVBMUw0KPiBjbGllbnQNCj4gPj4gbGF5ZXIgKGUuZy4gVlhMQU4sIEwy VFAtaW4tVURQLCBldGMpLg0KPiA+Pj4NCj4gPj4+IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1p bi1MMlRQLWluLVVEUCBpbnN0ZWFkLiBZZXMsIE1QTFMtaW4tTDJUUC0NCj4gPj4gaW4tVURQIHNj aGVtYSBhbHNvIHByb3ZpZGVzIGEgb3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKQ0K PiA+PiBuZXR3b3JrIGRlY291cGxpbmcuIEwyVFAgcHJvdG9jb2wgKHJmYzM5MzEpIHByb3ZpZGVz IGdvb2Qgc2VjdXJpdHkNCj4gPj4gbWVjaGFuaXNtIGFuZCBoYXMgdGhlIGVtYmVkZGVkIGNvbnRy b2wgZnVuY3Rpb24gdG9vLiBUaGVyZWZvcmUsDQo+IHNvbWVvbmUNCj4gPj4gY2FuIHVzZSBpdCBm b3IgTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudA0K PiA+PiBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWluLUwy VFAtaW4tVURQIGlzIGENCj4gPj4gb3ZlcmtpbGwgYW5kIHRvbyBjb21wbGV4LiBIZXJlIHdlIG5l ZWQgYSBzY2hlbWEgdG8gc3VwcG9ydCBJR1ANCj4gPj4gdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0 aG91dCB0b3VjaGluZyBhIG92ZXJsYXkgaGVhZGVyLiBVRFANCj4gPj4gZW5jYXBzdWxhdGlvbiBp cyB0aGUgYmVzdCBjaG9pY2UgdG8gYWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGUNCj4g Pj4gY2hhbmdlcyBvbiBleGlzdGluZyByb3V0ZXJzLCBlLmcuIGNoYW5nZSBhdCBlZGdlIHJvdXRl cnMsIG5vIGNoYW5nZQ0KPiBvbg0KPiA+PiB0cmFuc2l0IHJvdXRlcnMuDQo+ID4+Pg0KPiA+Pj4g UmVnYXJkcywNCj4gPj4+IEx1Y3kNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFv aHVAaHVhd2VpLmNvbV0NCj4gPj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIg NDoxNCBBTQ0KPiA+Pj4+IFRvOiBTaGFuZSBBbWFudGUNCj4gPj4+PiBDYzogUm9nZXJzLCBKb3No OyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPj4gdWRwQHRvb2xzLmlldGYu b3JnOw0KPiA+Pj4+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ ID4+Pj4gU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cgdG8gdHJhbnNwb3J0IE1QTFMgb3ZlciBV RFAgdHVubmVscw0KPiA+Pj4+DQo+ID4+Pj4gSGkgU2hhbmUsDQo+ID4+Pj4NCj4gPj4+PiBUaGFu a3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXNwb25zZSBp bmxpbmUuDQo+ID4+Pj4NCj4gPj4+PiBOb3RlOiBJIGNoYW5nZWQgdGhlIHN1YmplY3QgbGluZSBh Y2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi4NCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLdPKvP7U rbz+LS0tLS0NCj4gPj4+Pj4gt6K8/sjLOiBTaGFuZSBBbWFudGUgW21haWx0bzpzaGFuZUBjYXN0 bGVwb2ludC5uZXRdDQo+ID4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAyMjozOA0KPiA+ Pj4+PiDK1bz+yMs6IFh1eGlhb2h1DQo+ID4+Pj4+ILOty806IFJvZ2VycywgSm9zaDsgU2hhaHJh bSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4+Pj4gdWRwQHRvb2xzLmlldGYub3JnOw0K PiA+Pj4+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+Pj4+ PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtl IGRyYWZ0LXh1LQ0KPiA+Pj4+IG1wbHMtaW4tdWRwIGFuDQo+ID4+Pj4+IG1wbHMgd29ya2luZyBn cm91cCBkb2N1bWVudA0KPiA+Pj4+Pg0KPiA+Pj4+PiBYaWFvaHUsDQo+ID4+Pj4+DQo+ID4+Pj4+ IE9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tPg0KPiB3cm90ZToNCj4gPj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+Pj4gt6K8 /sjLOiBTaGFuZSBBbWFudGUgW21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXRdDQo+ID4+Pj4+ Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDExOjU4DQo+ID4+Pj4+Pj4gytW8/sjLOiBSb2dl cnMsIEpvc2gNCj4gPj4+Pj4+PiCzrcvNOiBTaGFocmFtIERhdmFyaTsgWHV4aWFvaHU7IGRyYWZ0 LXh1LW1wbHMtaW4tDQo+ID4+Pj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPiA+Pj4+Pj4+IG1wbHNA aWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4+Pj4+Pj4g1vfM4jogUmU6 IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC0NCj4g eHUtDQo+ID4+Pj4gbXBscy1pbi11ZHANCj4gPj4+Pj4gYW4NCj4gPj4+Pj4+PiBtcGxzIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVj IDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIg0KPiA+Pj4+IDxqb3NoLnJvZ2Vy c0B0d2NhYmxlLmNvbT4NCj4gPj4+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4gSSBzaGFyZSB5b3Vy IFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+Pj4g c29sdXRpb24NCj4gPj4+Pj4+Pj4gYWRkcmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIuDQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+PiArMS4gIFBsZWFzZSBkbyBub3QgZGVmaW5lIHlldCBhbm90aGVy IE1QTFMtb3Zlci1JUA0KPiBlbmNhcHN1bGF0aW9uLg0KPiA+Pj4+IFRoZQ0KPiA+Pj4+PiBJRVRG DQo+ID4+Pj4+Pj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRG IGhhcyBhbHNvDQo+ID4+Pj4gc3RhbmRhcmRpemVkDQo+ID4+Pj4+IE1QTFMNCj4gPj4+Pj4+PiBv dmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBs ZWFzdA0KPiA+PiBvbmUsDQo+ID4+Pj4gdmVyeQ0KPiA+Pj4+Pj4+IGxhcmdlIG9wZXJhdG9yIG5l dHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZg0KPiA+Pj4+IEwz VlBOIG92ZXINCj4gPj4+Pj4gYW4NCj4gPj4+Pj4+PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gSGkgU2hhbmUsDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmsgeW91IGZvciB0 ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwgZGVwbG95bWVudHMgb2YgTVBMUw0KPiBvdmVyDQo+ ID4+Pj4gSVAgaW4gYXQNCj4gPj4+Pj4gbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5l dHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkNCj4gPj4+PiB2YWx1YWJsZSB0byB0aG9zZQ0K PiA+Pj4+PiBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlvbiBv ZiBNUExTIG92ZXIgSVANCj4gaW4NCj4gPj4+PiB0b2RheSdzIFNQDQo+ID4+Pj4+IG5ldHdvcmtz Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkg Zm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4+PiBbTk9URTogdGhlIGRhdGVzIHRoZSBhYm92 ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUgMjAwNg0KPiA+Pj4+PiB0aW1lZnJhbWUh XQ0KPiA+Pj4+Pj4+ICAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50cyByZWxhdGVkIHRvIFZQTFMg dGhhdCBzYXkgdGhhdCBWUExTDQo+ID4+Pj4gbWF5IGJlDQo+ID4+Pj4+Pj4gY2FycmllZCBvdmVy IEwyVFB2Mw0KPiA+Pj4+Pj4+ICAgQW5kLCBoZXJlJ3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0 IGxlYXN0IG9uZSB2ZW5kb3IgaGFzDQo+ID4+Pj4+IGltcGxlbWVudGVkDQo+ID4+Pj4+Pj4gSVBW UE4ncyBvdmVyIEwyVFB2MzoNCj4gPj4NCj4gaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9j cy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gVGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVu dGlvbmVkIGluDQo+ID4+Pj4gdGhpcyBkcmFmdA0KPiA+Pj4+PiBBTkQgb3RoZXIgZHJhZnRzLCB0 aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbg0KPiA+PiB0aGUN Cj4gPj4+PiBTZXNzaW9uDQo+ID4+Pj4+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9y IHRoZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXINCj4gYXMNCj4gPj4+PiBkZWZpbmVkIGlu DQo+ID4+Pj4+IFtSRkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3Rpbmcg Y29yZSByb3V0ZXJzIHNvDQo+IGZhci4NCj4gPj4+Pj4NCj4gPj4+Pj4gRldJVywgSSBoYXZlIGhh ZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4NCj4gPj4+PiByZXF1 ZXN0aW5nIGEgY29yZQ0KPiA+Pj4+PiByb3V0ZXIgdmVuZG9yIHRvIHN1cHBvcnQgY2hhbmdlcyB0 byB0aGUgaW5wdXQta2V5cyB1c2VkIGluIGhhc2gNCj4gPj4+PiBjYWxjdWxhdGlvbnMgaW4NCj4g Pj4+Pj4gX2V4aXN0aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkp IHRocm91Z2hvdXQgbXkNCj4gPj4+PiBuZXR3b3JrLg0KPiA+Pj4+PiBGdXJ0aGVyLCBJIHN1c3Bl Y3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBzYXZ2eQ0KPiA+PiBmb2xr cw0KPiA+Pj4+IGFuZA0KPiA+Pj4+PiB1bmRlcnN0YW5kIHRoZSBpbnRlcm5hbCBhcmNoaXRlY3R1 cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuICBBcw0KPiBhDQo+ID4+Pj4gcmVzdWx0LCB0aG9z ZQ0KPiA+Pj4+PiBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmlj YWxseSBwb3NzaWJsZSBpbg0KPiB0aGlzDQo+ID4+Pj4gcmVnYXJkLg0KPiA+Pj4+PiBUaHVzLCBp dCBtYXkgYmUgYSBxdWVzdGlvbiBvZiAibWV0aG9kcyIgbmVjZXNzYXJ5IHRvIGNvbnZpbmNlDQo+ IHRoZWlyDQo+ID4+Pj4gSFcNCj4gPj4+Pj4gc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0 ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0bw0KPiA+PiBhY2hpZXZlDQo+ID4+Pj4gdGhl aXINCj4gPj4+Pj4gYnVzaW5lc3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBl dmVuIGJlIG5lY2Vzc2FyeSAuLi4NCj4gPj4gc2VlDQo+ID4+Pj4gYmVsb3cuDQo+ID4+Pj4NCj4g Pj4+PiBDb3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJv dmUgY2hhbmdlIGluDQo+ID4+Pj4gRVhJU1RJTkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBkZXBsb3ll ZCBjb3JlIHJvdXRlcnM/DQo+ID4+Pj4NCj4gPj4+Pj4+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0 aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mDQo+ID4+Pj4gYmFsYW5jaW5n IElQDQo+ID4+Pj4+IHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUt dHVwbGUgb2YgVURQIHBhY2tldHMuDQo+ID4+IEJ5DQo+ID4+Pj4gdXNpbmcgdGhlDQo+ID4+Pj4+ IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJh bGFuY2luZw0KPiA+Pj4+IGNhcGFiaWxpdHkgb2YNCj4gPj4+Pj4gbW9zdCBleGlzdGluZyBjb3Jl IHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkNCj4gPj4+PiBj aGFuZ2UgdG8NCj4gPj4+Pj4gdGhlbS4gVGhhdCBpcyB0aGUgbWFqb3IgbW90aXZhdGlvbiBvZiB0 aGlzIGRyYWZ0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiB0aGlzIGlzIGEgY29uY2VybiwgdGhlbiB3 aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFmZmljIGluDQo+ID4+Pj4gTVBMUy9MMlRQdjMsIHdo aWNoDQo+ID4+Pj4+IHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+ID4+Pj4NCj4g Pj4+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB5b3UgcHJlZmVyIHRvIHVzZSBNUExT LWluLUwyVFB2My1pbi0NCj4gPj4gVURQDQo+ID4+Pj4gaW5zdGVhZCBvZiBNUExTLWluLVVEUCwg cmlnaHQ/DQo+ID4+Pj4NCj4gPj4+Pj4gSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRv IGNvbnNpZGVyIGEgW21pbm9yXSAoPykgY2hhbmdlDQo+IHRvDQo+ID4+Pj4gUkZDIDM5MzEsDQo+ ID4+Pj4+IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBjb25uZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFj a2V0cyAobm90DQo+IGNvbnRyb2wNCj4gPj4+PiBwYWNrZXRzKQ0KPiA+Pj4+PiB0byB1c2UgYSB2 YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwNCj4g Pj4gYmFzZWQNCj4gPj4+PiBvbiBhIGhhc2gNCj4gPj4+Pj4gY2FsY3VsYXRpb24sIHRvIGFjaGll dmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92ZXIgZXhpc3RpbmcNCj4gPj4gZXF1aXBtZW50DQo+ ID4+Pj4gaW4gYW4NCj4gPj4+Pj4gSVAtb25seSBjb3JlLiAgTDJUUCBlbmQtc3lzdGVtIGltcGxl bWVudGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXINCj4gb2ZmDQo+ID4+Pj4ganVzdCB1c2luZw0KPiA+ Pj4+PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0 aXBsZXhvciB0bw0KPiA+Pj4+IGFzc29jaWF0ZQ0KPiA+Pj4+PiBpbmNvbWluZyBwYWNrZXRzIHdp dGggdGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9sIENoYW5uZWwuICBJbg0KPiBmYWN0LA0KPiA+ Pj4+IGl0J3Mgbm90DQo+ID4+Pj4+IGNsZWFyIHRvIG1lIHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50 YXRpb25zIG1heSAvYWxyZWFkeS8gZG8gdGhpcywNCj4gPj4+PiBtYWtpbmcgYW55DQo+ID4+Pj4+ ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQ IGVuZC0NCj4gc3lzdGVtDQo+ID4+Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4gPj4+Pj4NCj4gPj4+ Pj4gVGhlIGJlYXV0eSBvZiB0aGUgYWJvdmUgYXBwcm9hY2ggaXM6DQo+ID4+Pj4+IDEpIEkgd291 bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcw0K PiA+Pj4+IGxpbWl0ZWQgdG8gdGhlDQo+ID4+Pj4+ICJjb250cm9sIGNoYW5uZWwiIChzb2Z0d2Fy ZSkgb2YgZXhpc3RpbmcgTDJUUCBlbmQtc3lzdGVtDQo+ID4+Pj4gaW1wbGVtZW50YXRpb25zLg0K PiA+Pj4+PiBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4 aXN0aW5nIEwyVFB2Mw0KPiA+Pj4+PiBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVu dG9ycyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQgb24NCj4gPj4gdGhhdCkuDQo+ID4+Pj4NCj4gPj4+ PiBJTUhPLCBubyBtYXR0ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCAg dGhlDQo+IGhhcmR3YXJlDQo+ID4+IG9mDQo+ID4+Pj4gUEUgcm91dGVycyBuZWVkcyB0byBiZSB1 cGdyYWRlZCwgZS5nLiwgaW5ncmVzcyBQRSByb3V0ZXJzIG5lZWQgdG8NCj4gPj4gZmlsbA0KPiA+ Pj4+IGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBo ZWFkZXJzLg0KPiA+Pj4+DQo+ID4+Pj4+IDIpIFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQg c2VjdXJpdHkgb25lIGdldHMgYnkgdXNpbmcNCj4gIlNlc3Npb24NCj4gPj4+PiBJRCIgYW5kDQo+ ID4+Pj4+ICJDb29raWUiIGZpZWxkcyB0byBlbnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNr ZXQgaXMgaW50ZW5kZWQNCj4gPj4gZm9yDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+IGlkZW50aWZpZWQg c2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gPj4+Pj4g LS0tc25pcC0tLQ0KPiA+Pj4+PiAgTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBm b3IgaXRzIFZQTnMgdmlhIGEgMzItYml0DQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiAgSUQgaW4g dGhlIEwyVFB2MyBkYXRhIGhlYWRlci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWUN Cj4gPj4+Pj4gIChkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlv bmFsIGNoZWNrIHRvDQo+ID4+IGVuc3VyZQ0KPiA+Pj4+PiAgdGhhdCBhbiBhcnJpdmluZyBwYWNr ZXQgaXMgaW50ZW5kZWQgZm9yIHRoZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+ID4+Pj4+ICBUaHVz LCB1c2Ugb2YgYSBDb29raWUgd2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0K PiA+Pj4+IGd1YXJhbnRlZQ0KPiA+Pj4+PiAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2Fz IHBlcmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCj4gPj4+Pj4gIFNlc3Npb24gSUQgaXRz ZWxmIHdhcyBub3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQo+ID4+Pj4+IC0tLXNuaXAtLS0NCj4g Pj4+Pj4gLi4uIGluIHJlZ2FyZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNl Y3VyaXR5IEFyZWENCj4gPj4gZm9sa3MNCj4gPj4+PiBoYXZlLCBpbiB0aGUNCj4gPj4+Pj4gcGFz dCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExT IG92ZXINCj4gPj4gSVANCj4gPj4+PiB0cmFuc3BvcnQuDQo+ID4+Pj4+IEluIGZhY3QsIHRoaXMg aXMgd2h5IHlvdSBzZWUgdGV4dCBpbiBTZWN0aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YNCj4gPj4g UkZDDQo+ID4+Pj4gNDY2NS4NCj4gPj4+Pj4gKFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3Vh Z2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdXNlIE1QTFMNCj4gZm9yDQo+ID4+Pj4gdHJhbnNwb3J0 KS4NCj4gPj4+Pj4gV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBw YXkgbXVjaCBhdHRlbnRpb24gdG8NCj4gPj4+PiBkYWlseSB0cmFmZmljIG9uDQo+ID4+Pj4+IHRo ZSBNUExTIFdHIG1haWxpbmcgbGlzdCwgSSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJu IHdpbGwNCj4gPj4+PiBhcmlzZSBpZi93aGVuIHRoaXMNCj4gPj4+Pj4gZHJhZnQgZ29lcyB0byB0 aGUgSUVTRyAuLi4NCj4gPj4+Pg0KPiA+Pj4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHks IHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5jZSBvZg0KPiA+PiBNUExTLQ0KPiA+Pj4+IGlu LUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4g SWYgdGhhdA0KPiA+PiBpcw0KPiA+Pj4+IHNvIGNvbmNlcm5lZCwgY2FuIHlvdSBleHBsYWluIHdo eSBNUExTLWluLUdSRSBpcyBmYXIgbW9yZSBwb3B1bGFyDQo+ID4+IHRoYW4NCj4gPj4+PiBNUExT LWluLUwyVFAgaW4gcHJhY3RpY2U/DQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+ Pj4gWGlhb2h1DQo+ID4+Pj4NCj4gPj4+Pj4gMykgRmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5 IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQNCj4gPj4gaW1wbGVtZW50DQo+ID4+Pj4gTDJU UCwgZm9yDQo+ID4+Pj4+IHR1bm5lbGluZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBub3QgcmVxdWly ZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG8NCj4gPj4+PiBzdXBwb3J0DQo+ID4+Pj4+IE1QTFMvVURQ IGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIgcHJvZHVjdCBsaW5lcy4NCj4gPj4+Pj4NCj4gPj4+Pj4g LXNoYW5lDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCByZWdhcmRz LA0KPiA+Pj4+Pj4gWGlhb2h1DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IElmIHRoZXJlIHdhcyBtYXJr ZXQgZGVtYW5kIGZvciBNUExTIG92ZXIgSVAsIHRoZW4gY2xlYXJseSBpdA0KPiA+PiB3b3VsZA0K PiA+Pj4+IGhhdmUNCj4gPj4+Pj4gYmVlbg0KPiA+Pj4+Pj4+IG1vcmUgd2lkZWx5IGltcGxlbWVu dGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExTDQo+ID4+Pj4gb3Zlcg0K PiA+Pj4+PiBHUkUgb3INCj4gPj4+Pj4+PiBNUExTIG92ZXIgTDJUUHYzLiAgKFdoZXJlIHRoZXJl J3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkNCj4gPj4gd291bGQNCj4gPj4+PiBub3RlDQo+ ID4+Pj4+IHRoYXQNCj4gPj4+Pj4+PiB0aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBu b3QgcGFuIG91dCB3YXMgdGhlcmUgYXJlDQo+ID4+IHNldmVyYWwsDQo+ID4+Pj4gcHJhY3RpY2Fs DQo+ID4+Pj4+Pj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25lIGdldHMgZnJvbSBnb2luZyB3aXRo IG5hdGl2ZSBNUExTDQo+ID4+Pj4+Pj4gZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRo ZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+ID4+Pj4+Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4g Pj4+Pj4+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPiA+Pj4+Pj4+IC4uLiB0byBuYW1l LCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZQ0KPiBjb21wZWxsaW5n DQo+ID4+Pj4+IGFyZ3VtZW50cw0KPiA+Pj4+Pj4+IHRvICd1cGdyYWRlJyBuZXR3b3JrIEhXIHRv IHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+IC1zaGFuZQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gLUpvc2gNCj4gPj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFo cmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb20+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9yIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIg SVAgaXMgbGVnYWN5IGFuZCB0aGVyZQ0KPiA+PiBpcw0KPiA+Pj4+IG5vIG5lZWQNCj4gPj4+Pj4+ Pj4+IHRvIGltcHJvdmUgaXQuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4g Pj4+Pj4+Pj4+IFNoYWhyYW0NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g T24gRGVjIDE3LCAyMDEyLCBhdCA4OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWku Y29tPg0KPiA+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gU2hhaHJhbSwN Cj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgT05MWSBpbnRlbmRlZCB0 byBwcm92aWRlIGEgTVBMUy1vdmVyLUlQDQo+ID4+Pj4gZW5jYXBzdWxhdGlvbg0KPiA+Pj4+Pj4+ Pj4+IG1ldGhvZCB3aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28g ZmFyIHRvDQo+ID4+Pj4gdGhvc2UNCj4gPj4+Pj4+Pj4+PiBvcGVyYXRvcnMgd2hvIGhhcHBlbiB0 byByZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTDQo+IGFwcGxpY2F0aW9uDQo+ID4+Pj4gdHJhZmZp Yw0KPiA+Pj4+Pj4+Pj4+IGFjcm9zcyBJUCBuZXR3b3Jrcy4gSSBiZWxpZXZlIE1QTFMtYmFzZWQg VlBOIG92ZXIgSVAsIE5WR1JFDQo+ID4+IGFuZA0KPiA+Pj4+PiBWWExBTg0KPiA+Pj4+Pj4+Pj4+ IGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQgdXNlIGNhc2VzLiBJZiB5b3UNCj4g Pj4gYWJzb2x1dGVseQ0KPiA+Pj4+IGJlbGlldmUNCj4gPj4+Pj4+Pj4+PiBpdCdzIG1lYW5pbmds ZXNzIG9mIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMNCj4gPj4+PiBhY3Jv c3MgSVANCj4gPj4+Pj4+Pj4+PiBuZXR3b3JrcyBhbmQgdGhlcmVmb3JlIHRob3NlIGV4aXN0aW5n IFJGQ3MgcmVsYXRlZCB0byBNUExTDQo+ID4+IG92ZXINCj4gPj4+PiBJUA0KPiA+Pj4+Pj4+Pj4+ IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMs DQo+ID4+IHBsZWFzZQ0KPiA+Pj4+IHNheQ0KPiA+Pj4+PiBzby4NCj4gPj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4gPj4+Pj4+Pj4+PiAoaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiA+Pj4+IGFyY2hpdmUvd2ViL252bzMvY3VycmVudC9tc2cw MTg2NC5odG1sKSBpcw0KPiA+Pj4+Pj4+Pj4+IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBzdWl0YWJs ZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZw0KPiA+Pj4+IGFyZ3VtZW50DQo+ID4+Pj4+ Pj4+Pj4gKGkuZS4sIHdoZXRoZXIgb3Igbm90IE1QTFMtYmFzZWQgVlBOIGlzIGFwcGxpY2FibGUg dG8gZGF0YQ0KPiA+Pj4+IGNlbnRlcnMpLiBJDQo+ID4+Pj4+Pj4+Pj4gaGFkIHRob3VnaHQgeW91 IHdvdWxkIHNwZWFrIHVwIGF0IHRoYXQgdGltZS4gU2FkbHksDQo+ID4+Pj4gc3VycHJpc2luZ2x5 IHNpbGVudA0KPiA+Pj4+Pj4+Pj4+IHRpbGwgbm93Lg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4gU2lnaCwgSSBkaWRuJ3QgaW50ZW5kIHRvIHNheSB0aGUgYWJvdmUgb3RoZXJ3aXNlLg0KPiA+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gWGlhb2h1DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+Pj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXQ0KPiA+PiC0+g0KPiA+Pj4+ ILHtDQo+ID4+Pj4+Pj4gUy4NCj4gPj4+Pj4+Pj4+Pj4gRGF2YXJpDQo+ID4+Pj4+Pj4+Pj4+ILei y83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPiA+Pj4+Pj4+Pj4+PiDK1bz+yMs6IExvYSBB bmRlcnNzb24NCj4gPj4+Pj4+Pj4+Pj4gs63LzTogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMu aWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYg d2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UNCj4gPj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11 ZHAgYW4NCj4gPj4+Pj4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0 IGhhcyBubyBhcHBsaWNhdGlvbiBpbg0KPiA+Pj4+IHRvZGF5J3MNCj4gPj4+Pj4+Pj4+Pj4gbW9k ZXJuIG1ldHJvDQo+ID4+Pj4+Pj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50 LCBhbmQgaXRzIG9ubHkgcHJhY3RpY2FsDQo+ID4+Pj4gYXBwbGljYXRpb24NCj4gPj4+Pj4+Pj4+ Pj4gaW4gaW4gZGF0YQ0KPiA+Pj4+Pj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jv d2RlZCB3aXRoIG90aGVyIHNvbHV0aW9ucyBzdWNoDQo+IGFzDQo+ID4+Pj4gTlZHUkUNCj4gPj4+ Pj4gYW5kDQo+ID4+Pj4+Pj4+Pj4+IFZYTEFOLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ PiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1 dGlvbg0KPiA+Pj4+IHNlbGVjdGlvbg0KPiA+Pj4+Pj4+Pj4+PiBwcm9jZXNzDQo+ID4+Pj4+Pj4+ Pj4+IGJ5IGFkdmFuY2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4gPj4+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEg QU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+ Pj4+Pj4+Pj4+IGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhp cyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdpdGgNCj4gPj4+PiBvbmUgd2Vlay4NCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0 L25vdCBzdXBwb3J0KSB0byB0aGUNCj4gbXBscw0KPiA+Pj4+PiB3b3JraW5nDQo+ID4+Pj4+Pj4+ Pj4+PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBh bg0KPiA+Pj4+IHRlY2huaWNhbA0KPiA+Pj4+Pj4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBz dXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiA+Pj4+IHRoaW5rIHRoYXQN Cj4gPj4+Pj4+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3 b3JraW5nIGdyb3VwDQo+ID4+Pj4gZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+PiBUaGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVu dCAtDQo+ID4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQx LyAuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28tYXV0 aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+Pj4gbWFpbGluZyBsaXN0 DQo+ID4+Pj4+Pj4+Pj4+PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBS IGNsYWltcyB0aGFuIHRob3NlDQo+ID4+Pj4gYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4+Pj4gZGlzY2xv c2VkLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNp b24gLTAzICh0aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZvcg0KPiA+PiB0aGUNCj4gPj4+PiBJ UFINCj4gPj4+Pj4+Pj4+Pj4+IHBvbGwpDQo+ID4+Pj4+Pj4+Pj4+PiBNYXJzaGFsbCBFdWJhbmtz IHdhcyBsaXN0ZWQgYXMgb25lIG9mIHRoZSBhdXRob3JzLg0KPiBNYXJzaGFsbA0KPiA+Pj4+IGhh cw0KPiA+Pj4+Pj4+Pj4+Pj4gZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUg SUVURiwgaW5jbHVkaW5nIHRoZQ0KPiA+Pj4+IGF1dGhvciB0ZWFtDQo+ID4+Pj4+Pj4+Pj4+PiBv ZiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcw0K PiA+Pj4+IHRyaWVkIHRvDQo+ID4+Pj4+Pj4+Pj4+PiBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVy IG1lYW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb24NCj4gPj4gdGhlDQo+ID4+Pj4gSVBSDQo+ ID4+Pj4+Pj4+Pj4+PiBwb2xsLg0KPiA+Pj4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2Vz cyBpbiB0aGlzLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAt MDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMNCj4gYQ0KPiA+Pj4+ Pj4+Pj4+Pj4gY28tYXV0aG9yLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IC9Mb2EN Cj4gPj4+Pj4+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPiA+Pj4+Pj4+Pj4+Pj4gLS0NCj4g Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gTG9hIEFuZGVyc3Nv biAgICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDoNCj4gPj4+Pj4+Pj4+Pj4gbG9hLmFuZGVy c3NvbkBlcmljc3Nvbi5jb20NCj4gPj4+Pj4+Pj4+Pj4+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFy ZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+Pj4+Pj4+Pj4+Pj4gRXJpY3Nzb24g SW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1Mg0KPiA+PiAx Mw0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KzQ2IDc2NyA3MiA5MiAxMw0KPiA+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+Pj4gbXBs cyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZw0KPiA+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+PiBtcGxzQGlldGYub3Jn DQo+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBv ZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXINCj4gPj4+PiBDYWJsZQ0K PiA+Pj4+Pj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIG9yDQo+ID4+Pj4gc3ViamVjdCB0bw0KPiA+Pj4+Pj4+IGNvcHlyaWdodCBi ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzDQo+IGludGVuZGVk DQo+ID4+Pj4gc29sZWx5IGZvcg0KPiA+Pj4+PiB0aGUNCj4gPj4+Pj4+PiB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYNCj4geW91DQo+ ID4+Pj4gYXJlIG5vdCB0aGUNCj4gPj4+Pj4+PiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBF LW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQNCj4gPj4+PiBhbnkNCj4gPj4+Pj4g ZGlzc2VtaW5hdGlvbiwNCj4gPj4+Pj4+PiBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUNCj4gPj4gY29udGVudHMNCj4gPj4+PiBvZiBhbmQN Cj4gPj4+Pj4+PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkIGFuZCBtYXkgYmUNCj4gPj4+PiB1bmxhd2Z1bC4gSWYgeW91DQo+ID4+Pj4+Pj4gaGF2ZSBy ZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ ID4+Pj4gaW1tZWRpYXRlbHkgYW5kDQo+ID4+Pj4+Pj4gcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kDQo+ID4+Pj4gYW55IHByaW50 b3V0Lg0KPiA+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+PiBtcGxzQGll dGYub3JnDQo+ID4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZw0K PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From lucy.yong@huawei.com Thu Dec 20 10:00:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AF921F8A95 for ; Thu, 20 Dec 2012 10:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.821 X-Spam-Level: X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-2.364, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ5+wPTHs2Yn for ; Thu, 20 Dec 2012 10:00:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C290621F8A93 for ; Thu, 20 Dec 2012 09:59:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR56004; Thu, 20 Dec 2012 17:59:57 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 17:58:44 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 17:58:50 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 09:58:47 -0800 From: Lucy yong To: Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiaAqA//99ORCAAJLQgP//f9BQ Date: Thu, 20 Dec 2012 17:58:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448647E5@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.202] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:00:03 -0000 PiBXZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0aW9ucyBmb3Ig dGhlIHNhbWUgcHJvYmxlbSwNCj4gZG8gd2U/DQpbTHVjeV0gRG8geW91IHNlZSB0aGF0IE5WTzMg c29sdmUgdGhlIHNhbWUgcHJvYmxlbSB0aGF0IElFVEYgYWxyZWFkeSBzb2x2ZXM/IA0KQlRXLCBJ IGFncmVlIHRoYXQgd2UgZG9uJ3Qgd2FudCBJRVRGIGRlc2lnbiBOIG51bWJlciBvZiBzb2x1dGlv bnMgZm9yIHRoZSBzYW1lIHByb2JsZW0uIEVhY2ggQk9GIHdhcyBjb250cm9sbGVkIGJ5IEFEIHZl cnkgY2FyZWZ1bGx5IHRvIGRldGVybWluZSBpZiB0aGUgdGFyZ2V0IHByb2JsZW0gaXMgYSBuZXcg cHJvYmxlbS4gVGhlIHBvaW50IGlzIHRoYXQsIGV2ZW4gYSBuZXcgcHJvYmxlbSwgZG9lcyBub3Qg bWVhbiB3ZSBuZWVkIGEgYnJhbmQgbmV3IHByb3RvY29sIHRvIGRvIGl0LiBUaGUgbGlnaHQgZXhw YW5zaW9uIG9mIElFVEYgc3RhbmRhcmQgcHJvdG9jb2wgdG8gc29sdmUgdGhlIG5ldyBwcm9ibGVt IGlzIHdoYXQgd2UgYXJlIHdvcmtpbmcgb24gaGVyZSwgd2hpY2ggaXMgdGhlIHdheSBmb3IgdGhl IG5ldHdvcmsgZXZvbHV0aW9uIGFuZCBwcm90b2NvbCBldm9sdXRpb24uDQoNCkx1Y3kNCj4gDQo+ IC1TaGFocmFtDQo+IA0KPiANCj4gDQo+IFJlZ2FyZHMsDQo+IFNoYWhyYW0NCj4gDQo+IA0KPiBP biBEZWMgMjAsIDIwMTIsIGF0IDg6NTYgQU0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2Vp LmNvbT4gd3JvdGU6DQo+IA0KPiA+IE5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBpcyBk aXNjdXNzZWQgdW5kZXIgbnZvMyBXRy4gVGhpcyBkb2VzDQo+IG5vdCBtZWFuIHRoYXQgbnZvMyBX RyBoYXMgdG8gZGVzaWduIGEgbmV3IHByb3RvY29sIGZvciBhIHVuZGVybHlpbmcNCj4gbmV0d29y ayBvciBhIG5ldyBwcm90b2NvbCBmb3IgYSBvdmVybGF5IG5ldHdvcmsuIEluIGZhY3QsIHBlb3Bs ZSB0aGVyZQ0KPiBhaW0gb24gbGV2ZXJhZ2Ugc3RhbmRhcmQgbmV0d29yayBwcm90b2NvbHMgdG8g YWNjb21wbGlzaCB0aGVtLiBJTU86DQo+IHRoZXNlIGV4cGFuc2lvbnMgb24gYW4gZXhpc3Rpbmcg c3RhbmRhcmQgcHJvdG9jb2wgaGF2ZSB0byBiZSB3b3JrZWQgb3V0DQo+IGluIHRoZSBwcm90b2Nv bCBXRyBncm91cCwgaXQgc2hvdWxkIG5vdCBnaXZlIG52bzMgV0cgZnJlZSByaWdodCB0bw0KPiBl bmhhbmNlIHRoZXNlIHByb3RvY29scy4gRm9yIGEgYnJhbmQgbmV3IHByb3RvY29sIGZvciBuZXR3 b3JrDQo+IHZpcnR1YWxpemF0aW9uIG92ZXJsYXksIG52bzMgV0cgbWF5IGJlIHRoZSBwbGFjZSB0 byBzdGFydC4NCj4gPg0KPiA+IEx1Y3kNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBTaGFocmFtIERhdmFyaSBbbWFpbHRvOmRhdmFyaUBicm9hZGNvbS5j b21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiAxMDozNCBBTQ0KPiA+ PiBUbzogTHVjeSB5b25nDQo+ID4+IENjOiBTaGFuZSBBbWFudGU7IGRyYWZ0LXh1LW1wbHMtaW4t dWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOw0KPiA+PiBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92 ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KPiA+Pg0KPiA+PiBOZXR3b3JrIHZpcnR1YWxp emF0aW9uIG92ZXJsYXkgbXVzdCBiZSBkaXNjdXNzZWQgYW5kIGNvbnNlbnRlZCAgaW4NCj4gTlZP Mw0KPiA+PiBXRy4NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4gU2hhaHJhbQ0KPiA+Pg0KPiA+ Pg0KPiA+PiBPbiBEZWMgMjAsIDIwMTIsIGF0IDc6MzkgQU0sICJMdWN5IHlvbmciIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbT4NCj4gd3JvdGU6DQo+ID4+DQo+ID4+PiBIaSBTaGFuZSwNCj4gPj4+DQo+ ID4+PiBJIHVuZGVyc3RhbmQgb3BlcmF0b3IgY29uY2VybiBvbiBhIG5ldyBlbmNhcHN1bGF0aW9u IHRvIGFuIGV4aXN0aW5nDQo+ID4+IG5ldHdvcmsuDQo+ID4+Pg0KPiA+Pj4gSG93ZXZlciwgTVBM Uy1pbi1VRFAgZG9lcyBub3QgYWltIG9uIGNoYW5naW5nIGV4aXN0aW5nIFNQIElQL01QTFMNCj4g Pj4gbmV0d29yayBhdCBhbGwuDQo+ID4+PiBNUExTLWluLVVEUCBpcyB0byBlbmFibGUgTVBMUyBj bGllbnQgbGF5ZXIgdG8gYmUgZGVjb3VwbGVkIGZyb20NCj4gTVBMUw0KPiA+PiBzZXJ2ZXIgbGF5 ZXIgYW5kIHVzZSBNUExTIGNsaWVudCBsYXllciBhcyBvdmVybGF5IG5ldHdvcmsgYW5kIGFuIElH UA0KPiBhcw0KPiA+PiBhIHVuZGVybHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBTdWNoIGFw cGxpY2F0aW9uIGlzIGZvciBEQy4gWW91DQo+IG1heQ0KPiA+PiBhcmd1ZSB3aHkgbm90IHVzZSB0 aGUgR1JFIHdoaWNoIGlzIGZvciBNUExTIGxheWVyIG92ZXIgYW4gSUdQDQo+IHVuZGVybGluZw0K PiA+PiBuZXR3b3JrLiBXZSBoYXZlIHBvaW50ZWQgb3V0IGluIHRoZSBkcmFmdCB0aGF0IGN1cnJl bnQgcm91dGVycyBpbiBEQw0KPiA+PiBiYXJlbHkgc3VwcG9ydCBHUkUgYmFzZWQgbG9hZCBiYWxh bmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkNCj4gdXNlZA0KPiA+PiBpbiBTUCBuZXR3 b3JrcyB0b28uIE1vc3Qgb2Ygcm91dGVycyBpbiBEQyBwZXJmb3JtIHVwZCBwb3J0IGJhc2VkDQo+ IGxvYWQNCj4gPj4gYmFsYW5jaW5nIG5vdy4NCj4gPj4+DQo+ID4+PiBGcm9tIHRoZSBhcmNoaXRl Y3R1cmUgcGVyc3BlY3RpdmUsIHRoZSBVRFAgZW5jYXBzdWxhdGlvbiBoYXMNCj4gPj4gYWR2YW50 YWdlIG92ZXIgR1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5jYXBzdWxhdGlvbiwgdGhl DQo+IGZyYW1lDQo+ID4+IGhlYWRlciBkZWNvdXBsZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlp bmcgbmV0d29yayBjbGVhcmx5LCBpLmUuDQo+IG91dGVyDQo+ID4+IGhlYWRlciBhbmQgb3Zlcmxh eSBoZWFkZXIuIFVEUCBiZWxvbmdzIHRvIG91dGVyIGhlYWRlciwgd2hpY2gNCj4gPj4gdW5kZXJs eWluZyBuZXR3b3JrIHVzZXMgb25seS4gSG93ZXZlciwgR1JFIGhlYWRlciBoYXMgdGhlIGZpZWxk cyBmb3INCj4gPj4gdGhlIG92ZXJsYXkgbmV0d29yayBhbmQgdXNlcyB0aGUga2V5IGZpZWxkIGZv ciBmbG93IGVudHJvcHkuIEZvcg0KPiBsb2FkDQo+ID4+IGJhbGFuY2luZywgaXQgcmVxdWlyZXMg dGhlIHVuZGVybHlpbmcgbmV0d29yayB1c2VzIEdSRSBoZWFkZXIgdG9vLg0KPiBJbg0KPiA+PiBz aG9ydCwgR1JFIHRpZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29ya3MgdG9nZXRo ZXIuIFNpbmNlDQo+IGl0DQo+ID4+IGhhcyBub3QgdXNlZCBhIGxvdCwgcGVvcGxlIGFyZSBub3Qg YXdhcmUgb2YgdGhlIGRpc2FkdmFudGFnZSBvZiBzdWNoDQo+ID4+IGNvdXBsaW5nLg0KPiA+Pj4N Cj4gPj4+IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlv biBvdmVybGF5IGFuZA0KPiA+PiBkZWNvdXBsZXMgb3ZlcmxheSBuZXR3b3JrcyBmcm9tIHRoZSB1 bmRlcmx5aW5nIG5ldHdvcmsuIEEgY2xlYXINCj4gPj4gc2VwYXJhdGlvbiBvZiBvdmVybGF5IGhl YWRlciBhbmQgdW5kZXJseWluZyBoZWFkZXIgaXMgYSAiTVVTVCIgaW4gbXkNCj4gPj4gb3Bpbmlv bi4gSWYgd2UgY291bnQgR1JFIGFzIHRoZSBvdmVybGF5IGhlYWRlciwgdGhlbiBmb3IgSVB2NA0K PiA+PiB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUgZmxvdyBl bnRyb3B5LiBUaGlzIGlzDQo+IHRoZQ0KPiA+PiByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVu Y2Fwc3VsYXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZw0KPiA+PiBuZXR3b3JrLiBJ biBmYWN0LCBpdCBjYW4gc3VwcG9ydCBhbnkgb3ZlcmxheSBuZXR3b3JrIGJlc2lkZSBNUExTDQo+ IGNsaWVudA0KPiA+PiBsYXllciAoZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAsIGV0YykuDQo+ID4+ Pg0KPiA+Pj4gWW91IHBvaW50IG91dCB1c2luZyBNUExTLWluLUwyVFAtaW4tVURQIGluc3RlYWQu IFllcywgTVBMUy1pbi1MMlRQLQ0KPiA+PiBpbi1VRFAgc2NoZW1hIGFsc28gcHJvdmlkZXMgYSBv dmVybGF5IChMMlRQKSBhbmQgdW5kZXJseWluZyAoSVApDQo+ID4+IG5ldHdvcmsgZGVjb3VwbGlu Zy4gTDJUUCBwcm90b2NvbCAocmZjMzkzMSkgcHJvdmlkZXMgZ29vZCBzZWN1cml0eQ0KPiA+PiBt ZWNoYW5pc20gYW5kIGhhcyB0aGUgZW1iZWRkZWQgY29udHJvbCBmdW5jdGlvbiB0b28uIFRoZXJl Zm9yZSwNCj4gc29tZW9uZQ0KPiA+PiBjYW4gdXNlIGl0IGZvciBNUExTIGNsaWVudCBsYXllciBv dmVyIEludGVybmV0LiBUbyBoYXZlIE1QTFMgY2xpZW50DQo+ID4+IGxheWVyIG92ZXIgYW4gSUdQ IHVuZGVybGluZyBuZXR3b3JrLCBJTU86IE1QTFMtaW4tTDJUUC1pbi1VRFAgaXMgYQ0KPiA+PiBv dmVya2lsbCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZCBhIHNjaGVtYSB0byBzdXBwb3J0 IElHUA0KPiA+PiB1bmRlcmx5aW5nIHRyYW5zcG9ydCB3aXRob3V0IHRvdWNoaW5nIGEgb3Zlcmxh eSBoZWFkZXIuIFVEUA0KPiA+PiBlbmNhcHN1bGF0aW9uIGlzIHRoZSBiZXN0IGNob2ljZSB0byBh Y2NvbXBsaXNoIHRoYXQgYW5kIG1pbmltaXplIHRoZQ0KPiA+PiBjaGFuZ2VzIG9uIGV4aXN0aW5n IHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVycywgbm8gY2hhbmdlDQo+IG9uDQo+ ID4+IHRyYW5zaXQgcm91dGVycy4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4gTHVjeQ0K PiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+Pj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiA+Pj4+ IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA0OjE0IEFNDQo+ID4+Pj4gVG86IFNo YW5lIEFtYW50ZQ0KPiA+Pj4+IENjOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFm dC14dS1tcGxzLWluLQ0KPiA+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+Pj4gbXBsc0BpZXRm Lm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBEaXNjdXNz aW9uIG9uIGhvdyB0byB0cmFuc3BvcnQgTVBMUyBvdmVyIFVEUCB0dW5uZWxzDQo+ID4+Pj4NCj4g Pj4+PiBIaSBTaGFuZSwNCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcyBmb3IgeW91ciBmdXJ0aGVyIGNv bW1lbnRzIGFuZCBwbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZS4NCj4gPj4+Pg0KPiA+Pj4+ IE5vdGU6IEkgY2hhbmdlZCB0aGUgc3ViamVjdCBsaW5lIGFjY29yZGluZyB0byBMb2EncyBzdWdn ZXN0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+PiC3orz+ yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4gPj4+Pj4g t6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDIyOjM4DQo+ID4+Pj4+IMrVvP7IyzogWHV4aWFvaHUN Cj4gPj4+Pj4gs63LzTogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBs cy1pbi0NCj4gPj4+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmc7 IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9s bCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+Pj4gbXBs cy1pbi11ZHAgYW4NCj4gPj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+ DQo+ID4+Pj4+IFhpYW9odSwNCj4gPj4+Pj4NCj4gPj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCAx MTo1MCBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+IHdyb3RlOg0KPiA+Pj4+ PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4+Pj4+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFp bHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4gPj4+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLU wjE5yNUgMTE6NTgNCj4gPj4+Pj4+PiDK1bz+yMs6IFJvZ2VycywgSm9zaA0KPiA+Pj4+Pj4+ILOt y806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPj4+PiB1 ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcNCj4gPj4+Pj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlm IHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LQ0KPiB4dS0NCj4gPj4+PiBtcGxzLWluLXVk cA0KPiA+Pj4+PiBhbg0KPiA+Pj4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0IDg6NTAgQU0s ICJSb2dlcnMsIEpvc2giDQo+ID4+Pj4gPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KPiA+Pj4+ Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBJIHNoYXJlIHlvdXIgU1AgcGVyc3BlY3RpdmUsIGFuZCBk byBub3Qgc2VlIHRoZSBwcm9ibGVtIHRoaXMNCj4gPj4+PiBzb2x1dGlvbg0KPiA+Pj4+Pj4+PiBh ZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICsx LiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQDQo+IGVuY2Fw c3VsYXRpb24uDQo+ID4+Pj4gVGhlDQo+ID4+Pj4+IElFVEYNCj4gPj4+Pj4+PiBhbHJlYWR5IHN0 YW5kYXJkaXplZCBNUExTIG92ZXIgR1JFLiAgVGhlIElFVEYgaGFzIGFsc28NCj4gPj4+PiBzdGFu ZGFyZGl6ZWQNCj4gPj4+Pj4gTVBMUw0KPiA+Pj4+Pj4+IG92ZXIgTDJUUHYzL1VEUC9JUCwgd2hp Y2ggaGFkIHNlZW4gc29tZSBkZXBsb3ltZW50IGluIGF0IGxlYXN0DQo+ID4+IG9uZSwNCj4gPj4+ PiB2ZXJ5DQo+ID4+Pj4+Pj4gbGFyZ2Ugb3BlcmF0b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBv ZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mDQo+ID4+Pj4gTDNWUE4gb3Zlcg0KPiA+Pj4+PiBhbg0K PiA+Pj4+Pj4+IElQLW9ubHkgbmV0d29yay4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIaSBTaGFuZSwN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJlIGFj dHVhbCBkZXBsb3ltZW50cyBvZiBNUExTDQo+IG92ZXINCj4gPj4+PiBJUCBpbiBhdA0KPiA+Pj4+ PiBsZWFzdCBvbmUsIHZlcnkgbGFyZ2Ugb3BlcmF0b3IgbmV0d29yay4gVGhpcyBmYWN0IG11c3Qg YmUgdmVyeQ0KPiA+Pj4+IHZhbHVhYmxlIHRvIHRob3NlDQo+ID4+Pj4+IHBlb3BsZSB3aG8gaGFk IGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1QTFMgb3ZlciBJUA0KPiBpbg0K PiA+Pj4+IHRvZGF5J3MgU1ANCj4gPj4+Pj4gbmV0d29ya3MuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+ IFNlZTogUkZDJ3MgNDQ1NCwgNDcxOSwgNDU5MSwgNDM0OSBmb3IgUFdFMyBvdmVyIEwyVFB2Mw0K PiA+Pj4+Pj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBi YWNrIGluIHRoZSAyMDA2DQo+ID4+Pj4+IHRpbWVmcmFtZSFdDQo+ID4+Pj4+Pj4gICBSRkMgNDY2 NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4g Pj4+PiBtYXkgYmUNCj4gPj4+Pj4+PiBjYXJyaWVkIG92ZXIgTDJUUHYzDQo+ID4+Pj4+Pj4gICBB bmQsIGhlcmUncyBldmlkZW5jZSBzaG93aW5nIHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMN Cj4gPj4+Pj4gaW1wbGVtZW50ZWQNCj4gPj4+Pj4+PiBJUFZQTidzIG92ZXIgTDJUUHYzOg0KPiA+ Pg0KPiBodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJlL2d1 aWRlL2NzZ2wzdnBuLmh0bWwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MgYWdhaW4gZm9yIHNo YXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4NCj4gPj4+PiB0aGlz IGRyYWZ0DQo+ID4+Pj4+IEFORCBvdGhlciBkcmFmdHMsIHRoZSBtZWNoYW5pc20gb2YgcGVyZm9y bWluZyBoYXNoIGNhbGN1bGF0aW9uIG9uDQo+ID4+IHRoZQ0KPiA+Pj4+IFNlc3Npb24NCj4gPj4+ Pj4gSUQgZmllbGQgaW4gdGhlIEwyVFB2MyBoZWFkZXIgb3IgdGhlIEtleSBmaWVsZCBpbiB0aGUg R1JFIGhlYWRlcg0KPiBhcw0KPiA+Pj4+IGRlZmluZWQgaW4NCj4gPj4+Pj4gW1JGQyA1NjQwXSBp cyBub3Qgd2lkZWx5IHN1cHBvcnRlZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28NCj4gZmFy Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nlc3MsIGluIHRoZSByZWxh dGl2ZWx5IHJlY2VudCBwYXN0LCBpbg0KPiA+Pj4+IHJlcXVlc3RpbmcgYSBjb3JlDQo+ID4+Pj4+ IHJvdXRlciB2ZW5kb3IgdG8gc3VwcG9ydCBjaGFuZ2VzIHRvIHRoZSBpbnB1dC1rZXlzIHVzZWQg aW4gaGFzaA0KPiA+Pj4+IGNhbGN1bGF0aW9ucyBpbg0KPiA+Pj4+PiBfZXhpc3RpbmdfIGhhcmR3 YXJlLCBhbHJlYWR5IGRlcGxveWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteQ0KPiA+Pj4+ IG5ldHdvcmsuDQo+ID4+Pj4+IEZ1cnRoZXIsIEkgc3VzcGVjdCB0aGF0IG1vc3QgbGFyZ2UgbmV0 d29yayBvcGVyYXRvcnMgYXJlIHNhdnZ5DQo+ID4+IGZvbGtzDQo+ID4+Pj4gYW5kDQo+ID4+Pj4+ IHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWlybHkg d2VsbC4gIEFzDQo+IGENCj4gPj4+PiByZXN1bHQsIHRob3NlDQo+ID4+Pj4+IHNhbWUgb3BlcmF0 b3JzIGtub3cgd2hhdCBpcyBhbmQgaXMgbm90IHRlY2huaWNhbGx5IHBvc3NpYmxlIGluDQo+IHRo aXMNCj4gPj4+PiByZWdhcmQuDQo+ID4+Pj4+IFRodXMsIGl0IG1heSBiZSBhIHF1ZXN0aW9uIG9m ICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UNCj4gdGhlaXINCj4gPj4+PiBIVw0KPiA+ Pj4+PiBzdXBwbGllcihzKSB0byBtYWtlIGFwcHJvcHJpYXRlIGNoYW5nZXMgaW4gdGhlaXIgZXF1 aXBtZW50IHRvDQo+ID4+IGFjaGlldmUNCj4gPj4+PiB0aGVpcg0KPiA+Pj4+PiBidXNpbmVzcyBn b2Fscy4gIDotKSAgSG93ZXZlciwgdGhpcyBtYXkgbm90IGV2ZW4gYmUgbmVjZXNzYXJ5IC4uLg0K PiA+PiBzZWUNCj4gPj4+PiBiZWxvdy4NCj4gPj4+Pg0KPiA+Pj4+IENvdWxkIHlvdSBwbGVhc2Ug YnJpZWZseSBleHBsYWluIGhvdyB0byBtYWtlIHRoZSBhYm92ZSBjaGFuZ2UgaW4NCj4gPj4+PiBF WElTVElORyBoYXJkd2FyZSBvZiBhbHJlYWR5IGRlcGxveWVkIGNvcmUgcm91dGVycz8NCj4gPj4+ Pg0KPiA+Pj4+Pj4gSW4gY29udHJhc3QsIG1vc3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBh bHJlYWR5IGNhcGFibGUgb2YNCj4gPj4+PiBiYWxhbmNpbmcgSVANCj4gPj4+Pj4gdHJhZmZpYyBm bG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFja2V0cy4N Cj4gPj4gQnkNCj4gPj4+PiB1c2luZyB0aGUNCj4gPj4+Pj4gTVBMUy1pbi1VRFAgZW5jYXBzdWxh dGlvbiwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nDQo+ID4+Pj4gY2FwYWJp bGl0eSBvZg0KPiA+Pj4+PiBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJh Z2VkIHdpdGhvdXQgcmVxdWlyaW5nIGFueQ0KPiA+Pj4+IGNoYW5nZSB0bw0KPiA+Pj4+PiB0aGVt LiBUaGF0IGlzIHRoZSBtYWpvciBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQuDQo+ID4+Pj4+DQo+ ID4+Pj4+IElmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBub3QgZW5jYXBzdWxhdGUgdGhl IHRyYWZmaWMgaW4NCj4gPj4+PiBNUExTL0wyVFB2Mywgd2hpY2gNCj4gPj4+Pj4gdXNlcyBVRFAv SVAsIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gPj4+Pg0KPiA+Pj4+IElmIEkgdW5kZXJzdGFuZCBp dCBjb3JyZWN0bHksIHlvdSBwcmVmZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLQ0KPiA+PiBV RFANCj4gPj4+PiBpbnN0ZWFkIG9mIE1QTFMtaW4tVURQLCByaWdodD8NCj4gPj4+Pg0KPiA+Pj4+ PiBJTUhPLCBhIGJldHRlciBwcm9wb3NhbCBtYXkgYmUgdG8gY29uc2lkZXIgYSBbbWlub3JdICg/ KSBjaGFuZ2UNCj4gdG8NCj4gPj4+PiBSRkMgMzkzMSwNCj4gPj4+Pj4gd2hpY2ggd291bGQgYWxs b3cgdGhlIGNvbm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QNCj4gY29udHJvbA0K PiA+Pj4+IHBhY2tldHMpDQo+ID4+Pj4+IHRvIHVzZSBhIHZhcnlpbmcgc2V0IG9mIHNvdXJjZSBw b3J0cyAob3IsIHNvdXJjZSBJUCBhZGRyZXNzZXMpLA0KPiA+PiBiYXNlZA0KPiA+Pj4+IG9uIGEg aGFzaA0KPiA+Pj4+PiBjYWxjdWxhdGlvbiwgdG8gYWNoaWV2ZSBiZXR0ZXIgbG9hZC1iYWxhbmNp bmcgb3ZlciBleGlzdGluZw0KPiA+PiBlcXVpcG1lbnQNCj4gPj4+PiBpbiBhbg0KPiA+Pj4+PiBJ UC1vbmx5IGNvcmUuICBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJl dHRlcg0KPiBvZmYNCj4gPj4+PiBqdXN0IHVzaW5nDQo+ID4+Pj4+IHRoZSAiU2Vzc2lvbiBJRCIg KGFuZCAiQ29va2llIikgZmllbGRzIGFzIHRoZSBkZW11bHRpcGxleG9yIHRvDQo+ID4+Pj4gYXNz b2NpYXRlDQo+ID4+Pj4+IGluY29taW5nIHBhY2tldHMgd2l0aCB0aGUgYXNzb2NpYXRlZCBMMlRQ IENvbnRyb2wgQ2hhbm5lbC4gIEluDQo+IGZhY3QsDQo+ID4+Pj4gaXQncyBub3QNCj4gPj4+Pj4g Y2xlYXIgdG8gbWUgdGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBk byB0aGlzLA0KPiA+Pj4+IG1ha2luZyBhbnkNCj4gPj4+Pj4gImNoZWNrIiBvbiB0aGUgaW5jb21p bmcgc291cmNlIHBvcnQgdW5uZWNlc3NhcnkgZm9yIEwyVFAgZW5kLQ0KPiBzeXN0ZW0NCj4gPj4+ Pj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgYmVhdXR5IG9mIHRoZSBh Ym92ZSBhcHByb2FjaCBpczoNCj4gPj4+Pj4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92 ZSBpcyBtb3N0IGxpa2VseSBhIGNoYW5nZSB0aGF0IGlzDQo+ID4+Pj4gbGltaXRlZCB0byB0aGUN Cj4gPj4+Pj4gImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBvZiBleGlzdGluZyBMMlRQIGVu ZC1zeXN0ZW0NCj4gPj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+Pj4+IEhlY2ssIGl0IG1heSBl dmVuIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgTDJUUHYzDQo+ID4+Pj4+ IGltcGxlbWVudGF0aW9ucy4gIChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxkIG5lZWQgdG8gY29t bWVudCBvbg0KPiA+PiB0aGF0KS4NCj4gPj4+Pg0KPiA+Pj4+IElNSE8sIG5vIG1hdHRlciBNUExT LWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsICB0aGUNCj4gaGFyZHdhcmUNCj4gPj4g b2YNCj4gPj4+PiBQRSByb3V0ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdyZXNz IFBFIHJvdXRlcnMgbmVlZCB0bw0KPiA+PiBmaWxsDQo+ID4+Pj4gaW4gYW4gZW50cm9weSB2YWx1 ZSBpbiB0aGUgc291cmNlIHBvcnQgZmllbGQgb2YgVURQIGhlYWRlcnMuDQo+ID4+Pj4NCj4gPj4+ Pj4gMikgVGhlcmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBieSB1 c2luZw0KPiAiU2Vzc2lvbg0KPiA+Pj4+IElEIiBhbmQNCj4gPj4+Pj4gIkNvb2tpZSIgZmllbGRz IHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZA0KPiA+PiBm b3INCj4gPj4+PiB0aGUNCj4gPj4+Pj4gaWRlbnRpZmllZCBzZXNzaW9uLiAgUXVvdGluZyBmcm9t IFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOg0KPiA+Pj4+PiAtLS1zbmlwLS0tDQo+ID4+Pj4+ICBM MlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAzMi1i aXQNCj4gPj4+PiBTZXNzaW9uDQo+ID4+Pj4+ICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVy LiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KPiA+Pj4+PiAgKGRlc2NyaWJlZCBp biBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8NCj4gPj4gZW5z dXJlDQo+ID4+Pj4+ICB0aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhl IGlkZW50aWZpZWQgc2Vzc2lvbi4NCj4gPj4+Pj4gIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRo IHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhDQo+ID4+Pj4gZ3VhcmFudGVlDQo+ID4+ Pj4+ICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVyZm9ybWVkIHByb3Blcmx5IGFu ZCB0aGF0IHRoZQ0KPiA+Pj4+PiAgU2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0ZWQg aW4gdHJhbnNpdC4NCj4gPj4+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4+PiAuLi4gaW4gcmVnYXJkIHRv IHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYQ0KPiA+PiBmb2xr cw0KPiA+Pj4+IGhhdmUsIGluIHRoZQ0KPiA+Pj4+PiBwYXN0LCBoYWQgL3N1YnN0YW50aWFsLyBj b25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9uIG9mIE1QTFMgb3Zlcg0KPiA+PiBJUA0KPiA+Pj4+ IHRyYW5zcG9ydC4NCj4gPj4+Pj4gSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGlu IFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZg0KPiA+PiBSRkMNCj4gPj4+PiA0NjY1Lg0KPiA+ Pj4+PiAoVGhlcmUncyBsaWtlbHkgc2ltaWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhh dCB1c2UgTVBMUw0KPiBmb3INCj4gPj4+PiB0cmFuc3BvcnQpLg0KPiA+Pj4+PiBXaGlsZSBJJ20g bm90IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0K PiA+Pj4+IGRhaWx5IHRyYWZmaWMgb24NCj4gPj4+Pj4gdGhlIE1QTFMgV0cgbWFpbGluZyBsaXN0 LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0aGlzIGNvbmNlcm4gd2lsbA0KPiA+Pj4+IGFyaXNlIGlm L3doZW4gdGhpcw0KPiA+Pj4+PiBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KPiA+Pj4+DQo+ ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhlIHJlYXNvbiBmb3IgeW91ciBw cmVmZXJlbmNlIG9mDQo+ID4+IE1QTFMtDQo+ID4+Pj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0 IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0eSBmZWF0dXJlLiBJZiB0aGF0DQo+ID4+IGlzDQo+ID4+ Pj4gc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxhaW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBt b3JlIHBvcHVsYXINCj4gPj4gdGhhbg0KPiA+Pj4+IE1QTFMtaW4tTDJUUCBpbiBwcmFjdGljZT8N Cj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+PiBYaWFvaHUNCj4gPj4+Pg0KPiA+ Pj4+PiAzKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5c3Rl bXMgdGhhdA0KPiA+PiBpbXBsZW1lbnQNCj4gPj4+PiBMMlRQLCBmb3INCj4gPj4+Pj4gdHVubmVs aW5nIG9mIE1QTFMvSVAsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFuIGVudGlyZSBpbmR1c3RyeSB0 bw0KPiA+Pj4+IHN1cHBvcnQNCj4gPj4+Pj4gTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVp ciBwcm9kdWN0IGxpbmVzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtc2hhbmUNCj4gPj4+Pj4NCj4gPj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUNCj4g Pj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3Zl ciBJUCwgdGhlbiBjbGVhcmx5IGl0DQo+ID4+IHdvdWxkDQo+ID4+Pj4gaGF2ZQ0KPiA+Pj4+PiBi ZWVuDQo+ID4+Pj4+Pj4gbW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRv cnMsIHdpdGggZWl0aGVyIE1QTFMNCj4gPj4+PiBvdmVyDQo+ID4+Pj4+IEdSRSBvcg0KPiA+Pj4+ Pj4+IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3 YXkpLiAgSQ0KPiA+PiB3b3VsZA0KPiA+Pj4+IG5vdGUNCj4gPj4+Pj4gdGhhdA0KPiA+Pj4+Pj4+ IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBh cmUNCj4gPj4gc2V2ZXJhbCwNCj4gPj4+PiBwcmFjdGljYWwNCj4gPj4+Pj4+PiBvcGVyYXRpb25h bCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdvaW5nIHdpdGggbmF0aXZlIE1QTFMNCj4gPj4+Pj4+ PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4gdGhlIGRhdGEgcGxhbmUsIG5hbWVseToN Cj4gPj4+Pj4+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0ZQ0KPiA+Pj4+Pj4+IC0gTVBMUyBUcmFmZmlj IEVuZ2luZWVyaW5nDQo+ID4+Pj4+Pj4gLi4uIHRvIG5hbWUsIGJ1dCBhIGZldy4gIFRob3NlIGhh dmUgdGVuZGVkIHRvIGJlIHF1aXRlDQo+IGNvbXBlbGxpbmcNCj4gPj4+Pj4gYXJndW1lbnRzDQo+ ID4+Pj4+Pj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3Vs YXRpb24vc3dpdGNoaW5nLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gLXNoYW5lDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtSm9zaA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJy b2FkY29tLmNvbT4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBGb3Ig c2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdhY3kgYW5kIHRoZXJl DQo+ID4+IGlzDQo+ID4+Pj4gbm8gbmVlZA0KPiA+Pj4+Pj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6 MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4+Pj4+IHdyb3RlOg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXIt SVANCj4gPj4+PiBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0 ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gPj4+PiB0aG9zZQ0K PiA+Pj4+Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5n IE1QTFMNCj4gYXBwbGljYXRpb24NCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+Pj4+Pj4gYWNyb3Nz IElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4g Pj4gYW5kDQo+ID4+Pj4+IFZYTEFODQo+ID4+Pj4+Pj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBh ZHZvY2F0b3JzIGFuZCB1c2UgY2FzZXMuIElmIHlvdQ0KPiA+PiBhYnNvbHV0ZWx5DQo+ID4+Pj4g YmVsaWV2ZQ0KPiA+Pj4+Pj4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1Q TFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPiA+Pj4+IGFjcm9zcyBJUA0KPiA+Pj4+Pj4+Pj4+IG5l dHdvcmtzIGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMN Cj4gPj4gb3Zlcg0KPiA+Pj4+IElQDQo+ID4+Pj4+Pj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMg c2hvdWxkIGJlIG1vdmVkIHRvIEhpc3RvcmljIHN0YXR1cywNCj4gPj4gcGxlYXNlDQo+ID4+Pj4g c2F5DQo+ID4+Pj4+IHNvLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQnkgdGhlIHdheSwg aXQgc2VlbXMgdGhpcw0KPiA+Pj4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ ID4+Pj4gYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+Pj4+ Pj4+Pj4ganVzdCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUg Zm9sbG93aW5nDQo+ID4+Pj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBv ciBub3QgTVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+ID4+Pj4gY2VudGVy cykuIEkNCj4gPj4+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhh dCB0aW1lLiBTYWRseSwNCj4gPj4+PiBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+Pj4+Pj4+Pj4g dGlsbCBub3cuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRl bmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ PiBYaWFvaHUNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0N Cj4gPj4+Pj4+Pj4+Pj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+ILT6DQo+ID4+Pj4gse0NCj4gPj4+Pj4+PiBTLg0KPiA+ Pj4+Pj4+Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNcjV IDEzOjM0DQo+ID4+Pj4+Pj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+Pj4+Pj4+Pj4+ PiCzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9y ZzsNCj4gPj4+Pj4+Pj4+Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+ Pj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFr ZQ0KPiA+Pj4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiA+Pj4+Pj4+Pj4+PiBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4g SSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGlu DQo+ID4+Pj4gdG9kYXkncw0KPiA+Pj4+Pj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4gPj4+Pj4+Pj4+ Pj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGlj YWwNCj4gPj4+PiBhcHBsaWNhdGlvbg0KPiA+Pj4+Pj4+Pj4+PiBpbiBpbiBkYXRhDQo+ID4+Pj4+ Pj4+Pj4+IGNlbnRlciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRp b25zIHN1Y2gNCj4gYXMNCj4gPj4+PiBOVkdSRQ0KPiA+Pj4+PiBhbmQNCj4gPj4+Pj4+Pj4+Pj4g VlhMQU4uDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3Jz IGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uDQo+ID4+Pj4gc2VsZWN0aW9u DQo+ID4+Pj4+Pj4+Pj4+IHByb2Nlc3MNCj4gPj4+Pj4+Pj4+Pj4gYnkgYWR2YW5jaW5nIHRoZSBk cmFmdCBpbiBNUExTIFdHLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0K PiA+Pj4+Pj4+Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9h QHBpLm51Pg0KPiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFdvcmtpbmcg Z3JvdXAsDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyB0byBzdGFydCBh ICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+Pj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBs cy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pj4+Pj4+ Pj4+Pj4gRHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5k ZWQgd2l0aA0KPiA+Pj4+IG9uZSB3ZWVrLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZQ0K PiBtcGxzDQo+ID4+Pj4+IHdvcmtpbmcNCj4gPj4+Pj4+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlz dCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuDQo+ID4+Pj4gdGVjaG5pY2FsDQo+ ID4+Pj4+Pj4+Pj4+PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVz cGVjaWFsbHkgaWYgeW91DQo+ID4+Pj4gdGhpbmsgdGhhdA0KPiA+Pj4+Pj4+Pj4+Pj4gdGhlIGRv Y3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gPj4+PiBk b2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBK YW51YXJ5IDA3LCAyMDEzLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFRoZXJlIGlz IG9uZSBJUFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4gPj4+Pj4+Pj4+Pj4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhl IHdvcmtpbmcgZ3JvdXANCj4gPj4+PiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IHRoYXQg dGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UNCj4g Pj4+PiBhbHJlYWR5DQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0 aGF0IHdlIHVzZWQgZm9yDQo+ID4+IHRoZQ0KPiA+Pj4+IElQUg0KPiA+Pj4+Pj4+Pj4+Pj4gcG9s bCkNCj4gPj4+Pj4+Pj4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2Yg dGhlIGF1dGhvcnMuDQo+IE1hcnNoYWxsDQo+ID4+Pj4gaGFzDQo+ID4+Pj4+Pj4+Pj4+PiBkaXNj b250aW51ZWQgYWxsIGludGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+ ID4+Pj4gYXV0aG9yIHRlYW0NCj4gPj4+Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRw LTA2LiBUaGUgd29ya2luZyBncm91cCBjaGFpcnMgaGFzDQo+ID4+Pj4gdHJpZWQgdG8NCj4gPj4+ Pj4+Pj4+Pj4+IGNvbnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSBy ZXNwb25zZSBvbg0KPiA+PiB0aGUNCj4gPj4+PiBJUFINCj4gPj4+Pj4+Pj4+Pj4+IHBvbGwuDQo+ ID4+Pj4+Pj4+Pj4+PiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4+Pj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVk IHRvIHJlbW92ZSBNYXJzaGFsbCBhcw0KPiBhDQo+ID4+Pj4+Pj4+Pj4+PiBjby1hdXRob3IuDQo+ ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gL0xvYQ0KPiA+Pj4+Pj4+Pj4+Pj4gKG1wbHMg d2cgY28tY2hhaXIpDQo+ID4+Pj4+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOg0KPiA+Pj4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KPiA+ Pj4+Pj4+Pj4+Pj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAg bG9hQHBpLm51DQo+ID4+Pj4+Pj4+Pj4+PiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAg ICAgICAgIHBob25lOiArNDYgMTAgNzE3IDUyDQo+ID4+IDEzDQo+ID4+Pj4+Pj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyIDEzDQo+ID4+ Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IG1wbHNA aWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+ Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxp c3QNCj4gPj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4gbXBscyBtYWls aW5nIGxpc3QNCj4gPj4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lcg0KPiA+Pj4+IENhYmxlDQo+ID4+Pj4+Pj4gcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4gPj4+ PiBzdWJqZWN0IHRvDQo+ID4+Pj4+Pj4gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMNCj4gaW50ZW5kZWQNCj4gPj4+PiBzb2xlbHkgZm9yDQo+ ID4+Pj4+IHRoZQ0KPiA+Pj4+Pj4+IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZg0KPiB5b3UNCj4gPj4+PiBhcmUgbm90IHRoZQ0KPiA+ Pj4+Pj4+IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdA0KPiA+Pj4+IGFueQ0KPiA+Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPiA+Pj4+ Pj4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRv IHRoZQ0KPiA+PiBjb250ZW50cw0KPiA+Pj4+IG9mIGFuZA0KPiA+Pj4+Pj4+IGF0dGFjaG1lbnRz IHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KPiA+Pj4+ IHVubGF3ZnVsLiBJZiB5b3UNCj4gPj4+Pj4+PiBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4gPj4+PiBpbW1lZGlhdGVseSBhbmQN Cj4gPj4+Pj4+PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQNCj4gPj4+PiBhbnkgcHJpbnRvdXQuDQo+ID4+Pj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+IG1w bHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pg0KPiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG1wbHMg bWFpbGluZyBsaXN0DQo+ID4+PiBtcGxzQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From cpignata@cisco.com Thu Dec 20 10:29:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65AC21F8906 for ; Thu, 20 Dec 2012 10:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.823 X-Spam-Level: X-Spam-Status: No, score=-106.823 tagged_above=-999 required=5 tests=[AWL=-3.667, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_BELOW=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01d3L0RHkTXX for ; Thu, 20 Dec 2012 10:29:40 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 09EFD21F88E1 for ; Thu, 20 Dec 2012 10:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59356; q=dns/txt; s=iport; t=1356028180; x=1357237780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UnB/EyDKKJir69oo45qNDhAPDBhkjVPIw+0D2AsvGno=; b=mlZ1mXnmAZLIUXe4iKUsFstaZ3fCr3FXat16BJ8QEQVDzC6biVZb0WYP veqzeXxRamYA2/IDGOYuZZierXPs6n0lkpk9lwDIFLXiaHdPXs1aDfOYn SqlQ6iSv1uqVN02xDhN95a0UpZQ8sZyvNS3eLBN8DWu7ZUyAbSOr3wa0/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQGANNX01CtJV2b/2dsb2JhbABFhjqCX6tIAYZTgU9uFnOCHwEBBAEBARcBDEAHBAIFDgICAQYCEhAWAQYFAgIZDAsUAw4CBAENBQgBEod4DItPmm8IkxcEjE4LCgYNgwQ2YQOSHjqET48sgS+BRYFkAgcXHg X-IronPort-AV: E=Sophos;i="4.84,326,1355097600"; d="scan'208,217";a="155188320" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Dec 2012 18:29:38 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBKITctR009734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 18:29:38 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 12:29:38 -0600 From: "Carlos Pignataro (cpignata)" To: Shane Amante , Xuxiaohu Thread-Topic: Discussion on how to transport MPLS over UDP tunnels Thread-Index: AQHN3praOrGtZ2VkdEWwxZAmFPQPvZgiRR4AgAAiL4A= Date: Thu, 20 Dec 2012 18:29:37 +0000 Message-ID: <95067C434CE250468B77282634C96ED32281143B@xmb-aln-x02.cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-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: [10.150.52.103] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED32281143Bxmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Discussion on how to transport MPLS over UDP tunnels X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:29:43 -0000 --_000_95067C434CE250468B77282634C96ED32281143Bxmbalnx02ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgaW5saW5lIGEgY291cGxlIG9mIHRlY2huaWNhbCBjb21tZW50cyBvbiB0aGlz IGFkZGl0aW9uYWwgcHJvcG9zYWwuDQoNCk9uIERlYyAyMCwgMjAxMiwgYXQgMTE6MjcgQU0sIFNo YW5lIEFtYW50ZSA8c2hhbmVAY2FzdGxlcG9pbnQubmV0PG1haWx0bzpzaGFuZUBjYXN0bGVwb2lu dC5uZXQ+PiB3cm90ZToNCg0KSGkgWGlhb2h1LA0KDQpPbiBEZWMgMjAsIDIwMTIsIGF0IDM6MTMg QU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWku Y29tPj4gd3JvdGU6DQpIaSBTaGFuZSwNCg0KVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIgY29tbWVu dHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0KDQpOb3RlOiBJIGNoYW5nZWQg dGhlIHN1YmplY3QgbGluZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi4NCg0KLS0tLS3T yrz+1K28/i0tLS0tDQq3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBv aW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCreiy83KsbzkOiAyMDEyxOox MtTCMTnI1SAyMjozOA0KytW8/sjLOiBYdXhpYW9odQ0Ks63LzTogUm9nZXJzLCBKb3NoOyBTaGFo cmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsNCm1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQrW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdl IGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQptcGxzIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQNCg0KWGlhb2h1LA0KDQpPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUw IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFNoYW5lIEFtYW50ZSBb bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0 Pl0NCreiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KytW8/sjLOiBSb2dlcnMsIEpvc2gN CrOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsN Cm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQrW98ziOiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMt aW4tdWRwDQphbg0KbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQoNCg0KT24gRGVjIDE4LCAy MDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208 bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCndyb3RlOg0KSSBzaGFyZSB5b3VyIFNQ IHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzIHNvbHV0aW9uDQph ZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCg0KKzEuICBQbGVhc2UgZG8gbm90IGRl ZmluZSB5ZXQgYW5vdGhlciBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbi4gIFRoZQ0KSUVURg0K YWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvIHN0 YW5kYXJkaXplZA0KTVBMUw0Kb3ZlciBMMlRQdjMvVURQL0lQLCB3aGljaCBoYWQgc2VlbiBzb21l IGRlcGxveW1lbnQgaW4gYXQgbGVhc3Qgb25lLCB2ZXJ5DQpsYXJnZSBvcGVyYXRvciBuZXR3b3Jr IHRoYXQgSSdtIGF3YXJlIG9mIHRvIHN1cHBvcnQgY2FycmlhZ2Ugb2YgTDNWUE4gb3Zlcg0KYW4N CklQLW9ubHkgbmV0d29yay4NCg0KSGkgU2hhbmUsDQoNClRoYW5rIHlvdSBmb3IgdGVsbGluZyB1 cyB0aGVyZSBhcmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3ZlciBJUCBpbiBhdA0KbGVh c3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZl cnkgdmFsdWFibGUgdG8gdGhvc2UNCnBlb3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5v IGFwcGxpY2F0aW9uIG9mIE1QTFMgb3ZlciBJUCBpbiB0b2RheSdzIFNQDQpuZXR3b3Jrcy4NCg0K U2VlOiBSRkMncyA0NDU0LCA0NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYzDQpb Tk9URTogdGhlIGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUg MjAwNg0KdGltZWZyYW1lIV0NCiAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50cyByZWxhdGVkIHRv IFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBiZQ0KY2FycmllZCBvdmVyIEwyVFB2Mw0KICBB bmQsIGhlcmUncyBldmlkZW5jZSBzaG93aW5nIHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMN CmltcGxlbWVudGVkDQpJUFZQTidzIG92ZXIgTDJUUHYzOg0KaHR0cDovL3d3dy5jaXNjby5jb20v ZW4vVVMvZG9jcy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQoNClRoYW5r cyBhZ2FpbiBmb3Igc2hhcmluZyB0aGUgYWJvdmUgaW5mb3JtYXRpb24uIEFzIG1lbnRpb25lZCBp biB0aGlzIGRyYWZ0DQpBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1p bmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgU2Vzc2lvbg0KSUQgZmllbGQgaW4gdGhlIEwyVFB2 MyBoZWFkZXIgb3IgdGhlIEtleSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciBhcyBkZWZpbmVkIGlu DQpbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0aW5nIGNvcmUgcm91 dGVycyBzbyBmYXIuDQoNCkZXSVcsIEkgaGF2ZSBoYWQgc3VjY2VzcywgaW4gdGhlIHJlbGF0aXZl bHkgcmVjZW50IHBhc3QsIGluIHJlcXVlc3RpbmcgYSBjb3JlDQpyb3V0ZXIgdmVuZG9yIHRvIHN1 cHBvcnQgY2hhbmdlcyB0byB0aGUgaW5wdXQta2V5cyB1c2VkIGluIGhhc2ggY2FsY3VsYXRpb25z IGluDQpfZXhpc3RpbmdfIGhhcmR3YXJlLCBhbHJlYWR5IGRlcGxveWVkIChleHRlbnNpdmVseSkg dGhyb3VnaG91dCBteSBuZXR3b3JrLg0KRnVydGhlciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJn ZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3MgYW5kDQp1bmRlcnN0YW5kIHRoZSBp bnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuICBBcyBhIHJlc3Vs dCwgdGhvc2UNCnNhbWUgb3BlcmF0b3JzIGtub3cgd2hhdCBpcyBhbmQgaXMgbm90IHRlY2huaWNh bGx5IHBvc3NpYmxlIGluIHRoaXMgcmVnYXJkLg0KVGh1cywgaXQgbWF5IGJlIGEgcXVlc3Rpb24g b2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVpciBIVw0Kc3VwcGxpZXIocykg dG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0byBhY2hpZXZl IHRoZWlyDQpidXNpbmVzcyBnb2Fscy4gIDotKSAgSG93ZXZlciwgdGhpcyBtYXkgbm90IGV2ZW4g YmUgbmVjZXNzYXJ5IC4uLiBzZWUgYmVsb3cuDQoNCkNvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBl eHBsYWluIGhvdyB0byBtYWtlIHRoZSBhYm92ZSBjaGFuZ2UgaW4gRVhJU1RJTkcgaGFyZHdhcmUg b2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/DQoNCkZpcm13YXJlIHVwZ3JhZGVzPw0K DQoNCkluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBj YXBhYmxlIG9mIGJhbGFuY2luZyBJUA0KdHJhZmZpYyBmbG93cyBiYXNlZCBvbiB0aGUgaGFzaCBv ZiB0aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFja2V0cy4gQnkgdXNpbmcgdGhlDQpNUExTLWluLVVE UCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmcgY2Fw YWJpbGl0eSBvZg0KbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3 aXRob3V0IHJlcXVpcmluZyBhbnkgY2hhbmdlIHRvDQp0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBt b3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdo eSBub3QgZW5jYXBzdWxhdGUgdGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoDQp1c2Vz IFVEUC9JUCwgaW4gdGhlIGZpcnN0IHBsYWNlPw0KDQpJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVj dGx5LCB5b3UgcHJlZmVyIHRvIHVzZSBNUExTLWluLUwyVFB2My1pbi1VRFAgaW5zdGVhZCBvZiBN UExTLWluLVVEUCwgcmlnaHQ/DQoNCkFjdHVhbGx5LCBteSBmaXJzdCBwcmVmZXJlbmNlIHdvdWxk IGJlIG5hdGl2ZSBNUExTIHN3aXRjaGluZyBlZGdlLXRvLWVkZ2UsICh3aGljaCBtZWFucyBlbmFi bGluZyBNUExTIHRocm91Z2hvdXQgdGhlIG5ldHdvcmspLiAgTXkgc2Vjb25kIHByZWZlcmVuY2Ug d291bGQgYmUgdGhhdCBmb3IgdGhlIGNhc2VzIHdoZXJlIHRoYXQncyBpbXByYWN0aWNhbCB0byB1 c2UgbmF0aXZlIE1QTFMgc3dpdGNoaW5nIGVuZC10by1lbmQsIHRoZW4gKGVkZ2UpIGRldmljZXMg LS0gbm90IG5lY2Vzc2FyaWx5IHJvdXRlcnMsIChzZWUgYmVsb3cpIC0tIHdvdWxkIGhhdmUgdG8g cGVyZm9ybSBNUExTLWluLUwyVFB2My1pbi1VRFAgZW5jYXBzdWxhdGlvbi9kZS1lbmNhcHN1bGF0 aW9uLg0KDQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBhIFtt aW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwNCndoaWNoIHdvdWxkIGFsbG93IHRoZSBjb25u ZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFja2V0cyAobm90IGNvbnRyb2wgcGFja2V0cykNCnRvIHVz ZSBhIHZhcnlpbmcgc2V0IG9mIHNvdXJjZSBwb3J0cyAob3IsIHNvdXJjZSBJUCBhZGRyZXNzZXMp LCBiYXNlZCBvbiBhIGhhc2gNCmNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2FkLWJh bGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbg0KSVAtb25seSBjb3JlLg0KDQpZ b3UgbWVudGlvbiBSRkMgMzkzMSAtLSBMMlRQdjMgZGVmaW5lcyBMMlRQIGRpcmVjdGx5IG92ZXIg SVAgKElQIFByb3RvY29sIG51bWJlciAxMTUpIGFzIGEgTVVTVCwgYW5kIEwyVFAgb3ZlciBVRFAg YXMgYSBTSE9VTEQuIEltcGxlbWVudGF0aW9ucyBtaWdodCBub3Qgc3VwcG9ydCBMMlRQdjMgb3Zl ciBVRFAuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5MzEjc2VjdGlvbi00LjEN Cg0KICAgTDJUUCBtYXkgb3BlcmF0ZSBvdmVyIGEgdmFyaWV0eSBvZiBQU05zLiAgVGhlcmUgYXJl IHR3byBtb2Rlcw0KICAgZGVzY3JpYmVkIGZvciBvcGVyYXRpb24gb3ZlciBJUCwgTDJUUCBkaXJl Y3RseSBvdmVyIElQIChzZWUgU2VjdGlvbjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMz OTMxI3NlY3Rpb24tNC4xLjE+DQogICA0LjEuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzOTMxI3NlY3Rpb24tNC4xLjE+KSBhbmQgTDJUUCBvdmVyIFVEUCAoc2VlIFNlY3Rpb24gNC4x LjI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzkzMSNzZWN0aW9uLTQuMS4yPikuICBM MlRQdjMgaW1wbGVtZW50YXRpb25zDQogICBNVVNUIHN1cHBvcnQgTDJUUCBvdmVyIElQIGFuZCBT SE9VTEQgc3VwcG9ydCBMMlRQIG92ZXIgVURQIGZvciBiZXR0ZXINCiAgIE5BVCBhbmQgZmlyZXdh bGwgdHJhdmVyc2FsLCBhbmQgZm9yIGVhc2llciBtaWdyYXRpb24gZnJvbSBMMlRQdjIuDQoNCiBM MlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmYganVzdCB1 c2luZw0KdGhlICJTZXNzaW9uIElEIiAoYW5kICJDb29raWUiKSBmaWVsZHMgYXMgdGhlIGRlbXVs dGlwbGV4b3IgdG8gYXNzb2NpYXRlDQppbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0 ZWQgTDJUUCBDb250cm9sIENoYW5uZWwuICBJbiBmYWN0LCBpdCdzIG5vdA0KY2xlYXIgdG8gbWUg dGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLCBtYWtp bmcgYW55DQoiY2hlY2siIG9uIHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBm b3IgTDJUUCBlbmQtc3lzdGVtDQppbXBsZW1lbnRhdGlvbnMuDQoNCkFsc28sIEwyVFB2MyAob3Zl ciBhbnkgUFNOKSB1c2VzIHRoZSBTZXNzaW9uIElEIGFzIHRoZSBzZXNzaW9uIGRlbXVsdGlwbGV4 ZXIgKHRoZSBDb29raWUgaXMgbm90IGEgZGVtdXgpOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMzOTMxI3BhZ2UtMjcNCg0KICAgSXQgaXMgaW1wb3J0YW50IGZvciBpbXBsZW1lbnRl cnMgdG8NCiAgIG5vdGUgdGhhdCB0aGUgQ29va2llIGZpZWxkIGNoZWNrIG9jY3VycyBhZnRlciBs b29raW5nIHVwIHRoZSBzZXNzaW9uDQogICBjb250ZXh0IGJ5IHRoZSBTZXNzaW9uIElELCBhbmQg YXMgc3VjaCwgY29uc2lzdHMgbWVyZWx5IG9mIGEgdmFsdWUNCiAgIG1hdGNoIG9mIHRoZSBDb29r aWUgZmllbGQgYW5kIHRoYXQgc3RvcmVkIGluIHRoZSByZXRyaWV2ZWQgY29udGV4dC4NCiAgIFRo ZXJlIGlzIG5vIG5lZWQgdG8gcGVyZm9ybSBhIGxvb2t1cCBhY3Jvc3MgdGhlIFNlc3Npb24gSUQg YW5kIENvb2tpZQ0KICAgYXMgYSBzaW5nbGUgdmFsdWUuDQoNCkFuZCB0aGUgU2Vzc2lvbiBJRCBh c3NvY2lhdGVzIGNvbnRleHQgd2l0aCBhIFNlc3Npb24sIG5vdCB3aXRoIGEgQ29udHJvbCBDaGFu bmVsLiBUSGUgVURQICJjb25uZWN0aW9uIiBhc3NvY2lhdGVzIHdpdGggdGhlIENvbnRyb2wgQ29u bmVjdGlvbjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5MzEjc2VjdGlvbi00LjEu Mi4yDQoNCg0KDQpUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCjEpIEkgd291 bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcyBs aW1pdGVkIHRvIHRoZQ0KImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBvZiBleGlzdGluZyBM MlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KSGVjaywgaXQgbWF5IGV2ZW4gYmUgYmFj a3dhcmRzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBMMlRQdjMNCmltcGxlbWVudGF0aW9ucy4g IChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxkIG5lZWQgdG8gY29tbWVudCBvbiB0aGF0KS4NCg0K SU1ITywgbm8gbWF0dGVyIE1QTFMtaW4tTDJUUHYzLWluLVVEUCBvciBNUExTLWluLVVEUCwgIHRo ZSBoYXJkd2FyZSBvZiBQRSByb3V0ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdy ZXNzIFBFIHJvdXRlcnMgbmVlZCB0byBmaWxsIGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhlIHNv dXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KDQpJIHN1cHBvc2UgdGhlIGFuc3dlciBp cyAiaXQgZGVwZW5kcyIgb24gdGhlIEhXIGFyY2hpdGVjdHVyZSBvZiBQRSdzIC0tIE5QVSB2cy4g QVNJQyAtLSBhbmQgd2hldGhlciBvbmUgbmVlZHMgIlBFJ3MiIGluIHRoZSB0cmFkaXRpb25hbCBz ZW5zZSwgYXMgd2VsbC4gIEFzIG9uZSBleGFtcGxlLCB0aGVyZSBpcyB0aGUgZm9sbG93aW5nIG9w ZW4gc291cmNlIGltcGxlbWVudGF0aW9uIG9mIEwyVFA6DQpodHRwOi8vd3d3Lm9wZW5sMnRwLm9y Zw0KDQpOb3RlIHRoYXQgdGhlIE9wZW5MMlRQIHByb2plY3QgaW1wbGVtZW50cyBMMlRQdjIsIFJG QzI2NjEuDQoNCkFzIHRoYXQgV2ViIHBhZ2Ugbm90ZXMsIE9wZW5MMlRQIGhhcyBiZWVuIGludGVn cmF0ZWQgaW50byB0aGUgTGludXggMi42LjIzIGtlcm5lbC4gIEZXSVcsIEkgYW0gYXdhcmUgdGhh dCBNaWNyb3NvZnQgLS0gYW5kLCBvdGhlciBPcGVyYXRpbmcgU3lzdGVtcyAtLSBoYXZlIGFuIEwy VFAgc3RhY2sgZm9yIHNldmVyYWwgeWVhcnMgbm93LCAodG8gc3VwcG9ydCBMMlRQL0lQU2VjIGZv ciBWUE4ncyksIGFzIHdlbGwuDQoNClJlZ2FyZGxlc3MsIGlmIHRoZSBtYWluIGRlc2lyZSBmb3Ig TVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24gaXMgZm9yIERhdGFDZW50ZXJzIGFuZC9vciBOVk8z IC4uLiB0aGVuLCBJIHdvdWxkIHRoaW5rIGl0IHdvdWxkIGJlIHBvc3NpYmxlIHRvIGNvbnNpZGVy IC9lbmFibGluZy8gT3BlbkwyVFAgd2l0aGluIHRoZSBIeXBlcnZpc29yIG9mIHRoZSBleGlzdGlu ZyBzZXJ2ZXJzLCAoc2luY2UgdGhleSBsaWtlbHkgYWxyZWFkeSBydW4gTGludXgpLCBhbmQgeW91 IGxpa2VseSBnZXQgdGhlIGJlc3Qgb2YgYWxsIHdvcmxkczogbm8gbmVlZCB0byB1cGdyYWRlIGFu eSAiaGFyZHdhcmUiIGluIHRoZSBuZXR3b3JrLCBqdXN0IHVwZ3JhZGUgc29mdHdhcmUgKGlmIG5l Y2Vzc2FyeSEpIG9uIHlvdXIgc2VydmVycy4gIElmIEkgd2VyZSBpbiB0aGlzIHNpdHVhdGlvbiwg dGhhdCBpcyB0aGUgZGlyZWN0aW9uIEkgd291bGQgbG9vayBhdCwgc2luY2UgaXQgc2VlbXMgdGhh dCBzdWNoIEh5cGVydmlzb3IgdXBncmFkZXMgbWF5IGJlIG5lY2Vzc2FyeSBhbnl3YXksIGRlcGVu ZGluZyBvZiBjb3Vyc2Ugb24gdGhlIG91dGNvbWUgb2YgdGhlIHdvcmsgaW4gTlZPMywgYm90aCBp biBpdCdzIGNob2ljZShzKSBmb3IgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9ucyBhbmQgImNvbnRy b2wgcGxhbmUiIHNpZ25hbGluZywgYXMgd2VsbC4NCg0KDQoNCjIpIFRoZXJlIGlzIGEgc3Vic3Rh bnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdldHMgYnkgdXNpbmcgIlNlc3Npb24gSUQiIGFuZA0K IkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBp bnRlbmRlZCBmb3IgdGhlDQppZGVudGlmaWVkIHNlc3Npb24uICBRdW90aW5nIGZyb20gU2VjdGlv biA4LjIgb2YgUkZDIDM5MzE6DQotLS1zbmlwLS0tDQogTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMg c2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzItYml0IFNlc3Npb24NCiBJRCBpbiB0aGUg TDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KIChk ZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGNoZWNrIHRv IGVuc3VyZQ0KIHRoYXQgYW4gYXJyaXZpbmcgcGFja2V0IGlzIGludGVuZGVkIGZvciB0aGUgaWRl bnRpZmllZCBzZXNzaW9uLg0KIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9u IElEIHByb3ZpZGVzIGFuIGV4dHJhIGd1YXJhbnRlZQ0KIHRoYXQgdGhlIFNlc3Npb24gSUQgbG9v a3VwIHdhcyBwZXJmb3JtZWQgcHJvcGVybHkgYW5kIHRoYXQgdGhlDQogU2Vzc2lvbiBJRCBpdHNl bGYgd2FzIG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC4NCi0tLXNuaXAtLS0NCi4uLiBpbiByZWdh cmQgdG8gdGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBrbm93IHRoZSBTZWN1cml0eSBBcmVhIGZvbGtz IGhhdmUsIGluIHRoZQ0KcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5j YXBzdWxhdGlvbiBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0Lg0KSW4gZmFjdCwgdGhpcyBpcyB3 aHkgeW91IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBSRkMgNDY2NS4N CihUaGVyZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVz ZSBNUExTIGZvciB0cmFuc3BvcnQpLg0KV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkg QXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBvbg0KdGhlIE1Q TFMgV0cgbWFpbGluZyBsaXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0aGlzIGNvbmNlcm4gd2ls bCBhcmlzZSBpZi93aGVuIHRoaXMNCmRyYWZ0IGdvZXMgdG8gdGhlIElFU0cgLi4uDQoNCklmIEkg dW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5jZSBv ZiBNUExTLWluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkg ZmVhdHVyZS4gSWYgdGhhdCBpcyBzbyBjb25jZXJuZWQsIGNhbiB5b3UgZXhwbGFpbiB3aHkgTVBM Uy1pbi1HUkUgaXMgZmFyIG1vcmUgcG9wdWxhciB0aGFuIE1QTFMtaW4tTDJUUCBpbiBwcmFjdGlj ZT8NCg0KV291bGQgeW91IGNhcmUgdG8gY2l0ZSBhIHNvdXJjZSBmb3IgdGhlIGFib3ZlIGFzc2Vy dGlvbiB0aGF0IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXIgaW4gX2RlcGxveW1lbnRz XyB0aGFuIE1QTFMtaW4tTDJUUD8NCg0KKzEuDQoNCg0KUmVnYXJkbGVzcywgSSB3b3VsZCBub3Rl IHRoYXQgSUVURiBzcGVjaWZpY2F0aW9ucyBhcmUgb25seSByZWNvbW1lbmRhdGlvbnMsIGJhc2Vk IG9uIHRoZSBrbm93bGVkZ2UgYW5kIGV4cGVyaWVuY2Ugb2YgaXRzIHBhcnRpY2lwYW50cy4gIFRo ZSBJRVRGIGRvZXMgbm90IGVuZm9yY2Ugd2hhdCBvcGVyYXRvcnMgYWN0dWFsbHkgZGVwbG95IGlu IHRoZWlyIG5ldHdvcmsuICBPcGVyYXRvcnMgbWF5IG1ha2UgKGFuZCwgb2Z0ZW4gZG8gbWFrZSkg ZGlmZmVyZW50IGNob2ljZXMgdGhhbiB3aGF0IHRoZSBJRVRGIHJlY29tbWVuZHMsIGJlY2F1c2Ug b3BlcmF0b3JzIHVuZGVyc3RhbmQgdGhlaXIgbmV0d29ya3MsIHNlcnZpY2VzIGFuZCBhcHBsaWNh dGlvbnMgYmV0dGVyIGFuZCB0aGUgdHJhZGUtb2ZmcyBhbmQgdGhlIHJpc2tzIGludm9sdmVkLiAg U3BlY2lmaWNhbGx5LCBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRpc2N1c3Npb24sIGl0IG1heSBi ZSB0aGF0IE1QTFMtaW4tR1JFIGlzIG1vcmUgd2lkZWx5IHVzZWQgZHVlIHRvIGEgbnVtYmVyIG9m IGZhY3RvcnMuICBIb3dldmVyLCBvbmUgcG90ZW50aWFsIHJlYXNvbiB0aGF0IHRoZXkgbWF5IHVz ZSBNUExTLWluLUdSRSBpcyBpdCBpcyBvbmx5IHVzZWQgd2l0aGluIHRoZSBjb25maW5lcyBvZiBh IHByaXZhdGUgbmV0d29yayAoRW50ZXJwcmlzZSBMQU4vV0FOPywgSVBWUE4/KSwgdGh1cyB0aGUg X3BlcmNlcHRpb25fIG9mIHJpc2sgb2YgTWlUTSBhdHRhY2tzIC0tIHdoaWNoIGlzIHRoZSBtYWlu IGNvbmNlcm4gb2YgdXNpbmcgTVBMUy1pbi1HUkUgd2l0aG91dCBHUkUga2V5cyAtLSBpcyBjb25z aWRlcmVkIGJ5IHRoZSBvcGVyYXRvciB0byBiZSAibG93Ii4gIEZvciBiZXR0ZXIgb3Igd29yc2Us IElFVEYgcmVjb21tZW5kYXRpb25zIC9uZWVkLyB0byBjb25zaWRlciBhbGwgdHlwZXMgb2YgbmV0 d29ya3MsIGUuZy46IHB1YmxpYyBhbmQgcHJpdmF0ZSBuZXR3b3JrcywgYW5kIHRodXMgaGEhDQp2 ZSBhIHRlbmRlbmN5IHRvIHJlY29tbWVuZCBtb3JlLCByYXRoZXIgdGhhbiBsZXNzLCAic2VjdXJp dHkiIGluIHRob3NlIHJlY29tbWVuZGF0aW9ucy4NCg0KVGh1cywgKmlmKiB0aGlzIFdHIGRyYWZ0 IGlzIGFkb3B0ZWQgKGFuZCwgYmVmb3JlIGl0IGdldHMgc2VudCB0byB0aGUgSUVTRykgSSB0aGlu ayB0aGUgY28tYXV0aG9ycyBzaG91bGQgc3BlbmQgc29tZSB0aW1lIHdpdGggdGhlIFNlY3VyaXR5 IEFyZWEgdG8gdW5kZXJzdGFuZCB0aGUgY29uY2VybnMgdGhleSB3b3VsZCBtb3N0IGNlcnRhaW5s eSByYWlzZSBkdXJpbmcgdGhlIGRldmVsb3BtZW50IG9mIHRoaXMgZHJhZnQgb3IsIHdvcnNlLCBk dXJpbmcgdGhlIGZpbmFsIHN0YWdlcyBvZiBpdHMgcHVibGljYXRpb24gKElFU0cgcmV2aWV3KS4g IDotKSAgTmFtZWx5Og0KMSkgIEluIG15IHBhc3QgZXhwZXJpZW5jZSBtZXJlbHkgc2F5aW5nIHRo YXQgYSBnaXZlbiBwcm90b2NvbCBpcyBvbmx5IC9zdXBwb3NlZCB0by8gYmUgZGVwbG95ZWQgYSBn aXZlbiBlbnZpcm9ubWVudCBoYXMgbm90IGJlZW4gc3VjY2Vzc2Z1bCwgZ2l2ZW4gdGhlIHJlYXNv biBJIHN0YXRlZCBhYm92ZSAtLSB5b3UgY2FuJ3QgcHJlZGljdCB3aGVyZSBhIGdpdmVuIHRlY2hu b2xvZ3kgd2lsbCBnZXQgZGVwbG95ZWQgZHVlIHRvIG9wZXJhdG9ycyAobGlrZSBtZSA6LSkgImRp c29iZXlpbmciIChvciwgbm90IHJlYWRpbmcpIGFkdmljZSBpbiBJRVRGIGRyYWZ0cy9SRkNzLg0K MikgIFRoZSBjdXJyZW50ICJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgc2VjdGlvbiByZWNvbW1l bmRzIHVzaW5nIElQU2VjIFRyYW5zcG9ydCBNb2RlLCBidXQgbGFja3Mgc3VmZmljaWVudCBkZXRh aWxzIGJleW9uZCB0aGF0LCBuYW1lbHk6DQogICBhKSAgSVBTZWMgVHJhbnNwb3J0IE1vZGUgd2l0 aCBBSCBhbmQvb3IgRVNQPw0KICAgYikgIE1vcmUgY29uY2VybmluZyBpbiB0aGUgY29udGV4dCBv ZiB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhlIHdheSBJUFNlYyB3b3JrcyB3aWxsIGtpbGwgdGhlIGVm ZmVjdGl2ZW5lc3Mgb2YgdGhpcyBkcmFmdC4gIFNwZWNpZmljYWxseSwgeW91IG1heSB3aXNoIHRv IHJldmlldyBSRkNzIDQzMDIgYW5kIDQzMDMgKEFIIGFuZCBFU1AsIHJlc3BlY3RpdmVseSkuICBO YW1lbHksIHRoZSB3YXkgYW5kIElQU2VjIFRyYW5zcG9ydCBNb2RlIHBhY2tldCB3aWxsIGxvb2sg b24gdGhlIHdpcmUgaXMgYXMgZm9sbG93cywgKGZyb20gU2VjdGlvbnMgMy4xLjEgb2YgYm90aCBS RkNzKToNCg0KICAgICAgICAgICAgICAgICAgQUZURVIgQVBQTFlJTkcgQUgNCiAgICAgICAgICAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgICAgIElQdjQgIHxvcmlnaW5hbCBJUCBoZHIgKGFueSBvcHRpb25zKSB8IEFIIHwgVENQIHwg ICAgRGF0YSAgIHwNCiAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgIHw8LSBtdXRhYmxlIGZpZWxkIHBy b2Nlc3NpbmcgLT58PC0gaW1tdXRhYmxlIGZpZWxkcyAtPnwNCiAgICAgICAgICAgIHw8LS0tLS0g YXV0aGVudGljYXRlZCBleGNlcHQgZm9yIG11dGFibGUgZmllbGRzIC0tLS0tPnwNCg0KDQogICAg ICAgICAgICAgICAgIEFGVEVSIEFQUExZSU5HIEVTUA0KICAgICAgICAgICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgSVB2NCAgfG9yaWcg SVAgaGRyICB8IEVTUCB8ICAgICB8ICAgICAgfCAgIEVTUCAgIHwgRVNQfA0KICAgICAgICAgICAg fChhbnkgb3B0aW9ucyl8IEhkciB8IFRDUCB8IERhdGEgfCBUcmFpbGVyIHwgSUNWfA0KICAgICAg ICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0gZW5jcnlwdGlvbiAtLS0tPnwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLSBpbnRlZ3JpdHkgLS0tLS0tLT58 DQoNCkluIHN1bW1hcnksICp3aGVuKiBJUFNlYyBUcmFuc3BvcnQgTW9kZSBpcyBhcHBsaWVkLCBv bmx5IHRoZSBvdXRlcm1vc3QgMi10dXBsZSB7c3JjX2lwLCBkc3RfaXB9IHdpbGwgYmUgInJlYWRp bHkiIHZpc2libGUgdG8gaW50ZXJtZWRpYXRlIG5vZGVzLiAgVW5mb3J0dW5hdGVseSwgdGhlIG9y aWdpbmFsIChvdXRlcm1vc3QpIElQIGhlYWRlciB3aWxsIGhhdmUgSVAgcHJvdG9jb2wgNTAgb3Ig NTEgKEFIIG9yIEVTUCwgcmVzcGVjdGl2ZWx5KSBwb2ludGluZyB0aGF0IHdoYXQgaW1tZWRpYXRl bHkgZm9sbG93cyB0aGUgSVAgaGVhZGVyIGlzIGFuIEFIIG9yIEVTUCBoZWFkZXIgLi4uIHRodXMs IEkgd291bGQgYmV0IChiZXR0ZXIgeWV0LCBJICprbm93KikgdGhhdCAiZXhpc3RpbmcgY29yZSBy b3V0ZXJzIiB3aWxsICoqTk9UKiogaW5zcGVjdCB0aGUgSVAgaGVhZGVyIGZ1cnRoZXIgYnkgYXR0 ZW1wdGluZyB0byAnc2tpcCcgcGFzdCB0aGUgQUgvRVNQIGhlYWRlciBhbmQgZmluZCBhIFRDUC9V RFAgb3Igb3RoZXIgTGF5ZXItNCBoZWFkZXIgaW4gd2hpY2ggaXQgY291bGQgZXh0cmFjdCB7c3Jj X3BvcnQsIGRzdF9wb3J0fSBpbnB1dC1rZXlzIHRvIHVzZSBpbiBpdCdzIGhhc2ggYWxnb3JpdGht IGZvciBMQUcvRUNNUCBjb21wb25lbnQtbGluayBkZXRlcm1pbmF0aW9uLiAgR2l2ZW4gdGhlIHdo b2xlIHBvaW50IG9mIHRoaXMgZHJhZnQgaXMgdG8gYWxsb3cgY29yZSByb3V0ZXJzIHRvIGluc3Bl Y3QgdGhlIFVEUCBzcmNfcG9ydCBpbiBvcmRlciB0byBwcm92aWRlIHN1YnN0YW50aWFsICdlbnRy b3B5JyB0byBzdWNoIGhhc2gtYWxnb3JpdGhtcyBhbmQsIHRodXMsIGV2ZW4gZGlzdHJpYnV0aW9u IG9mIGZsb3dzIG92ZXIgY29tcG9uZW50LWxpbmtzIGluIExBRy9FQ01QIHBhdGhzIC4uLiB0aGF0 J3Mgbm90IHBvc3NpYmxlIHdoZW4gSVBTZWMgKGV2ZW4sIFRyYW5zcG9ydCBtb2RlKSB3aWxsIGJl IHJlcXVpcmVkIHRvIG1pdGlnYXRlIFNlIQ0KY3VyaXR5IGNvbmNlcm5zLg0KDQpUaGFua3MsDQoN Ci1zaGFuZQ0KDQoNClRoYW5rcywNCg0KLS0gQ2FybG9zLg0KDQoNCkJlc3QgcmVnYXJkcywNClhp YW9odQ0KDQozKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5 c3RlbXMgdGhhdCBpbXBsZW1lbnQgTDJUUCwgZm9yDQp0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5k IGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJlIGluZHVzdHJ5IHRvIHN1cHBvcnQNCk1QTFMvVURQ IGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIgcHJvZHVjdCBsaW5lcy4NCg0KLXNoYW5lDQoNCg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1Q TFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0IHdvdWxkIGhhdmUNCmJlZW4NCm1vcmUgd2lkZWx5 IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExTIG92ZXIN CkdSRSBvcg0KTVBMUyBvdmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUn cyBhIHdheSkuICBJIHdvdWxkIG5vdGUNCnRoYXQNCnRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRo aXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmUgc2V2ZXJhbCwgcHJhY3RpY2FsDQpvcGVy YXRpb25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdvaW5nIHdpdGggbmF0aXZlIE1QTFMNCmVu Y2Fwc3VsYXRpb24vc3dpdGNoaW5nIHdpdGhpbiB0aGUgZGF0YSBwbGFuZSwgbmFtZWx5Og0KLSBN UExTIEZhc3QgUmUtUm91dGUNCi0gTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nDQouLi4gdG8gbmFt ZSwgYnV0IGEgZmV3LiAgVGhvc2UgaGF2ZSB0ZW5kZWQgdG8gYmUgcXVpdGUgY29tcGVsbGluZw0K YXJndW1lbnRzDQp0byAndXBncmFkZScgbmV0d29yayBIVyB0byBzdXBwb3J0IE1QTFMgZW5jYXBz dWxhdGlvbi9zd2l0Y2hpbmcuDQoNCi1zaGFuZQ0KDQoNCi1Kb3NoDQoNCg0KT24gMTIvMTgvMTIg MTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRh dmFyaUBicm9hZGNvbS5jb20+Pg0Kd3JvdGU6DQoNCkZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFp biwgTVBMUyBvdmVyIElQIGlzIGxlZ2FjeSBhbmQgdGhlcmUgaXMgbm8gbmVlZA0KdG8gaW1wcm92 ZSBpdC4NCg0KUmVnYXJkcywNClNoYWhyYW0NCg0KDQpPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIg UE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdl aS5jb20+Pg0Kd3JvdGU6DQoNClNoYWhyYW0sDQoNClRoaXMgZHJhZnQgaXMgT05MWSBpbnRlbmRl ZCB0byBwcm92aWRlIGEgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24NCm1ldGhvZCB3aXRoIGEg YmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRvIHRob3NlDQpvcGVy YXRvcnMgd2hvIGhhcHBlbiB0byByZXF1aXJlIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9u IHRyYWZmaWMNCmFjcm9zcyBJUCBuZXR3b3Jrcy4gSSBiZWxpZXZlIE1QTFMtYmFzZWQgVlBOIG92 ZXIgSVAsIE5WR1JFIGFuZA0KVlhMQU4NCmVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBh bmQgdXNlIGNhc2VzLiBJZiB5b3UgYWJzb2x1dGVseSBiZWxpZXZlDQppdCdzIG1lYW5pbmdsZXNz IG9mIHRyYW5zcG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQDQpuZXR3 b3JrcyBhbmQgdGhlcmVmb3JlIHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBNUExTIG92 ZXIgSVANCnR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBz dGF0dXMsIHBsZWFzZSBzYXkNCnNvLg0KDQpCeSB0aGUgd2F5LCBpdCBzZWVtcyB0aGlzDQooaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL252bzMvY3VycmVudC9tc2cwMTg2NC5o dG1sKSBpcw0KanVzdCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0 aGUgZm9sbG93aW5nIGFyZ3VtZW50DQooaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNlZCBW UE4gaXMgYXBwbGljYWJsZSB0byBkYXRhIGNlbnRlcnMpLiBJDQpoYWQgdGhvdWdodCB5b3Ugd291 bGQgc3BlYWsgdXAgYXQgdGhhdCB0aW1lLiBTYWRseSwgc3VycHJpc2luZ2x5IHNpbGVudA0KdGls bCBub3cuDQoNClNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lz ZS4NCg0KWGlhb2h1DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dILT6se0NClMuDQpEYXZh cmkNCreiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KytW8/sjLOiBMb2EgQW5kZXJzc29u DQqzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPjsNCm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZz4NCtb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2 ZSBzdXBwb3J0IHRvIG1ha2UNCmRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQptcGxzIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQNCg0KSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFz IG5vIGFwcGxpY2F0aW9uIGluIHRvZGF5J3MNCm1vZGVybiBtZXRybw0KYW5kIGNvcmUsIHdoZXJl IE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGljYXRpb24NCmlu IGluIGRhdGENCmNlbnRlciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29s dXRpb25zIHN1Y2ggYXMgTlZHUkUNCmFuZA0KVlhMQU4uDQoNCkl0IHNlZW1zIHRoZSBhdXRob3Jz IGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KcHJvY2Vz cw0KYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KDQpSZWdhcmRzLA0KU2hhaHJh bQ0KDQoNCk9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCg0KV29ya2luZyBncm91cCwNCg0KVGhpcyBp cyB0byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KZHJhZnQteHUtbXBscy1p bi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KRHVlIHRvIHRoZSBo b2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0aCBvbmUgd2Vlay4N Cg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhl IG1wbHMNCndvcmtpbmcNCmdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZzxodHRw Oi8vaWV0Zi5vcmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQptb3RpdmF0aW9uIGZvciB5 b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRoaW5rIHRoYXQNCnRo ZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KDQpUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KDQpUaGVyZSBpcyBvbmUg SVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci8xOTQxLyAuDQoNCkFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRl ZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCnRoYXQgdGhleSBhcmUgbm90IGF3 YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UgYWxyZWFkeQ0KZGlzY2xvc2Vk Lg0KDQpIb3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAodGhlIGRvY3VtZW50IHRoYXQgd2UgdXNl ZCBmb3IgdGhlIElQUg0KcG9sbCkNCk1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUg b2YgdGhlIGF1dGhvcnMuIE1hcnNoYWxsIGhhcw0KZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlv bnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRoZSBhdXRob3IgdGVhbQ0Kb2YgZHJhZnQteHUt bXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8NCmNv bnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbiB0 aGUgSVBSDQpwb2xsLg0KV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KDQpGcm9tIHZl cnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxsIGFzIGENCmNv LWF1dGhvci4NCg0KL0xvYQ0KKG1wbHMgd2cgY28tY2hhaXIpDQotLQ0KDQoNCkxvYSBBbmRlcnNz b24gICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQpsb2EuYW5kZXJzc29uQGVyaWNzc29u LmNvbTxtYWlsdG86bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DQpTciBTdHJhdGVneSBhbmQg U3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVyaWNzc29uIEluYyAgICAg ICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTMNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTMNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K bXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZQ0KcHJvcHJpZXRhcnkg aW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVj dCB0bw0KY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1h aWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvcg0KdGhlDQp1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlDQppbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55DQpkaXNzZW1pbmF0aW9uLA0KZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZA0KYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UNCmhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQNCnBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQoNCg0KDQoNCg0KDQo= --_000_95067C434CE250468B77282634C96ED32281143Bxmbalnx02ciscoc_ Content-Type: text/html; charset="gb2312" Content-ID: <83F9BD4150D89544B62736E3FFC21B40@cisco.com> Content-Transfer-Encoding: quoted-printable Please find inline a couple of technical comments on this additional propos= al.

On Dec 20, 2012, at 11:27 AM, Shane Amante <shane@castlepoint.net> wrote:

Hi Xiaohu,

On Dec 20, 2012, at 3:13 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
Hi Shane,

Thanks for your further comments and please see my response inline.

Note: I changed the subject line according to Loa's suggestion.

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 22:38
=CA=D5=BC=FE=C8=CB: Xuxiaohu
=B3=AD=CB=CD: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-udp@tools.ietf.org;
mpls@ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make draft-xu-mp= ls-in-udp an
mpls working group document

Xiaohu,

On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
=CA=D5=BC=FE=C8=CB: Rogers, Josh
=B3=AD=CB=CD: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org;
mpls@ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make draft-xu-mp= ls-in-udp
an
mpls working group document


On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
wrote:
I share your SP perspective, and do not see the p= roblem this solution
addresses in practice any longer.

+1.  Please do not define yet another MPLS-over-IP encapsulation. =  The
IETF
already standardized MPLS over GRE.  The IET= F has also standardized
MPLS
over L2TPv3/UDP/IP, which had seen some deploymen= t in at least one, very
large operator network that I'm aware of to support carriage of L3VPN over<= br>
an
IP-only network.

Hi Shane,

Thank you for telling us there are actual deployments of MPLS over IP in at=
least one, very large operator network. This fact must be very valuable to = those
people who had believed there is no application of MPLS over IP in today's = SP
networks.

See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L= 2TPv3
[NOTE: the dates the above were published was back in the 2006
timeframe!]
  RFC 4665 for requirements related to = VPLS that say that VPLS may be
carried over L2TPv3
  And, here's evidence showing that at least one vendor has
implemented
IPVPN's over L2TPv3:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.htm= l

Thanks again for sharing the above information. As mentioned in this draft<= br>
AND other drafts, the mechanism of performing hash calculation on the Sessi= on
ID field in the L2TPv3 header or the Key field in the GRE header as defined= in
[RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent past, in requesting a co= re
router vendor to support changes to the input-keys used in hash calculation= s in
_existing_ hardware, already deployed (extensively) throughout my network.<= br> Further, I suspect that most large network operators are savvy folks and understand the internal architecture of their HW fairly well.  As a re= sult, those
same operators know what is and is not technically possible in this regard.=
Thus, it may be a question of "methods" necessary to convince the= ir HW
supplier(s) to make appropriate changes in their equipment to achieve their=
business goals.  :-)  However, this may not even be necessary ...= see below.

Could you please briefly explain how to make the above change in EXISTING h= ardware of already deployed core routers?

Firmware upgrades?


In contrast, most existing core routers are alrea= dy capable of balancing IP
traffic flows based on the hash of the five-tuple of UDP packets. By using = the
MPLS-in-UDP encapsulation, the already available load-balancing capability = of
most existing core routers can be leveraged without requiring any change to=
them. That is the major motivation of this draft.

If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, = which
uses UDP/IP, in the first place?

If I understand it correctly, you prefer to use MPLS-in-L2TPv3-in-UDP inste= ad of MPLS-in-UDP, right?

Actually, my first preference would be native MPLS switching edge-to-edge, = (which means enabling MPLS throughout the network).  My second prefere= nce would be that for the cases where that's impractical to use native MPLS= switching end-to-end, then (edge) devices -- not necessarily routers, (see below) -- would have to perform MPLS-in-L= 2TPv3-in-UDP encapsulation/de-encapsulation.


IMHO, a better proposal may be to consider a [min= or] (?) change to RFC 3931,
which would allow the connection used for data packets (not control packets= )
to use a varying set of source ports (or, source IP addresses), based on a = hash
calculation, to achieve better load-balancing over existing equipment in an=
IP-only core.

You mention RFC 3931 -- L2TPv3 defines L2TP directly over IP (IP Proto= col number 115) as a MUST, and L2TP over UDP as a SHOULD. Implementations m= ight not support L2TPv3 over UDP.

   L2TP may operate over a variety of PSNs.  There a=
re two modes
   described for operation over IP, L2TP directly over IP (see Section
   4.1.1) =
and L2TP over UDP (see Section 4.1.2).  L2TPv3 implementations
   MUST support L2TP over IP and SHOULD support L2TP over UDP for better
   NAT and firewall traversal, and for easier migration from L2TPv2.

 L2TP end-system implementations would be be= tter off just using
the "Session ID" (and "Cookie") fields as the demultipl= exor to associate
incoming packets with the associated L2TP Control Channel.  In fact, i= t's not
clear to me that existing implementations may /already/ do this, making any=
"check" on the incoming source port unnecessary for L2TP end-syst= em
implementations.

Also, L2TPv3 (over any PSN) uses the Session ID as the session demultiplexe= r (the Cookie is not a demux):

   It is important for implementers to
   note that the Cookie field check occurs after looking up the session
   context by the Session ID, and as such, consists merely of a value
   match of the Cookie field and that stored in the retrieved context.
   There is no need to perform a lookup across the Session ID and Cookie
   as a single value.
And the Session ID associates context with a Session, not with a Contr= ol Channel. THe UDP "connection" associates with the Control Conn= ection:



The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the
"control channel" (software) of existing L2TP end-system implemen= tations.
Heck, it may even be backwards compatible with existing L2TPv3
implementations.  (L2TPv3 implementors would need to comment on that).=

IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,  the hardware of= PE routers needs to be upgraded, e.g., ingress PE routers need to fill in = an entropy value in the source port field of UDP headers.

I suppose the answer is "it depends" on the HW architecture of PE= 's -- NPU vs. ASIC -- and whether one needs "PE's" in the traditi= onal sense, as well.  As one example, there is the following open sour= ce implementation of L2TP:
http://www.openl2tp.org

Note that the OpenL2TP project implements L2TPv2, RFC2661.

As that Web page notes, OpenL2TP has been integra= ted into the Linux 2.6.23 kernel.  FWIW, I am aware that Microsoft -- = and, other Operating Systems -- have an L2TP stack for several years now, (= to support L2TP/IPSec for VPN's), as well.

Regardless, if the main desire for MPLS-over-IP encapsulation is for DataCe= nters and/or NVO3 ... then, I would think it would be possible to consider = /enabling/ OpenL2TP within the Hypervisor of the existing servers, (since t= hey likely already run Linux), and you likely get the best of all worlds: no need to upgrade any "hardwa= re" in the network, just upgrade software (if necessary!) on your serv= ers.  If I were in this situation, that is the direction I would look = at, since it seems that such Hypervisor upgrades may be necessary anyway, depending of course on the outcome of the work in= NVO3, both in it's choice(s) for data plane encapsulations and "contr= ol plane" signaling, as well.



2) There is a substantial added security one gets= by using "Session ID" and
"Cookie" fields to ensure the received L2TPv3 packet is intended = for the
identified session.  Quoting from Section 8.2 of RFC 3931:
---snip---
 L2TPv3 provides traffic separation for its VPNs via a 32-bit Session<= br>  ID in the L2TPv3 data header.  When present, the L2TPv3 Cookie  (described in Section 4.1), provides an additional check to ensure  that an arriving packet is intended for the identified session.
 Thus, use of a Cookie with the Session ID provides an extra guarantee=
 that the Session ID lookup was performed properly and that the
 Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the
past, had /substantial/ concerns about encapsulation of MPLS over IP transp= ort.
In fact, this is why you see text in Section 7.6, "Security", of = RFC 4665.
(There's likely similar language in other drafts that use MPLS for transpor= t).
While I'm not sure that Security Area folks pay much attention to daily tra= ffic on
the MPLS WG mailing list, I'm fairly confident this concern will arise if/w= hen this
draft goes to the IESG ...

If I understand it correctly, the reason for your preference of MPLS-in-L2T= Pv3-in-UDP is that it has an added security feature. If that is so concerne= d, can you explain why MPLS-in-GRE is far more popular than MPLS-in-L2TP in= practice?

Would you care to cite a source for the above assertion that MPLS-in-GRE is= far more popular in _deployments_ than MPLS-in-L2TP?

+1.


Regardless, I would note that IETF specifications are only recommendations,= based on the knowledge and experience of its participants.  The IETF = does not enforce what operators actually deploy in their network.  Ope= rators may make (and, often do make) different choices than what the IETF recommends, because operators understand their = networks, services and applications better and the trade-offs and the risks= involved.  Specifically, in the context of this discussion, it may be= that MPLS-in-GRE is more widely used due to a number of factors.  However, one potential reason that they = may use MPLS-in-GRE is it is only used within the confines of a private net= work (Enterprise LAN/WAN?, IPVPN?), thus the _perception_ of risk of MiTM a= ttacks -- which is the main concern of using MPLS-in-GRE without GRE keys -- is considered by the operator to be = "low".  For better or worse, IETF recommendations /need/ to = consider all types of networks, e.g.: public and private networks, and thus= ha!
ve a tendency to recommend more, rather than less, "security" in = those recommendations.

Thus, *if* this WG draft is adopted (and, before it gets sent to the IESG) = I think the co-authors should spend some time with the Security Area to und= erstand the concerns they would most certainly raise during the development= of this draft or, worse, during the final stages of its publication (IESG review).  :-)  Namely:=
1)  In my past experience merely saying that a given protocol is only = /supposed to/ be deployed a given environment has not been successful, give= n the reason I stated above -- you can't predict where a given technology w= ill get deployed due to operators (like me :-) "disobeying" (or, not reading) advice in IETF drafts/RFCs= .
2)  The current "Security Considerations" section recommends= using IPSec Transport Mode, but lacks sufficient details beyond that, name= ly:
   a)  IPSec Transport Mode with AH and/or ESP?
   b)  More concerning in the context of this draft is = that the way IPSec works will kill the effectiveness of this draft.  S= pecifically, you may wish to review RFCs 4302 and 4303 (AH and ESP, respect= ively).  Namely, the way and IPSec Transport Mode packet will look on the wire is as follows, (from Sections 3.1.1 of both RFCs):
            &nb= sp;     AFTER APPLYING AH
            ---= ----------------------------------------------------
      IPv4  |original IP hdr (any option= s) | AH | TCP |    Data   |
            ---= ----------------------------------------------------
            |&l= t;- mutable field processing ->|<- immutable fields ->|
            |&l= t;----- authenticated except for mutable fields ----->|


            &nb= sp;    AFTER APPLYING ESP
            ---= ----------------------------------------------
      IPv4  |orig IP hdr  | ESP | &= nbsp;   |      |   ESP &n= bsp; | ESP|
            |(a= ny options)| Hdr | TCP | Data | Trailer | ICV|
            ---= ----------------------------------------------
            &nb= sp;            =        |<---- encryption ---->|             &nb= sp;            =  |<-------- integrity ------->|

In summary, *when* IPSec Transport Mode is applied, only the outermost 2-tu= ple {src_ip, dst_ip} will be "readily" visible to intermediate no= des.  Unfortunately, the original (outermost) IP header will have IP p= rotocol 50 or 51 (AH or ESP, respectively) pointing that what immediately follows the IP header is an AH or ESP header ... thu= s, I would bet (better yet, I *know*) that "existing core routers"= ; will **NOT** inspect the IP header further by attempting to 'skip' past t= he AH/ESP header and find a TCP/UDP or other Layer-4 header in which it could extract {src_port, dst_port} input-keys t= o use in it's hash algorithm for LAG/ECMP component-link determination. &nb= sp;Given the whole point of this draft is to allow core routers to inspect = the UDP src_port in order to provide substantial 'entropy' to such hash-algorithms and, thus, even distribution= of flows over component-links in LAG/ECMP paths ... that's not possible wh= en IPSec (even, Transport mode) will be required to mitigate Se!
curity concerns.

Thanks,

-shane


Thanks,

-- Carlos.


Best regards,
Xiaohu

3) Finally, this approach only affects the end-sy= stems that implement L2TP, for
tunneling of MPLS/IP, and does not require an entire industry to support MPLS/UDP encapsulation in their product lines.

-shane



Best regards,
Xiaohu

If there was market demand for MPLS over IP, then= clearly it would have
been
more widely implemented by equipment vendors, wit= h either MPLS over
GRE or
MPLS over L2TPv3.  (Where there's a will, th= ere's a way).  I would note
that
the most likely reasons this did not pan out was = there are several, practical
operational benefits one gets from going with native MPLS
encapsulation/switching within the data plane, namely:
- MPLS Fast Re-Route
- MPLS Traffic Engineering
... to name, but a few.  Those have tended to be quite compelling
arguments
to 'upgrade' network HW to support MPLS encapsula= tion/switching.

-shane


-Josh


On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com>
wrote:

For service provider domain, MPLS over IP is lega= cy and there is no need
to improve it.

Regards,
Shahram


On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com>
wrote:

Shahram,

This draft is ONLY intended to provide a MPLS-over-IP encapsulation
method with a better load-balancing applicability so far to those
operators who happen to require transporting MPLS application traffic
across IP networks. I believe MPLS-based VPN over IP, NVGRE and
VXLAN
each have their own advocators and use cases. If = you absolutely believe
it's meaningless of transporting MPLS application traffic across IP
networks and therefore those existing RFCs related to MPLS over IP
tunneling mechanisms should be moved to Historic status, please say
so.

By the way, it seems this
(http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) is just the right thread suitable for you to make the following argument
(i.e., whether or not MPLS-based VPN is applicable to data centers). I
had thought you would speak up at that time. Sadly, surprisingly silent
till now.

Sigh, I didn't intend to say the above otherwise.

Xiaohu

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: mpls-bounces@i= etf.org [mailto:mpls-bounces@i= etf.org] =B4=FA=B1=ED
S.
Davari
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
=CA=D5=BC=FE=C8=CB: Loa Andersson
=B3=AD=CB=CD: draft-= xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make
draft-xu-mpls-in-udp an
mpls working group document

I don't support this draft since it has no application in today's
modern metro
and core, where MPLS is dominant, and its only practical application
in in data
center, which already is crowded with other solutions such as NVGRE
and
VXLAN.

It seems the authors are trying to bypass the NVO3 solution selection
process
by advancing the draft in MPLS WG.

Regards,
Shahram


On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:

Working group,

This is to start a "two week" poll on adopting
draft-xu-mpls-in-udp-06 as an MPLS working group document.
Due to the holiday season this poll has been extended with one week.

Please send your comments (support/not support) to the mpls
working
group mailing list (mpls at ietf.org). Please give an technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends January 07, 2013.

There is one IPR claim against this document -
https://datatracker.ietf= .org/ipr/1941/ .

All the active co-authors has stated on the working group mailing list
that they are not aware of any other IPR claims than those already
disclosed.

However, up to version -03 (the document that we used for the IPR
poll)
Marshall Eubanks was listed as one of the authors. Marshall has
discontinued all interactions with the IETF, including the author team
of draft-xu-mpls-in-udp-06. The working group chairs has tried to
contact Marshall by other means, to try get a response on the IPR
poll.
We have had no success in this.

>From version -04 the authors decided to remove Marshall as a
co-author.

/Loa
(mpls wg co-chair)
--


Loa Andersson           &= nbsp;           &nbs= p; email:
loa.andersson@ericsson.com
Sr Strategy and Standards Manager   &nb= sp;        loa@pi.nu
Ericsson Inc           &n= bsp;            = ;  phone: +46 10 717 52 13
            &nb= sp;            =             &nb= sp; +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely fo= r
the
use of the individual or entity to which it is ad= dressed. If you are not the
intended recipient of this E-mail, you are hereby notified that any
dissemination,
distribution, copying, or action taken in relatio= n to the contents of and
attachments to this E-mail is strictly prohibited and may be unlawful. If y= ou
have received this E-mail in error, please notify the sender immediately an= d
permanently delete the original and any copy of this E-mail and any printou= t.
_______________________________________________ mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls








--_000_95067C434CE250468B77282634C96ED32281143Bxmbalnx02ciscoc_-- From adrian@olddog.co.uk Thu Dec 20 10:37:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CA921F8A85 for ; Thu, 20 Dec 2012 10:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VBXSRlji9B1 for ; Thu, 20 Dec 2012 10:37:57 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0FB21F8A61 for ; Thu, 20 Dec 2012 10:37:56 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBKIbpVJ013548; Thu, 20 Dec 2012 18:37:51 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBKIboeJ013520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Dec 2012 18:37:51 GMT From: "Adrian Farrel" To: "'Lucy yong'" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> Date: Thu, 20 Dec 2012 18:37:47 -0000 Message-ID: <02c401cddee1$1bc3b130$534b1390$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQKSpWp75Rbtd9ee1EcHDETJX5kCEALLXTJHA0ARFM8BvBt4EAID1R3sAq4LnCWWNKlusA== Cc: draft-xu-mpls-in-udp@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 18:37:59 -0000 Hi Lucy, Can you clarify something for me. The I-D is pretty open about the use cases. It cites DC interconnect as = an example, but focuses the main motivation as providing entropy in a = non-MPLS IP network that carries MPLS traffic through encapsulation. Yet in your email below you say:=20 > Such application is for DC. You may argue why not use the > GRE which is for MPLS layer over an IGP underling network. > We have pointed out in the draft that current routers in DC=20 > barely support GRE based load balancing and MPLS-in-GRE > are barely used in SP networks too. Most of routers in DC > perform upd port based load balancing now. Now, it is important, in my opinion to understand whether you are = attempting to solve a general MPLS-in-IP entropy problem, or attempting to solve a = specific DC interconnect problem for connectivity over non-MPLS cores. In the former = case, it would not be unreasonable for us to try to work out what the demand = is: the problem is understandable from an academic point of view, but are people carrying MPLS over IP today, and if so, do they see this problem? In the = latter case, it is sensible to discuss with NVO3 whether this is addressing the = DC interconnect (L3 overlay) problem in a meaningful way. Thanks, Adrian > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf = Of Lucy > yong > Sent: 20 December 2012 15:39 > To: Shane Amante > Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls- > chairs@tools.ietf.org > Subject: [mpls] MPLS client layer over an IGP underlying network >=20 > Hi Shane, >=20 > I understand operator concern on a new encapsulation to an existing = network. >=20 > However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS = network at > all. > MPLS-in-UDP is to enable MPLS client layer to be decoupled from MPLS = server > layer and use MPLS client layer as overlay network and an IGP as a = underlying > network for transport. Such application is for DC. You may argue why = not use the > GRE which is for MPLS layer over an IGP underling network. We have = pointed out > in the draft that current routers in DC barely support GRE based load balancing > and MPLS-in-GRE are barely used in SP networks too. Most of routers in = DC > perform upd port based load balancing now. >=20 > From the architecture perspective, the UDP encapsulation has advantage = over > GRE encapsulation too. In UDP encapsulation, the frame header = decouples the > overlay and underlying network clearly, i.e. outer header and overlay = header. > UDP belongs to outer header, which underlying network uses only. = However, > GRE header has the fields for the overlay network and uses the key = field for flow > entropy. For load balancing, it requires the underlying network uses = GRE header > too. In short, GRE ties the overlay and underlying networks together. = Since it has > not used a lot, people are not aware of the disadvantage of such = coupling. >=20 > As the industry moves toward network virtualization overlay and = decouples > overlay networks from the underlying network. A clear separation of = overlay > header and underlying header is a "MUST" in my opinion. If we count = GRE as the > overlay header, then for IPv4 underlying network, there is no field = for the flow > entropy. This is the reason we propose the UDP encapsulation: for an = IGP based > underlying network. In fact, it can support any overlay network beside = MPLS > client layer (e.g. VXLAN, L2TP-in-UDP, etc). >=20 > You point out using MPLS-in-L2TP-in-UDP instead. Yes, = MPLS-in-L2TP-in-UDP > schema also provides a overlay (L2TP) and underlying (IP) network = decoupling. > L2TP protocol (rfc3931) provides good security mechanism and has the > embedded control function too. Therefore, someone can use it for MPLS = client > layer over Internet. To have MPLS client layer over an IGP underling = network, > IMO: MPLS-in-L2TP-in-UDP is a overkill and too complex. Here we need a = schema > to support IGP underlying transport without touching a overlay header. = UDP > encapsulation is the best choice to accomplish that and minimize the = changes on > existing routers, e.g. change at edge routers, no change on transit = routers. >=20 > Regards, > Lucy >=20 >=20 >=20 > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Thursday, December 20, 2012 4:14 AM > > To: Shane Amante > > Cc: Rogers, Josh; Shahram Davari; = draft-xu-mpls-in-udp@tools.ietf.org; > > mpls@ietf.org; mpls-chairs@tools.ietf.org > > Subject: Discussion on how to transport MPLS over UDP tunnels > > > > Hi Shane, > > > > Thanks for your further comments and please see my response inline. > > > > Note: I changed the subject line according to Loa's suggestion. > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net] > > > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 22:38 > > > =CA=D5=BC=FE=C8=CB: Xuxiaohu > > > =B3=AD=CB=CD: Rogers, Josh; Shahram Davari; draft-xu-mpls-in- > > udp@tools.ietf.org; > > > mpls@ietf.org; mpls-chairs@tools.ietf.org > > > =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make = draft-xu- > > mpls-in-udp an > > > mpls working group document > > > > > > Xiaohu, > > > > > > On Dec 18, 2012, at 11:50 PM, Xuxiaohu = wrote: > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > >> =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net] > > > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58 > > > >> =CA=D5=BC=FE=C8=CB: Rogers, Josh > > > >> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu; draft-xu-mpls-in- > > udp@tools.ietf.org; > > > >> mpls@ietf.org; mpls-chairs@tools.ietf.org > > > >> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make = draft-xu- > > mpls-in-udp > > > an > > > >> mpls working group document > > > >> > > > >> > > > >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" > > > > > >> wrote: > > > >>> I share your SP perspective, and do not see the problem this > > solution > > > >>> addresses in practice any longer. > > > >> > > > >> +1. Please do not define yet another MPLS-over-IP = encapsulation. > > The > > > IETF > > > >> already standardized MPLS over GRE. The IETF has also > > standardized > > > MPLS > > > >> over L2TPv3/UDP/IP, which had seen some deployment in at least = one, > > very > > > >> large operator network that I'm aware of to support carriage of > > L3VPN over > > > an > > > >> IP-only network. > > > > > > > > Hi Shane, > > > > > > > > Thank you for telling us there are actual deployments of MPLS = over > > IP in at > > > least one, very large operator network. This fact must be very > > valuable to those > > > people who had believed there is no application of MPLS over IP in > > today's SP > > > networks. > > > > > > > >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 > > > >> [NOTE: the dates the above were published was back in the 2006 > > > timeframe!] > > > >> RFC 4665 for requirements related to VPLS that say that = VPLS > > may be > > > >> carried over L2TPv3 > > > >> And, here's evidence showing that at least one vendor has > > > implemented > > > >> IPVPN's over L2TPv3: > > > >> > > = http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html > > > > > > > > Thanks again for sharing the above information. As mentioned in > > this draft > > > AND other drafts, the mechanism of performing hash calculation on = the > > Session > > > ID field in the L2TPv3 header or the Key field in the GRE header = as > > defined in > > > [RFC 5640] is not widely supported by existing core routers so = far. > > > > > > FWIW, I have had success, in the relatively recent past, in > > requesting a core > > > router vendor to support changes to the input-keys used in hash > > calculations in > > > _existing_ hardware, already deployed (extensively) throughout my > > network. > > > Further, I suspect that most large network operators are savvy = folks > > and > > > understand the internal architecture of their HW fairly well. As = a > > result, those > > > same operators know what is and is not technically possible in = this > > regard. > > > Thus, it may be a question of "methods" necessary to convince = their > > HW > > > supplier(s) to make appropriate changes in their equipment to = achieve > > their > > > business goals. :-) However, this may not even be necessary ... = see > > below. > > > > Could you please briefly explain how to make the above change in > > EXISTING hardware of already deployed core routers? > > > > > > In contrast, most existing core routers are already capable of > > balancing IP > > > traffic flows based on the hash of the five-tuple of UDP packets. = By > > using the > > > MPLS-in-UDP encapsulation, the already available load-balancing > > capability of > > > most existing core routers can be leveraged without requiring any > > change to > > > them. That is the major motivation of this draft. > > > > > > If this is a concern, then why not encapsulate the traffic in > > MPLS/L2TPv3, which > > > uses UDP/IP, in the first place? > > > > If I understand it correctly, you prefer to use = MPLS-in-L2TPv3-in-UDP > > instead of MPLS-in-UDP, right? > > > > > IMHO, a better proposal may be to consider a [minor] (?) change to > > RFC 3931, > > > which would allow the connection used for data packets (not = control > > packets) > > > to use a varying set of source ports (or, source IP addresses), = based > > on a hash > > > calculation, to achieve better load-balancing over existing = equipment > > in an > > > IP-only core. L2TP end-system implementations would be better off > > just using > > > the "Session ID" (and "Cookie") fields as the demultiplexor to > > associate > > > incoming packets with the associated L2TP Control Channel. In = fact, > > it's not > > > clear to me that existing implementations may /already/ do this, > > making any > > > "check" on the incoming source port unnecessary for L2TP = end-system > > > implementations. > > > > > > The beauty of the above approach is: > > > 1) I would think that the above is most likely a change that is > > limited to the > > > "control channel" (software) of existing L2TP end-system > > implementations. > > > Heck, it may even be backwards compatible with existing L2TPv3 > > > implementations. (L2TPv3 implementors would need to comment on = that). > > > > IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP, the hardware = of > > PE routers needs to be upgraded, e.g., ingress PE routers need to = fill > > in an entropy value in the source port field of UDP headers. > > > > > 2) There is a substantial added security one gets by using = "Session > > ID" and > > > "Cookie" fields to ensure the received L2TPv3 packet is intended = for > > the > > > identified session. Quoting from Section 8.2 of RFC 3931: > > > ---snip--- > > > L2TPv3 provides traffic separation for its VPNs via a 32-bit > > Session > > > ID in the L2TPv3 data header. When present, the L2TPv3 Cookie > > > (described in Section 4.1), provides an additional check to = ensure > > > that an arriving packet is intended for the identified session. > > > Thus, use of a Cookie with the Session ID provides an extra > > guarantee > > > that the Session ID lookup was performed properly and that the > > > Session ID itself was not corrupted in transit. > > > ---snip--- > > > ... in regard to this question alone, I know the Security Area = folks > > have, in the > > > past, had /substantial/ concerns about encapsulation of MPLS over = IP > > transport. > > > In fact, this is why you see text in Section 7.6, "Security", of = RFC > > 4665. > > > (There's likely similar language in other drafts that use MPLS for > > transport). > > > While I'm not sure that Security Area folks pay much attention to > > daily traffic on > > > the MPLS WG mailing list, I'm fairly confident this concern will > > arise if/when this > > > draft goes to the IESG ... > > > > If I understand it correctly, the reason for your preference of = MPLS- > > in-L2TPv3-in-UDP is that it has an added security feature. If that = is > > so concerned, can you explain why MPLS-in-GRE is far more popular = than > > MPLS-in-L2TP in practice? > > > > Best regards, > > Xiaohu > > > > > 3) Finally, this approach only affects the end-systems that = implement > > L2TP, for > > > tunneling of MPLS/IP, and does not require an entire industry to > > support > > > MPLS/UDP encapsulation in their product lines. > > > > > > -shane > > > > > > > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > >> If there was market demand for MPLS over IP, then clearly it = would > > have > > > been > > > >> more widely implemented by equipment vendors, with either MPLS > > over > > > GRE or > > > >> MPLS over L2TPv3. (Where there's a will, there's a way). I = would > > note > > > that > > > >> the most likely reasons this did not pan out was there are = several, > > practical > > > >> operational benefits one gets from going with native MPLS > > > >> encapsulation/switching within the data plane, namely: > > > >> - MPLS Fast Re-Route > > > >> - MPLS Traffic Engineering > > > >> ... to name, but a few. Those have tended to be quite = compelling > > > arguments > > > >> to 'upgrade' network HW to support MPLS = encapsulation/switching. > > > >> > > > >> -shane > > > >> > > > >> > > > >>> -Josh > > > >>> > > > >>> > > > >>> On 12/18/12 12:31 AM, "Shahram Davari" > > > wrote: > > > >>> > > > >>>> For service provider domain, MPLS over IP is legacy and there = is > > no need > > > >>>> to improve it. > > > >>>> > > > >>>> Regards, > > > >>>> Shahram > > > >>>> > > > >>>> > > > >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" > > > wrote: > > > >>>> > > > >>>>> Shahram, > > > >>>>> > > > >>>>> This draft is ONLY intended to provide a MPLS-over-IP > > encapsulation > > > >>>>> method with a better load-balancing applicability so far to > > those > > > >>>>> operators who happen to require transporting MPLS = application > > traffic > > > >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE = and > > > VXLAN > > > >>>>> each have their own advocators and use cases. If you = absolutely > > believe > > > >>>>> it's meaningless of transporting MPLS application traffic > > across IP > > > >>>>> networks and therefore those existing RFCs related to MPLS = over > > IP > > > >>>>> tunneling mechanisms should be moved to Historic status, = please > > say > > > so. > > > >>>>> > > > >>>>> By the way, it seems this > > > >>>>> (http://www.ietf.org/mail- > > archive/web/nvo3/current/msg01864.html) is > > > >>>>> just the right thread suitable for you to make the following > > argument > > > >>>>> (i.e., whether or not MPLS-based VPN is applicable to data > > centers). I > > > >>>>> had thought you would speak up at that time. Sadly, > > surprisingly silent > > > >>>>> till now. > > > >>>>> > > > >>>>> Sigh, I didn't intend to say the above otherwise. > > > >>>>> > > > >>>>> Xiaohu > > > >>>>> > > > >>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > > >>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org = [mailto:mpls-bounces@ietf.org] =B4=FA > > =B1=ED > > > >> S. > > > >>>>>> Davari > > > >>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34 > > > >>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersson > > > >>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; = mpls@ietf.org; > > > >>>>>> mpls-chairs@tools.ietf.org > > > >>>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to = make > > > >>>>>> draft-xu-mpls-in-udp an > > > >>>>>> mpls working group document > > > >>>>>> > > > >>>>>> I don't support this draft since it has no application in > > today's > > > >>>>>> modern metro > > > >>>>>> and core, where MPLS is dominant, and its only practical > > application > > > >>>>>> in in data > > > >>>>>> center, which already is crowded with other solutions such = as > > NVGRE > > > and > > > >>>>>> VXLAN. > > > >>>>>> > > > >>>>>> It seems the authors are trying to bypass the NVO3 solution > > selection > > > >>>>>> process > > > >>>>>> by advancing the draft in MPLS WG. > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Shahram > > > >>>>>> > > > >>>>>> > > > >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson = wrote: > > > >>>>>> > > > >>>>>>> Working group, > > > >>>>>>> > > > >>>>>>> This is to start a "two week" poll on adopting > > > >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. > > > >>>>>>> Due to the holiday season this poll has been extended with > > one week. > > > >>>>>>> > > > >>>>>>> Please send your comments (support/not support) to the = mpls > > > working > > > >>>>>>> group mailing list (mpls at ietf.org). Please give an > > technical > > > >>>>>>> motivation for your support/not support, especially if you > > think that > > > >>>>>>> the document should not be adopted as a working group > > document. > > > >>>>>>> > > > >>>>>>> This poll ends January 07, 2013. > > > >>>>>>> > > > >>>>>>> There is one IPR claim against this document - > > > >>>>>>> https://datatracker.ietf.org/ipr/1941/ . > > > >>>>>>> > > > >>>>>>> All the active co-authors has stated on the working group > > mailing list > > > >>>>>>> that they are not aware of any other IPR claims than those > > already > > > >>>>>>> disclosed. > > > >>>>>>> > > > >>>>>>> However, up to version -03 (the document that we used for = the > > IPR > > > >>>>>>> poll) > > > >>>>>>> Marshall Eubanks was listed as one of the authors. = Marshall > > has > > > >>>>>>> discontinued all interactions with the IETF, including the > > author team > > > >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has > > tried to > > > >>>>>>> contact Marshall by other means, to try get a response on = the > > IPR > > > >>>>>>> poll. > > > >>>>>>> We have had no success in this. > > > >>>>>>> > > > >>>>>>> From version -04 the authors decided to remove Marshall as = a > > > >>>>>>> co-author. > > > >>>>>>> > > > >>>>>>> /Loa > > > >>>>>>> (mpls wg co-chair) > > > >>>>>>> -- > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Loa Andersson email: > > > >>>>>> loa.andersson@ericsson.com > > > >>>>>>> Sr Strategy and Standards Manager loa@pi.nu > > > >>>>>>> Ericsson Inc phone: +46 10 717 52 = 13 > > > >>>>>>> +46 767 72 92 13 > > > >>>>>>> _______________________________________________ > > > >>>>>>> mpls mailing list > > > >>>>>>> mpls@ietf.org > > > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>>>>> _______________________________________________ > > > >>>>>> mpls mailing list > > > >>>>>> mpls@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>>>> _______________________________________________ > > > >>>>> mpls mailing list > > > >>>>> mpls@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>>> _______________________________________________ > > > >>>> mpls mailing list > > > >>>> mpls@ietf.org > > > >>>> https://www.ietf.org/mailman/listinfo/mpls > > > >>> > > > >>> > > > >>> This E-mail and any of its attachments may contain Time Warner > > Cable > > > >> proprietary information, which is privileged, confidential, or > > subject to > > > >> copyright belonging to Time Warner Cable. This E-mail is = intended > > solely for > > > the > > > >> use of the individual or entity to which it is addressed. If = you > > are not the > > > >> intended recipient of this E-mail, you are hereby notified that > > any > > > dissemination, > > > >> distribution, copying, or action taken in relation to the = contents > > of and > > > >> attachments to this E-mail is strictly prohibited and may be > > unlawful. If you > > > >> have received this E-mail in error, please notify the sender > > immediately and > > > >> permanently delete the original and any copy of this E-mail and > > any printout. > > > >>> _______________________________________________ > > > >>> mpls mailing list > > > >>> mpls@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/mpls > > > >> > > > > > > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From lucy.yong@huawei.com Thu Dec 20 11:14:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D868D21F8A45 for ; Thu, 20 Dec 2012 11:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.771 X-Spam-Level: X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=-2.314, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnnfBmPiTPcZ for ; Thu, 20 Dec 2012 11:14:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C892621F88C4 for ; Thu, 20 Dec 2012 11:14:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR59095; Thu, 20 Dec 2012 19:14:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 19:13:59 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 19:14:05 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 11:14:02 -0800 From: Lucy yong To: "adrian@olddog.co.uk" Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiisKA//98ebA= Date: Thu, 20 Dec 2012 19:14:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864890@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <02c401cddee1$1bc3b130$534b1390$@olddog.co.uk> In-Reply-To: <02c401cddee1$1bc3b130$534b1390$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.202] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:14:58 -0000 SGkgQWRyaWFuLA0KDQpQZXJzb25hbGx5LCBJIGRvIG5vdCBzZWUgdGhhdCBEQyBpbnRlcmNvbm5l Y3Rpb24gaXMgYW4gYXBwbGljYXRpb24gb2YgdGhpcyB5ZXQuIFRvIG1lLCB1c2luZyBNUExTIGNs aWVudCBsYXllciAoZS5nLiBFVlBOLCBJUFZQTikgaW5zaWRlIERDIChlLmcuIElHUCkgZm9yIG5l dHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBpcyB0aGUgcG90ZW50aWFsIGFwcGxpY2F0aW9u IG9mIHRoaXMuDQoNClBlcnNvbmFsbHksIEkgaGF2ZSBub3Qgc2VlbiBhIHJlcXVlc3QgZnJvbSBz ZXJ2aWNlIHByb3ZpZGVyIHdobyB3YW50IE1QTFMgb3ZlciBXQU4gSVAgaW4gZ2VuZXJhbC4gT3Ro ZXIgY28tYXV0aG9ycyBtYXkgaGF2ZS4gV2hldGhlciB0aGlzIGlzIGFwcGxpY2FibGUgZm9yIERD IGludGVyY29ubmVjdGlvbiwgSSBmaXJzdCBhc2sgd2h5IGRvIGl0LCBpZiBTZXJ2aWNlIHByb3Zp ZGVycyBoYXZlIGRlcGxveWVkIElQL01QTFMgdHJhbnNwb3J0IG5ldHdvcmtzIGluIFdBTiwgd2hh dCBpcyB3cm9uZyB0byB1c2UgaXQgZm9yIERDIGludGVyY29ubmVjdGlvbj8gSW4gZmFjdCwgdGhp cyBpcyB3aGF0IFNQcyBkbyB0b2RheS4gDQoNClNvbWV0aGluZyBJIGNhbiBmb3Jlc2VlIGlzIHRo YXQgYSBzZXJ2aWNlIHByb3ZpZGVyIG1heSBhbHNvIGhhdmUgRGF0YSBDZW50ZXJzLCBvciBEQyBw cm92aWRlcnMgaGF2ZSBzb21lIGEgV0FOIG5ldHdvcmssIGluIHRoaXMgY2FzZSwgaWYgdGhleSB3 YW50IGJvdGggbmV0d29ya3MgdXNlIHRoZSBzYW1lIHVuZGVybHlpbmcgbmV0d29yayBhbmQgb3Zl cmxheSBuZXR3b3JrIG1lY2hhbmlzbS4gVGhpcyBjYW4gcHJvdmlkZSBhIGdlbmVyYWwgc29sdXRp b24gZm9yIHRoaXMgYXJlYS4gQWdhaW4sIHRoaXMgaXMgbXkgdmlldywgbm90IGZyb20gYSBzZXJ2 aWNlIHByb3ZpZGVyIG9yIERDIHByb3ZpZGVyLg0KDQpJbiBzaG9ydCwgdGhlIHBvdGVudGlhbCBh cHBsaWNhdGlvbiBJIHRoaW5rIGlzIGRpZmZlcmVudCBmcm9tIHR3byB5b3UgcG9pbnQgb3V0IGhl cmUgKG9yIHRoZSBkcmFmdCBzdGF0ZSkuIEknbGwgd29yayB3aXRoIGNvLWF1dGhvcnMgb24gdGhh dC4NCg0KVGhhbmtzLA0KTHVjeSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBBZHJpYW4gRmFycmVsIFttYWlsdG86YWRyaWFuQG9sZGRvZy5jby51a10NCj4gU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDEyOjM4IFBNDQo+IFRvOiBMdWN5IHlvbmcNCj4g Q2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJFOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJs eWluZyBuZXR3b3JrDQo+IA0KPiBIaSBMdWN5LA0KPiANCj4gQ2FuIHlvdSBjbGFyaWZ5IHNvbWV0 aGluZyBmb3IgbWUuDQo+IFRoZSBJLUQgaXMgcHJldHR5IG9wZW4gYWJvdXQgdGhlIHVzZSBjYXNl cy4gSXQgY2l0ZXMgREMgaW50ZXJjb25uZWN0IGFzDQo+IGFuDQo+IGV4YW1wbGUsIGJ1dCBmb2N1 c2VzIHRoZSBtYWluIG1vdGl2YXRpb24gYXMgcHJvdmlkaW5nIGVudHJvcHkgaW4gYSBub24tDQo+ IE1QTFMgSVANCj4gbmV0d29yayB0aGF0IGNhcnJpZXMgTVBMUyB0cmFmZmljIHRocm91Z2ggZW5j YXBzdWxhdGlvbi4NCj4gWWV0IGluIHlvdXIgZW1haWwgYmVsb3cgeW91IHNheToNCj4gPiBTdWNo IGFwcGxpY2F0aW9uIGlzIGZvciBEQy4gWW91IG1heSBhcmd1ZSB3aHkgbm90IHVzZSB0aGUNCj4g PiBHUkUgd2hpY2ggaXMgZm9yIE1QTFMgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJsaW5nIG5ldHdv cmsuDQo+ID4gV2UgaGF2ZSBwb2ludGVkIG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJv dXRlcnMgaW4gREMNCj4gPiBiYXJlbHkgc3VwcG9ydCBHUkUgYmFzZWQgbG9hZCBiYWxhbmNpbmcg YW5kIE1QTFMtaW4tR1JFDQo+ID4gYXJlIGJhcmVseSB1c2VkIGluIFNQIG5ldHdvcmtzIHRvby4g TW9zdCBvZiByb3V0ZXJzIGluIERDDQo+ID4gcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkIGJh bGFuY2luZyBub3cuDQo+IA0KPiBOb3csIGl0IGlzIGltcG9ydGFudCwgaW4gbXkgb3BpbmlvbiB0 byB1bmRlcnN0YW5kIHdoZXRoZXIgeW91IGFyZQ0KPiBhdHRlbXB0aW5nIHRvDQo+IHNvbHZlIGEg Z2VuZXJhbCBNUExTLWluLUlQIGVudHJvcHkgcHJvYmxlbSwgb3IgYXR0ZW1wdGluZyB0byBzb2x2 ZSBhDQo+IHNwZWNpZmljIERDDQo+IGludGVyY29ubmVjdCBwcm9ibGVtIGZvciBjb25uZWN0aXZp dHkgb3ZlciBub24tTVBMUyBjb3Jlcy4gSW4gdGhlDQo+IGZvcm1lciBjYXNlLA0KPiBpdCB3b3Vs ZCBub3QgYmUgdW5yZWFzb25hYmxlIGZvciB1cyB0byB0cnkgdG8gd29yayBvdXQgd2hhdCB0aGUg ZGVtYW5kDQo+IGlzOiB0aGUNCj4gcHJvYmxlbSBpcyB1bmRlcnN0YW5kYWJsZSBmcm9tIGFuIGFj YWRlbWljIHBvaW50IG9mIHZpZXcsIGJ1dCBhcmUNCj4gcGVvcGxlDQo+IGNhcnJ5aW5nIE1QTFMg b3ZlciBJUCB0b2RheSwgYW5kIGlmIHNvLCBkbyB0aGV5IHNlZSB0aGlzIHByb2JsZW0/IEluDQo+ IHRoZSBsYXR0ZXINCj4gY2FzZSwgaXQgaXMgc2Vuc2libGUgdG8gZGlzY3VzcyB3aXRoIE5WTzMg d2hldGhlciB0aGlzIGlzIGFkZHJlc3NpbmcNCj4gdGhlIERDDQo+IGludGVyY29ubmVjdCAoTDMg b3ZlcmxheSkgcHJvYmxlbSBpbiBhIG1lYW5pbmdmdWwgd2F5Lg0KPiANCj4gVGhhbmtzLA0KPiBB ZHJpYW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPiBPZiBMdWN5DQo+ID4geW9uZw0KPiA+IFNlbnQ6IDIwIERlY2VtYmVyIDIwMTIgMTU6MzkN Cj4gPiBUbzogU2hhbmUgQW1hbnRlDQo+ID4gQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLQ0KPiA+IGNoYWlyc0B0b29scy5pZXRmLm9y Zw0KPiA+IFN1YmplY3Q6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRl cmx5aW5nIG5ldHdvcmsNCj4gPg0KPiA+IEhpIFNoYW5lLA0KPiA+DQo+ID4gSSB1bmRlcnN0YW5k IG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBzdWxhdGlvbiB0byBhbiBleGlzdGluZw0K PiBuZXR3b3JrLg0KPiA+DQo+ID4gSG93ZXZlciwgTVBMUy1pbi1VRFAgZG9lcyBub3QgYWltIG9u IGNoYW5naW5nIGV4aXN0aW5nIFNQIElQL01QTFMNCj4gbmV0d29yayBhdA0KPiA+IGFsbC4NCj4g PiBNUExTLWluLVVEUCBpcyB0byBlbmFibGUgTVBMUyBjbGllbnQgbGF5ZXIgdG8gYmUgZGVjb3Vw bGVkIGZyb20gTVBMUw0KPiBzZXJ2ZXINCj4gPiBsYXllciBhbmQgdXNlIE1QTFMgY2xpZW50IGxh eWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFzIGENCj4gdW5kZXJseWluZw0KPiA+ IG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBmb3IgREMuIFlvdSBt YXkgYXJndWUgd2h5DQo+IG5vdCB1c2UNCj4gdGhlDQo+ID4gR1JFIHdoaWNoIGlzIGZvciBNUExT IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybGluZyBuZXR3b3JrLiBXZSBoYXZlDQo+IHBvaW50ZWQg b3V0DQo+ID4gaW4gdGhlIGRyYWZ0IHRoYXQgY3VycmVudCByb3V0ZXJzIGluIERDIGJhcmVseSBz dXBwb3J0IEdSRSBiYXNlZCBsb2FkDQo+IGJhbGFuY2luZw0KPiA+IGFuZCBNUExTLWluLUdSRSBh cmUgYmFyZWx5IHVzZWQgaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRlcnMNCj4gaW4g REMNCj4gPiBwZXJmb3JtIHVwZCBwb3J0IGJhc2VkIGxvYWQgYmFsYW5jaW5nIG5vdy4NCj4gPg0K PiA+IEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhlIFVEUCBlbmNhcHN1bGF0 aW9uIGhhcw0KPiBhZHZhbnRhZ2Ugb3Zlcg0KPiA+IEdSRSBlbmNhcHN1bGF0aW9uIHRvby4gSW4g VURQIGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZSBoZWFkZXINCj4gZGVjb3VwbGVzIHRoZQ0KPiA+ IG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29yayBjbGVhcmx5LCBpLmUuIG91dGVyIGhlYWRl ciBhbmQgb3ZlcmxheQ0KPiBoZWFkZXIuDQo+ID4gVURQIGJlbG9uZ3MgdG8gb3V0ZXIgaGVhZGVy LCB3aGljaCB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBvbmx5Lg0KPiBIb3dldmVyLA0KPiA+IEdS RSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9yIHRoZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMg dGhlIGtleQ0KPiBmaWVsZCBmb3INCj4gZmxvdw0KPiA+IGVudHJvcHkuIEZvciBsb2FkIGJhbGFu Y2luZywgaXQgcmVxdWlyZXMgdGhlIHVuZGVybHlpbmcgbmV0d29yayB1c2VzDQo+IEdSRQ0KPiBo ZWFkZXINCj4gPiB0b28uIEluIHNob3J0LCBHUkUgdGllcyB0aGUgb3ZlcmxheSBhbmQgdW5kZXJs eWluZyBuZXR3b3JrcyB0b2dldGhlci4NCj4gU2luY2UgaXQNCj4gaGFzDQo+ID4gbm90IHVzZWQg YSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaA0K PiBjb3VwbGluZy4NCj4gPg0KPiA+IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0b3dhcmQgbmV0d29y ayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGFuZA0KPiBkZWNvdXBsZXMNCj4gPiBvdmVybGF5IG5l dHdvcmtzIGZyb20gdGhlIHVuZGVybHlpbmcgbmV0d29yay4gQSBjbGVhciBzZXBhcmF0aW9uIG9m DQo+IG92ZXJsYXkNCj4gPiBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlzIGEgIk1VU1Qi IGluIG15IG9waW5pb24uIElmIHdlIGNvdW50DQo+IEdSRSBhcyB0aGUNCj4gPiBvdmVybGF5IGhl YWRlciwgdGhlbiBmb3IgSVB2NCB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxk DQo+IGZvciB0aGUNCj4gZmxvdw0KPiA+IGVudHJvcHkuIFRoaXMgaXMgdGhlIHJlYXNvbiB3ZSBw cm9wb3NlIHRoZSBVRFAgZW5jYXBzdWxhdGlvbjogZm9yIGFuDQo+IElHUCBiYXNlZA0KPiA+IHVu ZGVybHlpbmcgbmV0d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkgbmV0 d29yaw0KPiBiZXNpZGUgTVBMUw0KPiA+IGNsaWVudCBsYXllciAoZS5nLiBWWExBTiwgTDJUUC1p bi1VRFAsIGV0YykuDQo+ID4NCj4gPiBZb3UgcG9pbnQgb3V0IHVzaW5nIE1QTFMtaW4tTDJUUC1p bi1VRFAgaW5zdGVhZC4gWWVzLCBNUExTLWluLUwyVFAtDQo+IGluLVVEUA0KPiA+IHNjaGVtYSBh bHNvIHByb3ZpZGVzIGEgb3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKSBuZXR3b3Jr DQo+IGRlY291cGxpbmcuDQo+ID4gTDJUUCBwcm90b2NvbCAocmZjMzkzMSkgcHJvdmlkZXMgZ29v ZCBzZWN1cml0eSBtZWNoYW5pc20gYW5kIGhhcyB0aGUNCj4gPiBlbWJlZGRlZCBjb250cm9sIGZ1 bmN0aW9uIHRvby4gVGhlcmVmb3JlLCBzb21lb25lIGNhbiB1c2UgaXQgZm9yIE1QTFMNCj4gY2xp ZW50DQo+ID4gbGF5ZXIgb3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudCBsYXllciBv dmVyIGFuIElHUCB1bmRlcmxpbmcNCj4gbmV0d29yaywNCj4gPiBJTU86IE1QTFMtaW4tTDJUUC1p bi1VRFAgaXMgYSBvdmVya2lsbCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZA0KPiBhIHNj aGVtYQ0KPiA+IHRvIHN1cHBvcnQgSUdQIHVuZGVybHlpbmcgdHJhbnNwb3J0IHdpdGhvdXQgdG91 Y2hpbmcgYSBvdmVybGF5IGhlYWRlci4NCj4gVURQDQo+ID4gZW5jYXBzdWxhdGlvbiBpcyB0aGUg YmVzdCBjaG9pY2UgdG8gYWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGUNCj4gY2hhbmdl cw0KPiBvbg0KPiA+IGV4aXN0aW5nIHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVy cywgbm8gY2hhbmdlIG9uIHRyYW5zaXQNCj4gcm91dGVycy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ ID4gTHVjeQ0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gPiA+ IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA0OjE0IEFNDQo+ID4gPiBUbzogU2hh bmUgQW1hbnRlDQo+ID4gPiBDYzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQt eHUtbXBscy1pbi0NCj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPiA+ID4gbXBsc0BpZXRmLm9yZzsg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IERpc2N1c3Npb24gb24g aG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIgVURQIHR1bm5lbHMNCj4gPiA+DQo+ID4gPiBIaSBT aGFuZSwNCj4gPiA+DQo+ID4gPiBUaGFua3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBhbmQg cGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4gTm90ZTogSSBjaGFu Z2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdzIHN1Z2dlc3Rpb24uDQo+ID4g Pg0KPiA+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ID4gt6K8/sjLOiBTaGFuZSBBbWFu dGUgW21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXRdDQo+ID4gPiA+ILeiy83KsbzkOiAyMDEy xOoxMtTCMTnI1SAyMjozOA0KPiA+ID4gPiDK1bz+yMs6IFh1eGlhb2h1DQo+ID4gPiA+ILOty806 IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4gPiB1 ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4gPiA+IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQo+ID4gPiA+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2Ug aGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4gPiBtcGxzLWluLXVkcCBhbg0KPiA+ ID4gPiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPiA+ID4NCj4gPiA+ID4gWGlhb2h1 LA0KPiA+ID4gPg0KPiA+ID4gPiBPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUwIFBNLCBYdXhpYW9o dSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4NCj4gd3JvdGU6DQo+ID4gPiA+IC0tLS0t08q8/tStvP4t LS0tLQ0KPiA+ID4gPiA+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3Rs ZXBvaW50Lm5ldF0NCj4gPiA+ID4gPj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDExOjU4DQo+ ID4gPiA+ID4+IMrVvP7IyzogUm9nZXJzLCBKb3NoDQo+ID4gPiA+ID4+ILOty806IFNoYWhyYW0g RGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPiA+IHVkcEB0b29scy5pZXRm Lm9yZzsNCj4gPiA+ID4gPj4gbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmcNCj4gPiA+ID4gPj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1 cHBvcnQgdG8gbWFrZSBkcmFmdC0NCj4geHUtDQo+ID4gPiBtcGxzLWluLXVkcA0KPiA+ID4gPiBh bg0KPiA+ID4gPiA+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPiA+ID4gPj4NCj4g PiA+ID4gPj4NCj4gPiA+ID4gPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJz LCBKb3NoIg0KPiA+ID4gPGpvc2gucm9nZXJzQHR3Y2FibGUuY29tPg0KPiA+ID4gPiA+PiB3cm90 ZToNCj4gPiA+ID4gPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBz ZWUgdGhlIHByb2JsZW0gdGhpcw0KPiA+ID4gc29sdXRpb24NCj4gPiA+ID4gPj4+IGFkZHJlc3Nl cyBpbiBwcmFjdGljZSBhbnkgbG9uZ2VyLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiArMS4gIFBs ZWFzZSBkbyBub3QgZGVmaW5lIHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUA0KPiBlbmNhcHN1bGF0 aW9uLg0KPiA+ID4gVGhlDQo+ID4gPiA+IElFVEYNCj4gPiA+ID4gPj4gYWxyZWFkeSBzdGFuZGFy ZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvDQo+ID4gPiBzdGFuZGFyZGl6 ZWQNCj4gPiA+ID4gTVBMUw0KPiA+ID4gPiA+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhh ZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdA0KPiBvbmUsDQo+ID4gPiB2ZXJ5DQo+ ID4gPiA+ID4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3Vw cG9ydCBjYXJyaWFnZQ0KPiBvZg0KPiA+ID4gTDNWUE4gb3Zlcg0KPiA+ID4gPiBhbg0KPiA+ID4g PiA+PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIaSBTaGFuZSwNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFRoYW5rIHlvdSBmb3IgdGVsbGluZyB1cyB0aGVyZSBhcmUgYWN0 dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMNCj4gb3Zlcg0KPiA+ID4gSVAgaW4gYXQNCj4gPiA+ID4g bGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJl IHZlcnkNCj4gPiA+IHZhbHVhYmxlIHRvIHRob3NlDQo+ID4gPiA+IHBlb3BsZSB3aG8gaGFkIGJl bGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1QTFMgb3ZlciBJUA0KPiBpbg0KPiA+ ID4gdG9kYXkncyBTUA0KPiA+ID4gPiBuZXR3b3Jrcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+PiBT ZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4g PiA+ID4gPj4gW05PVEU6IHRoZSBkYXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJh Y2sgaW4gdGhlIDIwMDYNCj4gPiA+ID4gdGltZWZyYW1lIV0NCj4gPiA+ID4gPj4gICAgIFJGQyA0 NjY1IGZvciByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBWUExTIHRoYXQgc2F5IHRoYXQNCj4gVlBM Uw0KPiA+ID4gbWF5IGJlDQo+ID4gPiA+ID4+IGNhcnJpZWQgb3ZlciBMMlRQdjMNCj4gPiA+ID4g Pj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVu ZG9yIGhhcw0KPiA+ID4gPiBpbXBsZW1lbnRlZA0KPiA+ID4gPiA+PiBJUFZQTidzIG92ZXIgTDJU UHYzOg0KPiA+ID4gPiA+Pg0KPiA+ID4NCj4gaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9j cy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0aW9uLiBBcyBt ZW50aW9uZWQgaW4NCj4gPiA+IHRoaXMgZHJhZnQNCj4gPiA+ID4gQU5EIG90aGVyIGRyYWZ0cywg dGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb24gb24NCj4gdGhlDQo+ ID4gPiBTZXNzaW9uDQo+ID4gPiA+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRo ZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXINCj4gYXMNCj4gPiA+IGRlZmluZWQgaW4NCj4g PiA+ID4gW1JGQyA1NjQwXSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRlZCBieSBleGlzdGluZyBjb3Jl IHJvdXRlcnMgc28NCj4gZmFyLg0KPiA+ID4gPg0KPiA+ID4gPiBGV0lXLCBJIGhhdmUgaGFkIHN1 Y2Nlc3MsIGluIHRoZSByZWxhdGl2ZWx5IHJlY2VudCBwYXN0LCBpbg0KPiA+ID4gcmVxdWVzdGlu ZyBhIGNvcmUNCj4gPiA+ID4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhl IGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4gPiBjYWxjdWxhdGlvbnMgaW4NCj4gPiA+ID4g X2V4aXN0aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkpIHRocm91 Z2hvdXQgbXkNCj4gPiA+IG5ldHdvcmsuDQo+ID4gPiA+IEZ1cnRoZXIsIEkgc3VzcGVjdCB0aGF0 IG1vc3QgbGFyZ2UgbmV0d29yayBvcGVyYXRvcnMgYXJlIHNhdnZ5DQo+IGZvbGtzDQo+ID4gPiBh bmQNCj4gPiA+ID4gdW5kZXJzdGFuZCB0aGUgaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIHRoZWly IEhXIGZhaXJseSB3ZWxsLiAgQXMNCj4gYQ0KPiA+ID4gcmVzdWx0LCB0aG9zZQ0KPiA+ID4gPiBz YW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJs ZSBpbg0KPiB0aGlzDQo+ID4gPiByZWdhcmQuDQo+ID4gPiA+IFRodXMsIGl0IG1heSBiZSBhIHF1 ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UNCj4gdGhlaXINCj4gPiA+ IEhXDQo+ID4gPiA+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlhdGUgY2hhbmdlcyBpbiB0 aGVpciBlcXVpcG1lbnQgdG8NCj4gYWNoaWV2ZQ0KPiA+ID4gdGhlaXINCj4gPiA+ID4gYnVzaW5l c3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJlIG5lY2Vzc2FyeSAu Li4NCj4gc2VlDQo+ID4gPiBiZWxvdy4NCj4gPiA+DQo+ID4gPiBDb3VsZCB5b3UgcGxlYXNlIGJy aWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJvdmUgY2hhbmdlIGluDQo+ID4gPiBFWElT VElORyBoYXJkd2FyZSBvZiBhbHJlYWR5IGRlcGxveWVkIGNvcmUgcm91dGVycz8NCj4gPiA+DQo+ ID4gPiA+ID4gSW4gY29udHJhc3QsIG1vc3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBhbHJl YWR5IGNhcGFibGUgb2YNCj4gPiA+IGJhbGFuY2luZyBJUA0KPiA+ID4gPiB0cmFmZmljIGZsb3dz IGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVEUCBwYWNrZXRzLg0KPiBC eQ0KPiA+ID4gdXNpbmcgdGhlDQo+ID4gPiA+IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24sIHRo ZSBhbHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJhbGFuY2luZw0KPiA+ID4gY2FwYWJpbGl0eSBvZg0K PiA+ID4gPiBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJhZ2VkIHdpdGhv dXQgcmVxdWlyaW5nIGFueQ0KPiA+ID4gY2hhbmdlIHRvDQo+ID4gPiA+IHRoZW0uIFRoYXQgaXMg dGhlIG1ham9yIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdC4NCj4gPiA+ID4NCj4gPiA+ID4gSWYg dGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBp bg0KPiA+ID4gTVBMUy9MMlRQdjMsIHdoaWNoDQo+ID4gPiA+IHVzZXMgVURQL0lQLCBpbiB0aGUg Zmlyc3QgcGxhY2U/DQo+ID4gPg0KPiA+ID4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwg eW91IHByZWZlciB0byB1c2UgTVBMUy1pbi1MMlRQdjMtaW4tDQo+IFVEUA0KPiA+ID4gaW5zdGVh ZCBvZiBNUExTLWluLVVEUCwgcmlnaHQ/DQo+ID4gPg0KPiA+ID4gPiBJTUhPLCBhIGJldHRlciBw cm9wb3NhbCBtYXkgYmUgdG8gY29uc2lkZXIgYSBbbWlub3JdICg/KSBjaGFuZ2UNCj4gdG8NCj4g PiA+IFJGQyAzOTMxLA0KPiA+ID4gPiB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1 c2VkIGZvciBkYXRhIHBhY2tldHMgKG5vdA0KPiBjb250cm9sDQo+ID4gPiBwYWNrZXRzKQ0KPiA+ ID4gPiB0byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAg YWRkcmVzc2VzKSwNCj4gYmFzZWQNCj4gPiA+IG9uIGEgaGFzaA0KPiA+ID4gPiBjYWxjdWxhdGlv biwgdG8gYWNoaWV2ZSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgb3ZlciBleGlzdGluZw0KPiBlcXVp cG1lbnQNCj4gPiA+IGluIGFuDQo+ID4gPiA+IElQLW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3Rl bSBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYmV0dGVyDQo+IG9mZg0KPiA+ID4ganVzdCB1c2lu Zw0KPiA+ID4gPiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUg ZGVtdWx0aXBsZXhvciB0bw0KPiA+ID4gYXNzb2NpYXRlDQo+ID4gPiA+IGluY29taW5nIHBhY2tl dHMgd2l0aCB0aGUgYXNzb2NpYXRlZCBMMlRQIENvbnRyb2wgQ2hhbm5lbC4gIEluDQo+IGZhY3Qs DQo+ID4gPiBpdCdzIG5vdA0KPiA+ID4gPiBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGltcGxl bWVudGF0aW9ucyBtYXkgL2FscmVhZHkvIGRvIHRoaXMsDQo+ID4gPiBtYWtpbmcgYW55DQo+ID4g PiA+ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBM MlRQIGVuZC0NCj4gc3lzdGVtDQo+ID4gPiA+IGltcGxlbWVudGF0aW9ucy4NCj4gPiA+ID4NCj4g PiA+ID4gVGhlIGJlYXV0eSBvZiB0aGUgYWJvdmUgYXBwcm9hY2ggaXM6DQo+ID4gPiA+IDEpIEkg d291bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBp cw0KPiA+ID4gbGltaXRlZCB0byB0aGUNCj4gPiA+ID4gImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3 YXJlKSBvZiBleGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gPiA+IGltcGxlbWVudGF0aW9ucy4N Cj4gPiA+ID4gSGVjaywgaXQgbWF5IGV2ZW4gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBl eGlzdGluZyBMMlRQdjMNCj4gPiA+ID4gaW1wbGVtZW50YXRpb25zLiAgKEwyVFB2MyBpbXBsZW1l bnRvcnMgd291bGQgbmVlZCB0byBjb21tZW50IG9uDQo+IHRoYXQpLg0KPiA+ID4NCj4gPiA+IElN SE8sIG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsICB0aGUg aGFyZHdhcmUNCj4gb2YNCj4gPiA+IFBFIHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUu Zy4sIGluZ3Jlc3MgUEUgcm91dGVycyBuZWVkIHRvDQo+IGZpbGwNCj4gPiA+IGluIGFuIGVudHJv cHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiA+ID4N Cj4gPiA+ID4gMikgVGhlcmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0 cyBieSB1c2luZw0KPiAiU2Vzc2lvbg0KPiA+ID4gSUQiIGFuZA0KPiA+ID4gPiAiQ29va2llIiBm aWVsZHMgdG8gZW5zdXJlIHRoZSByZWNlaXZlZCBMMlRQdjMgcGFja2V0IGlzIGludGVuZGVkDQo+ IGZvcg0KPiA+ID4gdGhlDQo+ID4gPiA+IGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJv bSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gPiA+ID4gLS0tc25pcC0tLQ0KPiA+ID4gPiAg ICBMMlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAz Mi1iaXQNCj4gPiA+IFNlc3Npb24NCj4gPiA+ID4gICAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhl YWRlci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWUNCj4gPiA+ID4gICAgKGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8NCj4g ZW5zdXJlDQo+ID4gPiA+ICAgIHRoYXQgYW4gYXJyaXZpbmcgcGFja2V0IGlzIGludGVuZGVkIGZv ciB0aGUgaWRlbnRpZmllZCBzZXNzaW9uLg0KPiA+ID4gPiAgICBUaHVzLCB1c2Ugb2YgYSBDb29r aWUgd2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0KPiA+ID4gZ3VhcmFudGVl DQo+ID4gPiA+ICAgIHRoYXQgdGhlIFNlc3Npb24gSUQgbG9va3VwIHdhcyBwZXJmb3JtZWQgcHJv cGVybHkgYW5kIHRoYXQgdGhlDQo+ID4gPiA+ICAgIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3Qg Y29ycnVwdGVkIGluIHRyYW5zaXQuDQo+ID4gPiA+IC0tLXNuaXAtLS0NCj4gPiA+ID4gLi4uIGlu IHJlZ2FyZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWEN Cj4gZm9sa3MNCj4gPiA+IGhhdmUsIGluIHRoZQ0KPiA+ID4gPiBwYXN0LCBoYWQgL3N1YnN0YW50 aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9uIG9mIE1QTFMgb3Zlcg0KPiBJUA0KPiA+ ID4gdHJhbnNwb3J0Lg0KPiA+ID4gPiBJbiBmYWN0LCB0aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQg aW4gU2VjdGlvbiA3LjYsICJTZWN1cml0eSIsIG9mDQo+IFJGQw0KPiA+ID4gNDY2NS4NCj4gPiA+ ID4gKFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQg dXNlIE1QTFMNCj4gZm9yDQo+ID4gPiB0cmFuc3BvcnQpLg0KPiA+ID4gPiBXaGlsZSBJJ20gbm90 IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0KPiA+ ID4gZGFpbHkgdHJhZmZpYyBvbg0KPiA+ID4gPiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEkn bSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsDQo+ID4gPiBhcmlzZSBpZi93aGVu IHRoaXMNCj4gPiA+ID4gZHJhZnQgZ29lcyB0byB0aGUgSUVTRyAuLi4NCj4gPiA+DQo+ID4gPiBJ ZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGUgcmVhc29uIGZvciB5b3VyIHByZWZlcmVu Y2Ugb2YNCj4gTVBMUy0NCj4gPiA+IGluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBoYXMgYW4g YWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdA0KPiBpcw0KPiA+ID4gc28gY29uY2VybmVk LCBjYW4geW91IGV4cGxhaW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXINCj4g dGhhbg0KPiA+ID4gTVBMUy1pbi1MMlRQIGluIHByYWN0aWNlPw0KPiA+ID4NCj4gPiA+IEJlc3Qg cmVnYXJkcywNCj4gPiA+IFhpYW9odQ0KPiA+ID4NCj4gPiA+ID4gMykgRmluYWxseSwgdGhpcyBh cHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQNCj4gaW1wbGVtZW50DQo+ ID4gPiBMMlRQLCBmb3INCj4gPiA+ID4gdHVubmVsaW5nIG9mIE1QTFMvSVAsIGFuZCBkb2VzIG5v dCByZXF1aXJlIGFuIGVudGlyZSBpbmR1c3RyeSB0bw0KPiA+ID4gc3VwcG9ydA0KPiA+ID4gPiBN UExTL1VEUCBlbmNhcHN1bGF0aW9uIGluIHRoZWlyIHByb2R1Y3QgbGluZXMuDQo+ID4gPiA+DQo+ ID4gPiA+IC1zaGFuZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQmVz dCByZWdhcmRzLA0KPiA+ID4gPiA+IFhpYW9odQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+IElmIHRo ZXJlIHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92ZXIgSVAsIHRoZW4gY2xlYXJseSBpdA0K PiB3b3VsZA0KPiA+ID4gaGF2ZQ0KPiA+ID4gPiBiZWVuDQo+ID4gPiA+ID4+IG1vcmUgd2lkZWx5 IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExTDQo+ID4g PiBvdmVyDQo+ID4gPiA+IEdSRSBvcg0KPiA+ID4gPiA+PiBNUExTIG92ZXIgTDJUUHYzLiAgKFdo ZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkNCj4gd291bGQNCj4gPiA+IG5v dGUNCj4gPiA+ID4gdGhhdA0KPiA+ID4gPiA+PiB0aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlz IGRpZCBub3QgcGFuIG91dCB3YXMgdGhlcmUgYXJlDQo+IHNldmVyYWwsDQo+ID4gPiBwcmFjdGlj YWwNCj4gPiA+ID4gPj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25lIGdldHMgZnJvbSBnb2luZyB3 aXRoIG5hdGl2ZSBNUExTDQo+ID4gPiA+ID4+IGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nIHdpdGhp biB0aGUgZGF0YSBwbGFuZSwgbmFtZWx5Og0KPiA+ID4gPiA+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0 ZQ0KPiA+ID4gPiA+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPiA+ID4gPiA+PiAuLi4g dG8gbmFtZSwgYnV0IGEgZmV3LiAgVGhvc2UgaGF2ZSB0ZW5kZWQgdG8gYmUgcXVpdGUNCj4gY29t cGVsbGluZw0KPiA+ID4gPiBhcmd1bWVudHMNCj4gPiA+ID4gPj4gdG8gJ3VwZ3JhZGUnIG5ldHdv cmsgSFcgdG8gc3VwcG9ydCBNUExTDQo+IGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPiA+ID4g PiA+Pg0KPiA+ID4gPiA+PiAtc2hhbmUNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4NCj4gPiA+ID4g Pj4+IC1Kb3NoDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IE9uIDEyLzE4 LzEyIDEyOjMxIEFNLCAiU2hhaHJhbSBEYXZhcmkiIDxkYXZhcmlAYnJvYWRjb20uY29tPg0KPiA+ ID4gPiB3cm90ZToNCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+Pj4gRm9yIHNlcnZpY2UgcHJvdmlk ZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZA0KPiB0aGVyZSBpcw0KPiA+ID4g bm8gbmVlZA0KPiA+ID4gPiA+Pj4+IHRvIGltcHJvdmUgaXQuDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ ID4gPj4+PiBSZWdhcmRzLA0KPiA+ID4gPiA+Pj4+IFNoYWhyYW0NCj4gPiA+ID4gPj4+Pg0KPiA+ ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4gT24gRGVjIDE3LCAyMDEyLCBhdCA4OjAyIFBNLCAiWHV4 aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPj4+ Pg0KPiA+ID4gPiA+Pj4+PiBTaGFocmFtLA0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBU aGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUA0KPiA+ ID4gZW5jYXBzdWxhdGlvbg0KPiA+ID4gPiA+Pj4+PiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2Fk LWJhbGFuY2luZyBhcHBsaWNhYmlsaXR5IHNvIGZhciB0bw0KPiA+ID4gdGhvc2UNCj4gPiA+ID4g Pj4+Pj4gb3BlcmF0b3JzIHdobyBoYXBwZW4gdG8gcmVxdWlyZSB0cmFuc3BvcnRpbmcgTVBMUw0K PiBhcHBsaWNhdGlvbg0KPiA+ID4gdHJhZmZpYw0KPiA+ID4gPiA+Pj4+PiBhY3Jvc3MgSVAgbmV0 d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQLCBOVkdSRQ0KPiBhbmQNCj4g PiA+ID4gVlhMQU4NCj4gPiA+ID4gPj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBhZHZvY2F0b3Jz IGFuZCB1c2UgY2FzZXMuIElmIHlvdQ0KPiBhYnNvbHV0ZWx5DQo+ID4gPiBiZWxpZXZlDQo+ID4g PiA+ID4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRp b24gdHJhZmZpYw0KPiA+ID4gYWNyb3NzIElQDQo+ID4gPiA+ID4+Pj4+IG5ldHdvcmtzIGFuZCB0 aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMNCj4gb3Zlcg0KPiA+ ID4gSVANCj4gPiA+ID4gPj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMgc2hvdWxkIGJlIG1vdmVk IHRvIEhpc3RvcmljIHN0YXR1cywNCj4gcGxlYXNlDQo+ID4gPiBzYXkNCj4gPiA+ID4gc28uDQo+ ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4g PiA+ID4gPj4+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4gPiA+IGFyY2hpdmUvd2Vi L252bzMvY3VycmVudC9tc2cwMTg2NC5odG1sKSBpcw0KPiA+ID4gPiA+Pj4+PiBqdXN0IHRoZSBy aWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZQ0KPiBmb2xsb3dpbmcNCj4g PiA+IGFyZ3VtZW50DQo+ID4gPiA+ID4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJh c2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGENCj4gPiA+IGNlbnRlcnMpLiBJDQo+ID4gPiA+ ID4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5 LA0KPiA+ID4gc3VycHJpc2luZ2x5IHNpbGVudA0KPiA+ID4gPiA+Pj4+PiB0aWxsIG5vdy4NCj4g PiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gU2lnaCwgSSBkaWRuJ3QgaW50ZW5kIHRvIHNheSB0 aGUgYWJvdmUgb3RoZXJ3aXNlLg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBYaWFvaHUN Cj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4g PiA+Pj4+Pj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmddDQo+ILT6DQo+ID4gPiCx7Q0KPiA+ID4gPiA+PiBTLg0KPiA+ID4gPiA+Pj4+ Pj4gRGF2YXJpDQo+ID4gPiA+ID4+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjE1yNUgMTM6MzQN Cj4gPiA+ID4gPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+ID4gPiA+Pj4+Pj4gs63L zTogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+ ID4gPiA+ID4+Pj4+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+ID4gPiA+Pj4+Pj4g 1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZQ0K PiA+ID4gPiA+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPiA+ID4gPj4+Pj4+IG1w bHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPiA+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4+ IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBp bg0KPiA+ID4gdG9kYXkncw0KPiA+ID4gPiA+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+ID4gPiA+ID4+ Pj4+PiBhbmQgY29yZSwgd2hlcmUgTVBMUyBpcyBkb21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0 aWNhbA0KPiA+ID4gYXBwbGljYXRpb24NCj4gPiA+ID4gPj4+Pj4+IGluIGluIGRhdGENCj4gPiA+ ID4gPj4+Pj4+IGNlbnRlciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29s dXRpb25zIHN1Y2gNCj4gYXMNCj4gPiA+IE5WR1JFDQo+ID4gPiA+IGFuZA0KPiA+ID4gPiA+Pj4+ Pj4gVlhMQU4uDQo+ID4gPiA+ID4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4gSXQgc2VlbXMgdGhlIGF1 dGhvcnMgYXJlIHRyeWluZyB0byBieXBhc3MgdGhlIE5WTzMNCj4gc29sdXRpb24NCj4gPiA+IHNl bGVjdGlvbg0KPiA+ID4gPiA+Pj4+Pj4gcHJvY2Vzcw0KPiA+ID4gPiA+Pj4+Pj4gYnkgYWR2YW5j aW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KPiA+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4+ IFJlZ2FyZHMsDQo+ID4gPiA+ID4+Pj4+PiBTaGFocmFtDQo+ID4gPiA+ID4+Pj4+Pg0KPiA+ID4g PiA+Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9h IEFuZGVyc3NvbiA8bG9hQHBpLm51Pg0KPiB3cm90ZToNCj4gPiA+ID4gPj4+Pj4+DQo+ID4gPiA+ ID4+Pj4+Pj4gV29ya2luZyBncm91cCwNCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+ IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPiA+ID4g Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcC0wNiBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQuDQo+ID4gPiA+ID4+Pj4+Pj4gRHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlz IHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQNCj4gd2l0aA0KPiA+ID4gb25lIHdlZWsuDQo+ID4gPiA+ ID4+Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBw b3J0L25vdCBzdXBwb3J0KSB0byB0aGUNCj4gbXBscw0KPiA+ID4gPiB3b3JraW5nDQo+ID4gPiA+ ID4+Pj4+Pj4gZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzIGF0IGlldGYub3JnKS4gUGxlYXNlIGdp dmUgYW4NCj4gPiA+IHRlY2huaWNhbA0KPiA+ID4gPiA+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZg0KPiB5b3UNCj4gPiA+IHRoaW5r IHRoYXQNCj4gPiA+ID4gPj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVk IGFzIGEgd29ya2luZyBncm91cA0KPiA+ID4gZG9jdW1lbnQuDQo+ID4gPiA+ID4+Pj4+Pj4NCj4g PiA+ID4gPj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KPiA+ID4gPiA+ Pj4+Pj4+DQo+ID4gPiA+ID4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRo aXMgZG9jdW1lbnQgLQ0KPiA+ID4gPiA+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvaXByLzE5NDEvIC4NCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+IEFsbCB0aGUg YWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cA0KPiA+ID4g bWFpbGluZyBsaXN0DQo+ID4gPiA+ID4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2Yg YW55IG90aGVyIElQUiBjbGFpbXMgdGhhbg0KPiB0aG9zZQ0KPiA+ID4gYWxyZWFkeQ0KPiA+ID4g PiA+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+IEhv d2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZvcg0K PiB0aGUNCj4gPiA+IElQUg0KPiA+ID4gPiA+Pj4+Pj4+IHBvbGwpDQo+ID4gPiA+ID4+Pj4+Pj4g TWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4NCj4gTWFy c2hhbGwNCj4gPiA+IGhhcw0KPiA+ID4gPiA+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJh Y3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZw0KPiB0aGUNCj4gPiA+IGF1dGhvciB0ZWFt DQo+ID4gPiA+ID4+Pj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5n IGdyb3VwIGNoYWlycyBoYXMNCj4gPiA+IHRyaWVkIHRvDQo+ID4gPiA+ID4+Pj4+Pj4gY29udGFj dCBNYXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uDQo+IHRo ZQ0KPiA+ID4gSVBSDQo+ID4gPiA+ID4+Pj4+Pj4gcG9sbC4NCj4gPiA+ID4gPj4+Pj4+PiBXZSBo YXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4gPiA+ID4+Pj4+Pj4NCj4gPiA+ID4gPj4+ Pj4+PiBGcm9tIHZlcnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNo YWxsDQo+IGFzIGENCj4gPiA+ID4gPj4+Pj4+PiBjby1hdXRob3IuDQo+ID4gPiA+ID4+Pj4+Pj4N Cj4gPiA+ID4gPj4+Pj4+PiAvTG9hDQo+ID4gPiA+ID4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIp DQo+ID4gPiA+ID4+Pj4+Pj4gLS0NCj4gPiA+ID4gPj4+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pj4+DQo+ ID4gPiA+ID4+Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDoNCj4gPiA+ID4gPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQo+ID4gPiA+ID4+ Pj4+Pj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBp Lm51DQo+ID4gPiA+ID4+Pj4+Pj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAg ICBwaG9uZTogKzQ2IDEwIDcxNw0KPiA1MiAxMw0KPiA+ID4gPiA+Pj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KPiA+ID4gPiA+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiA+ID4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4+Pj4+PiBtcGxzQGll dGYub3JnDQo+ID4gPiA+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo+ID4gPiA+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ ID4gPj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4gPiA+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+Pj4+PiBtcGxzIG1haWxp bmcgbGlzdA0KPiA+ID4gPiA+Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ID4gPiA+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+Pj4g bXBscyBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4+PiBtcGxzQGlldGYub3JnDQo+ID4gPiA+ID4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gPiA+ID4+ Pg0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUNCj4gV2FybmVyDQo+ID4gPiBDYWJsZQ0KPiA+ID4g PiA+PiBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLCBvcg0KPiA+ID4gc3ViamVjdCB0bw0KPiA+ID4gPiA+PiBjb3B5cmlnaHQgYmVsb25n aW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcw0KPiBpbnRlbmRlZA0KPiA+ ID4gc29sZWx5IGZvcg0KPiA+ID4gPiB0aGUNCj4gPiA+ID4gPj4gdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmDQo+IHlvdQ0KPiA+ID4g YXJlIG5vdCB0aGUNCj4gPiA+ID4gPj4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWls LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZA0KPiB0aGF0DQo+ID4gPiBhbnkNCj4gPiA+ID4gZGlz c2VtaW5hdGlvbiwNCj4gPiA+ID4gPj4gZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlDQo+IGNvbnRlbnRzDQo+ID4gPiBvZiBhbmQNCj4gPiA+ ID4gPj4gYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBh bmQgbWF5IGJlDQo+ID4gPiB1bmxhd2Z1bC4gSWYgeW91DQo+ID4gPiA+ID4+IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+ID4g aW1tZWRpYXRlbHkgYW5kDQo+ID4gPiA+ID4+IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsDQo+IGFuZA0KPiA+ID4gYW55IHByaW50b3V0 Lg0KPiA+ID4gPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+ID4gPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4+PiBtcGxzQGll dGYub3JnDQo+ID4gPiA+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1haWxpbmcg bGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg0K From curtis@occnc.com Thu Dec 20 11:24:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F6621F89A4 for ; Thu, 20 Dec 2012 11:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAMBEFaX0Rdj for ; Thu, 20 Dec 2012 11:24:39 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5B48021F8994 for ; Thu, 20 Dec 2012 11:24:33 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id qBKJLwdF020158; Thu, 20 Dec 2012 14:21:58 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201212201921.qBKJLwdF020158@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 20 Dec 2012 15:49:01 GMT." <95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> Date: Thu, 20 Dec 2012 14:21:58 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 19:24:41 -0000 Carlos, See inline. In message <95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > > Hi, Curtis, > > Thanks for the response -- please see inline, skipping responses as > implicit Ack. > > On Dec 19, 2012, at 7:08 PM, Curtis Villamizar wrote: > > > > > Hi Carlos, > > > > I see Andy and Kireeti already replied. > > > > In message <95067C434CE250468B77282634C96ED3227D1CDC@xmb-aln-x02.cisco.com> > > "Carlos Pignataro (cpignata)" writes: > >> > >> Hi, Kireeti, > >> > >> This is a very nicely written document that covers important aspects. > >> > >> One early comment is that, in a way, this seems to actually be > >> multi-part document, including requirements, as well as compliance and > >> performance testing. One early question is whether it makes sense to > >> take each part separately (even in different WGs, with one as a BCP in > >> mpls in other in bmwg continuation of rfc5695). > >> > >> I also agree with Andy's comments about some PW specific pieces to this. > >> > >> Some more specific comments, hopefully these are clear and useful: > > > > The sections with questions to ask and testing are intentionally terse > > and serve only as outlines. This is to put a summary in one place. > > If BMWG wants to launch one or more documents to cover the testing in > > detailed benchmark specifications, they are more than welcome to do > > so. That is why we gave Al a heads up and why Al gave the BMWG > > mailing list a heads up. > > > > One concern with the terse specification of testing cases is that they > could use quite different methodology -- for example, how is the > determination required in T#10 performed? This document is not about testing methodology. Testing methodology should be specified in BMWG (if at all). This document needs only to say "You [chip vendor, system vendor, provider] need to 'text for X'". Only in cases were some might question whether such testing is even feasible should there be any mention of how to "test for X", and maybe not even then. Today most (or all) service providers do extensive unpublished testing of product (plus field trial) before deployment. The real world has a habit of producing far more challenging test cases than BMWG has and that is why equipment which benchmarks well often fails or performs poorly in service provider testing, and sometimes in field testing or worse yet in the field. In the absense of BMWG testing methodologies it is up to the tester (test organization as a whole) to figure out a way to "test for X". Even where BMWG testing methodologies exist it is up to the tester to figure out whether BMWG testing methodologies adequately "test for X". > > Of course, if there is consensus to break up this document into more > > than one, I'm OK with that approach. > > > >> 2.1. Forwarding Basics > >> > >> Should this section also include forwarding specifics about reserved > >> labels, and in particular RA. > > > > ... what Kireeti said. > > > > Yes we could reference the reserved label list and also if there is > > new work on "special purpose labels" we can reference that work too. > > > > So far RFC 3032 specifies RA and the NULL labels (RFC 3032 is > > obviously cited), the update to NULL is in RFC 4182 (cited), and GAL > > is defined in RFC 5586. We also cover EL and ELI (RFC 6790) in some > > detail. At this point that covers it for reserved labels. We can > > explicitly point out RA. > > > > We didn't cover OAM Alert Label #14 RFC3429 as use of ITU-T Y.1711 is > > strongly discouraged today. Y.1711 doesn't work at all for multipath > > and all service providers use multipath. > > > > When Kireeti's "special purpose labels" draft becomes a WG item we can > > point to "special purpose labels". I'm not sure what the WG concensus > > is on that. We still have 4-6 and 8-12 to assign, which should be > > plenty IMHO, but the extension mechanism can't hurt (too much). > > > > Its been pointed out in private email that some TP OAM functions > > require hardware support (DM, LM, and to a lesser extent CC/CV). The > > most challenging may be LM. Also PTP and NTP benefit from hardware > > support and the TICTOC work should be reflected here. > > > >> 2.3. MPLS Multipath Techniques > >> > >> ... > >> > >> The most common multipath techniques are ECMP applied at the IP > >> forwarding level, Ethernet LAG with inspection of the IP payload, and > >> multipath on links carrying both IP and MPLS, where the IP header is > >> inspected below the MPLS label stack. In most core networks, the > >> vast majority of traffic is MPLS encapsulated. > >> > >> In order to support an adequately even load distribution across > >> multiple links, IP addresses must be used. Common practice today is > >> to reinspect the IP addresses at each LSR and use the label stack and > >> IP addresses in a hash performed at each LSR. > >> > >> This description might appear oversimplified, especially in the > >> presence of BCP128. It was interesting that RFC 4928 is not cited, > >> when it contains a whole section on current ECMP practices at > >> http://tools.ietf.org/html/bcp128#section-2. Further, this section > >> describes how in addition to IP addresses, some cases use the label > >> stack (alone or in combination) as input into the hash for multipath. > > > > Both RFC4928 (BCP128) and RFC4385 are cited. RFC4928 section 2 is a > > little dated and represents the LCD in roughly 2004 or so when this > > draft was first introduced. > > > > In response to private email comments from Shane Anante the > > paragraph you pointed out as oversimplified had already been expanded. > > A lot more is now said about the so-called 5-tuple commonly used and > > the use of other fields. There is now a new section "2.3.5. Fields > > Used for Multipath" which we can put a forward reference to. > > > >> 2.3.1. Pseudowire Control Word > >> > >> Within the core of a network some form of multipath is almost certain > >> to be used. Multipath techniques deployed today are likely to be > >> looking beneath the label stack for an opportunity to hash on IP > >> addresses. > >> > >> A pseudowire encapsulated at a network edge must have a means to > >> prevent reordering within the core if the pseudowire will be crossing > >> a network core, or any part of a network topology where multipath is > >> used. > >> > >> Not supporting the ability to encapsulate a pseudowire with a control > >> word may lock a product out from consideration. A pseudowire > >> capability without control word support might be sufficient for > >> applications which are strictly both intra-metro and low bandwidth. > >> However a provider with other applications will very likely not > >> tolerate having equipment which can only support a subset of their > >> pseudowire needs. > >> > >> While I agree with this text, I wonder if it is attempting to set up a > >> new requirement. For example, although not 2119-capitalized, "A > >> pseudowire encapsulated at a network edge must have a means to prevent > >> reordering within the core". PWE3 has been discussing this topic, but > >> today's specs include PW Types for which a CW is optional. Similarly, > >> recommendations are already at this > >> http://tools.ietf.org/html/bcp128#section-3. > > > > What Andy said ... > > > > BTW- Andy has sent quite a lot of private email about PW which will be > > reflected in the next iteration. > > Thanks. > > > > >> 2.3.2. Pseudowire Flow Label > >> > >> ... > >> Any pseudowire which does not carry a flow label is in effect a > >> single microflow (in [RFC2475] terms). > >> > >> This is a bit of a corner-case nit, but for completeness: this is not > >> the case for IP L2 Transport PW without its optional CW (without flow > >> label) http://tools.ietf.org/html/rfc4447#section-4.1. > > > > People use L2TP? :-) > > Very much so -- but that is orthogonal to my comment, which is about > IP L2 and not L2TP. The point I was making was that this is an MPLS document. > > OK - PW with MPLS PSN, but then again this is an MPLS document. > > > > I don't see what point you are trying to make. > > Sorry if I managed to confuse you. Let me try again -- it is a nit. > > RFC 4447 (PW setup using LDP) defines in Section 4.1 (pointer included > above) the "IP Layer 2 Transport" Pseudowire (PW Type 0x000B). This is > a PW FEC, that when used without CW looks in the DP as an RFC 3032 > MPLS encapsulated IP datagram. It's used in arp-med, ipls, etc. > > I was just pointing out that for that particular PW, the multipath is > as if IP payload directly on MPLS (since it is in the DP). I do not > intend to convolute the description and remove generalization to > somehow cover this, but I thought I'd bring it up in case. AFAIK no one uses the LDP FEC to determine whether the payload is IP or not. It is also entirely useless if LDP is carried in RSVP-TE LSP as is often the case. This part of RFC 4447 says "The PW control word MAY be inserted between the MPLS label stack and the IP payload." If load balancing is desired, then either 1) don't insert a CW, or 2) add an entropy label, or 3) both. If If load balancing is *not* desired, then either 1) add a CW and either don't add an entropy label, or 2) add an entropy label with a fixed value for all packets in the PW. or 3) both. If you do this (above two paragraphs) then load split works exactly as intended in RFC4385 and RFC4928. Maybe this needs to be mentioned somewhere. > >> 2.3.2. Pseudowire Flow Label > >> > >> 2.3.3. MPLS Entropy Label > >> > >> (see Section 2.3) > >> > >> This is an editorial nit, but for readability -- it confused me to see > >> a pointer to S2.3 within S2.3.x (as if there is an (apparent) reading > >> loop). > > > > I'll change the reference to "2.3.5. Fields in Multipath" which > > is new. BTW- that section starts by saying "Inspecting the IP payload > > provides the most entropy in provider networks. The practice of > > looking past the bottom of stack label for an IP payload is well > > accepted and documented in [RFC4928] and in other RFCs." just to be > > clear that the reason for inclusion in an MPLS document is that you > > need to look under the MPLS label stack for this purpose. > > > > Thanks. > > >> 3. Questions for Suppliers > >> > >> Q#10 Are reserved labels included in the label stack hash? They > >> MUST NOT be included. > >> > >> Could a citation be included for this MUST NOT? Or is this document > >> adding this requirement? I think there was a mention in RFC 6790, but > >> RFC4928/BCP128 says: > > > > Eliminated the double negative. It now says "Are reserved labels > > excluded from the label stack hash? They MUST be excluded [RFC6790]." > > > > RFC 6790 is cited elsewhere but is now cited here as well. > > > >> Any reserved label, no > >> matter where it is located in the stack, may be included in the > >> computation for load balancing. Modification of the label stack > >> between packets of a single flow could result in re-ordering that > >> flow. That is, were an explicit null or a router-alert label to be > >> > >> added to a packet, that packet could take a different path through > >> the network. > >> > >> 4. Forwarding Compliance and Performance Testing > >> > >> I wonder if this complete section should be progressed independently > >> in a separate document. > > > > If your "wondering" becomes the WG concensus, then I'm OK with that. > > > > My preference is to keep this brief summary of necessary testing with > > the requirements and expand on details of specific tests in BMWG. > > > >> Again, this is an useful well-written document, thanks! > >> > >> -- Carlos. > > > > Thanks for the comments, here in MPLS as well as in BMWG. > > > > The following changes have been edited into (my local copy) of the > > draft and are likely to make the next iteration (unless Kireeti > > objects). > > > > > 1. Expanded a bit on reserved labels. Mention TP OAM (to be > > expanded on in later sections). Mention PTP and NTP. > > > > 2. Defer inclusion of "special purpose labels" for now. > > > > 3. The paragraph introducing multipath had already been expanded. > > > > 4. Andy already sent two rounds of extensive comments on PW. I > > have yet to edit in the second round. > > > > 5. Clarified PW without flow label to mean PW carried over MPLS > > without flow label (though I don't really agree that we need > > that clarification). > > > > 6. Fixed reference to 2.3 in 2.3.3. It now refers to the new > > section "2.3.5. Fields in Multipath". > > > > 7. Changed "MUST NOT be included" to "MUST exclude" in two places > > where reserved labels in hash are discussed. Referenced RFC6790 > > in both places. > > > > I may send out a 01 without Andy's latest rounds of comments, then > > following shortly after with an 02. This would be a better basis for > > discussion. I'll see what Kireeti thinks of sending this out vs > > waiting for all of the changes to get edited in and then sending out > > an 01. We still have off list discussions on other topics such as TP > > OAM with changes pending. > > Thanks much. > > -- Carlos. Thanks for clarifying your prior comment on IP PW. I'll look for a place in the document to put the text on IP PW if this addresses your comment. Curtis > > Curtis > > > > > >> On Oct 8, 2012, at 8:30 PM, Kireeti Kompella > wrote: > >> > >> Hi Folks, > >> > >> I'd spoken on the issue of deep label stacks at the last IETF, and > >> there was interest from chip suppliers, vendors and service providers. > >> Curtis just submitted the draft; it goes beyond just deep label > >> stacks. There are suggestions in the draft on aspects of implementing > >> MPLS forwarding, as well as questions to ask regarding an > >> implementation, and things to test. > >> > >> Please read and comment to the list. > >> > >> If you (that includes MPLS WG chairs and ADs) could also formulate > >> your thoughts on what type of doc (Info, BCP, PS) this should be, that > >> would be very helpful in moving this discussion forward. > >> > >> Thanks, > >> Kireeti. From cpignata@cisco.com Thu Dec 20 12:49:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2426821F8A7D for ; Thu, 20 Dec 2012 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3EWK4151tqL for ; Thu, 20 Dec 2012 12:49:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 77AAB21F8973 for ; Thu, 20 Dec 2012 12:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2467; q=dns/txt; s=iport; t=1356036554; x=1357246154; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JvlKj4HmPNashyPMXZ4YO3lE9ifarsOxdhp05qtQtFI=; b=epb4AdG3m8LQxOus50S2lAcExb6iCuIuRW5UMStxGk2yZl/IE2URiAcA F8dcV6mW5HFdzCRV2CUub7G0UsC+vUKzzKywP9Gd/JnJTlfvuYy6p2RD7 RNdOZSrRiqMdRLdC7PTiGrWHrIWZE57PgzI2wVhnAhV+H06ENcBatF/IF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABx501CtJXHB/2dsb2JhbABFvXAWc4IgAQQnEy0QAhIBCCIUQiUCBA4FCIgLDLlmkDlhA5cnjyyCdIIi X-IronPort-AV: E=Sophos;i="4.84,326,1355097600"; d="scan'208";a="152244674" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2012 20:49:11 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBKKnAdw012196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 20:49:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 14:49:10 -0600 From: "Carlos Pignataro (cpignata)" To: "curtis@occnc.com" Thread-Topic: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt Thread-Index: AQHN3vNS1pBvDgYtvUO7JXu4csIevpgiOceA Date: Thu, 20 Dec 2012 20:49:10 +0000 Message-ID: <95067C434CE250468B77282634C96ED322812D0E@xmb-aln-x02.cisco.com> In-Reply-To: <201212202048.qBKKmCIl020658@gateway1.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.150.52.103] Content-Type: text/plain; charset="us-ascii" Content-ID: <338ADF25CE4C2F4DADBB49BA2B3D029A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:49:15 -0000 It does -- thanks for addressing. -- Carlos. On 12/20/12 3:48 PM, "Curtis Villamizar" wrote: > >Carlos, > >Revisiting one nit of yours. Trimmed the rest. > >In message=20 ><95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> >"Carlos Pignataro (cpignata)" writes: >> >> 2.3.2. Pseudowire Flow Label >> >>=20 >> >> ... >> >> Any pseudowire which does not carry a flow label is in effect a >> >> single microflow (in [RFC2475] terms). >> >>=20 >> >> This is a bit of a corner-case nit, but for completeness: this is not >> >> the case for IP L2 Transport PW without its optional CW (without flow >> >> label) http://tools.ietf.org/html/rfc4447#section-4.1. >> >=20 >> > People use L2TP? :-) >> =20 >> Very much so -- but that is orthogonal to my comment, which is about >> IP L2 and not L2TP. >> =20 >> > OK - PW with MPLS PSN, but then again this is an MPLS document. >> >=20 >> > I don't see what point you are trying to make. >> =20 >> Sorry if I managed to confuse you. Let me try again -- it is a nit. >> =20 >> RFC 4447 (PW setup using LDP) defines in Section 4.1 (pointer included >> above) the "IP Layer 2 Transport" Pseudowire (PW Type 0x000B). This is >> a PW FEC, that when used without CW looks in the DP as an RFC 3032 >> MPLS encapsulated IP datagram. It's used in arp-med, ipls, etc. >> =20 >> I was just pointing out that for that particular PW, the multipath is >> as if IP payload directly on MPLS (since it is in the DP). I do not >> intend to convolute the description and remove generalization to >> somehow cover this, but I thought I'd bring it up in case. > >OK I finally see the nit that started out this part of the thread. > >Here is the new text for the offending paragraph (xml source). > > > > Any pseudowire carried over MPLS which makes use of the > pseudowire control word and does not carry a > flow label is in effect a single microflow (in target=3D"RFC2475" /> terms). > > >I think this covers the original nit regarding the corner case of IP >PW. If an IP PW or any other PW has a CW and no flow label it is >effectively treated as one microflow in RFC2475 terms. [If it is not >an IP PW and has no control word it is going to be a mess of reordered >PW traffic, even with flow label.] > >Curtis > From curtis@occnc.com Thu Dec 20 12:50:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443A821F8A58 for ; Thu, 20 Dec 2012 12:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRtLj+Fd03f2 for ; Thu, 20 Dec 2012 12:50:47 -0800 (PST) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61021F8973 for ; Thu, 20 Dec 2012 12:50:47 -0800 (PST) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id qBKKmCIl020658; Thu, 20 Dec 2012 15:48:12 -0500 (EST) (envelope-from curtis@occnc.com) Message-Id: <201212202048.qBKKmCIl020658@gateway1.orleans.occnc.com> To: "Carlos Pignataro (cpignata)" From: Curtis Villamizar In-reply-to: Your message of "Thu, 20 Dec 2012 15:49:01 GMT." <95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> Date: Thu, 20 Dec 2012 15:48:11 -0500 Cc: "mpls@ietf.org" Subject: Re: [mpls] New Version Notification for draft-villamizar-mpls-forwarding-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 20:50:48 -0000 Carlos, Revisiting one nit of yours. Trimmed the rest. In message <95067C434CE250468B77282634C96ED3228102A4@xmb-aln-x02.cisco.com> "Carlos Pignataro (cpignata)" writes: > >> 2.3.2. Pseudowire Flow Label > >> > >> ... > >> Any pseudowire which does not carry a flow label is in effect a > >> single microflow (in [RFC2475] terms). > >> > >> This is a bit of a corner-case nit, but for completeness: this is not > >> the case for IP L2 Transport PW without its optional CW (without flow > >> label) http://tools.ietf.org/html/rfc4447#section-4.1. > > > > People use L2TP? :-) > > Very much so -- but that is orthogonal to my comment, which is about > IP L2 and not L2TP. > > > OK - PW with MPLS PSN, but then again this is an MPLS document. > > > > I don't see what point you are trying to make. > > Sorry if I managed to confuse you. Let me try again -- it is a nit. > > RFC 4447 (PW setup using LDP) defines in Section 4.1 (pointer included > above) the "IP Layer 2 Transport" Pseudowire (PW Type 0x000B). This is > a PW FEC, that when used without CW looks in the DP as an RFC 3032 > MPLS encapsulated IP datagram. It's used in arp-med, ipls, etc. > > I was just pointing out that for that particular PW, the multipath is > as if IP payload directly on MPLS (since it is in the DP). I do not > intend to convolute the description and remove generalization to > somehow cover this, but I thought I'd bring it up in case. OK I finally see the nit that started out this part of the thread. Here is the new text for the offending paragraph (xml source). Any pseudowire carried over MPLS which makes use of the pseudowire control word and does not carry a flow label is in effect a single microflow (in terms). I think this covers the original nit regarding the corner case of IP PW. If an IP PW or any other PW has a CW and no flow label it is effectively treated as one microflow in RFC2475 terms. [If it is not an IP PW and has no control word it is going to be a mess of reordered PW traffic, even with flow label.] Curtis From xuxiaohu@huawei.com Thu Dec 20 17:45:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBE21E8034 for ; Thu, 20 Dec 2012 17:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlAy5rNCFyWa for ; Thu, 20 Dec 2012 17:45:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD321E803F for ; Thu, 20 Dec 2012 17:45:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR74456; Fri, 21 Dec 2012 01:45:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:44:58 +0000 Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:45:04 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 09:44:50 +0800 From: Xuxiaohu To: Shahram Davari , Lucy yong Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sszh5eWXqDbZUC4MEZ17BejhpghW8uAgAEcR/A= Date: Fri, 21 Dec 2012 01:44:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A328@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com> In-Reply-To: <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.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.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 01:45:31 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFNoYWhyYW0gRGF2YXJpDQo+ ILeiy83KsbzkOiAyMDEyxOoxMtTCMjHI1SAwOjM0DQo+IMrVvP7IyzogTHVjeSB5b25nDQo+ILOt y806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsNCj4gbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW21wbHNdIE1QTFMgY2xp ZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KPiANCj4gTmV0d29yayB2 aXJ0dWFsaXphdGlvbiBvdmVybGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBjb25zZW50ZWQgIGlu IE5WTzMNCj4gV0cuDQoNCklmIHNvLCBjYW4geW91IHRlbGwgdXMgd2hhdCBMMlZQTiwgTDNWUE4g YW5kIGV2ZW4gUFdFMyBXR3MgaGF2ZSBkb25lIGJlZm9yZT8NCiANClhpYW9odQ0KDQo+IFJlZ2Fy ZHMsDQo+IFNoYWhyYW0NCj4gDQo+IA0KPiBPbiBEZWMgMjAsIDIwMTIsIGF0IDc6MzkgQU0sICJM dWN5IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEhpIFNoYW5l LA0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBz dWxhdGlvbiB0byBhbiBleGlzdGluZw0KPiBuZXR3b3JrLg0KPiA+DQo+ID4gSG93ZXZlciwgTVBM Uy1pbi1VRFAgZG9lcyBub3QgYWltIG9uIGNoYW5naW5nIGV4aXN0aW5nIFNQIElQL01QTFMNCj4g bmV0d29yayBhdCBhbGwuDQo+ID4gTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50 IGxheWVyIHRvIGJlIGRlY291cGxlZCBmcm9tIE1QTFMgc2VydmVyDQo+IGxheWVyIGFuZCB1c2Ug TVBMUyBjbGllbnQgbGF5ZXIgYXMgb3ZlcmxheSBuZXR3b3JrIGFuZCBhbiBJR1AgYXMgYSB1bmRl cmx5aW5nDQo+IG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBmb3Ig REMuIFlvdSBtYXkgYXJndWUgd2h5IG5vdCB1c2UNCj4gdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBM UyBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcgbmV0d29yay4gV2UgaGF2ZQ0KPiBwb2ludGVk IG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJvdXRlcnMgaW4gREMgYmFyZWx5IHN1cHBv cnQgR1JFIGJhc2VkDQo+IGxvYWQgYmFsYW5jaW5nIGFuZCBNUExTLWluLUdSRSBhcmUgYmFyZWx5 IHVzZWQgaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mDQo+IHJvdXRlcnMgaW4gREMgcGVyZm9y bSB1cGQgcG9ydCBiYXNlZCBsb2FkIGJhbGFuY2luZyBub3cuDQo+ID4NCj4gPiBGcm9tIHRoZSBh cmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUsIHRoZSBVRFAgZW5jYXBzdWxhdGlvbiBoYXMgYWR2YW50 YWdlDQo+IG92ZXIgR1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5jYXBzdWxhdGlvbiwg dGhlIGZyYW1lIGhlYWRlcg0KPiBkZWNvdXBsZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcg bmV0d29yayBjbGVhcmx5LCBpLmUuIG91dGVyIGhlYWRlciBhbmQNCj4gb3ZlcmxheSBoZWFkZXIu IFVEUCBiZWxvbmdzIHRvIG91dGVyIGhlYWRlciwgd2hpY2ggdW5kZXJseWluZyBuZXR3b3JrIHVz ZXMNCj4gb25seS4gSG93ZXZlciwgR1JFIGhlYWRlciBoYXMgdGhlIGZpZWxkcyBmb3IgdGhlIG92 ZXJsYXkgbmV0d29yayBhbmQgdXNlcyB0aGUNCj4ga2V5IGZpZWxkIGZvciBmbG93IGVudHJvcHku IEZvciBsb2FkIGJhbGFuY2luZywgaXQgcmVxdWlyZXMgdGhlIHVuZGVybHlpbmcgbmV0d29yaw0K PiB1c2VzIEdSRSBoZWFkZXIgdG9vLiBJbiBzaG9ydCwgR1JFIHRpZXMgdGhlIG92ZXJsYXkgYW5k IHVuZGVybHlpbmcgbmV0d29ya3MNCj4gdG9nZXRoZXIuIFNpbmNlIGl0IGhhcyBub3QgdXNlZCBh IGxvdCwgcGVvcGxlIGFyZSBub3QgYXdhcmUgb2YgdGhlIGRpc2FkdmFudGFnZQ0KPiBvZiBzdWNo IGNvdXBsaW5nLg0KPiA+DQo+ID4gQXMgdGhlIGluZHVzdHJ5IG1vdmVzIHRvd2FyZCBuZXR3b3Jr IHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgYW5kIGRlY291cGxlcw0KPiBvdmVybGF5IG5ldHdvcmtz IGZyb20gdGhlIHVuZGVybHlpbmcgbmV0d29yay4gQSBjbGVhciBzZXBhcmF0aW9uIG9mIG92ZXJs YXkNCj4gaGVhZGVyIGFuZCB1bmRlcmx5aW5nIGhlYWRlciBpcyBhICJNVVNUIiBpbiBteSBvcGlu aW9uLiBJZiB3ZSBjb3VudCBHUkUgYXMNCj4gdGhlIG92ZXJsYXkgaGVhZGVyLCB0aGVuIGZvciBJ UHY0IHVuZGVybHlpbmcgbmV0d29yaywgdGhlcmUgaXMgbm8gZmllbGQgZm9yIHRoZQ0KPiBmbG93 IGVudHJvcHkuIFRoaXMgaXMgdGhlIHJlYXNvbiB3ZSBwcm9wb3NlIHRoZSBVRFAgZW5jYXBzdWxh dGlvbjogZm9yIGFuIElHUA0KPiBiYXNlZCB1bmRlcmx5aW5nIG5ldHdvcmsuIEluIGZhY3QsIGl0 IGNhbiBzdXBwb3J0IGFueSBvdmVybGF5IG5ldHdvcmsgYmVzaWRlDQo+IE1QTFMgY2xpZW50IGxh eWVyIChlLmcuIFZYTEFOLCBMMlRQLWluLVVEUCwgZXRjKS4NCj4gPg0KPiA+IFlvdSBwb2ludCBv dXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVEUCBpbnN0ZWFkLiBZZXMsIE1QTFMtaW4tTDJUUC1p bi1VRFANCj4gc2NoZW1hIGFsc28gcHJvdmlkZXMgYSBvdmVybGF5IChMMlRQKSBhbmQgdW5kZXJs eWluZyAoSVApIG5ldHdvcmsgZGVjb3VwbGluZy4NCj4gTDJUUCBwcm90b2NvbCAocmZjMzkzMSkg cHJvdmlkZXMgZ29vZCBzZWN1cml0eSBtZWNoYW5pc20gYW5kIGhhcyB0aGUNCj4gZW1iZWRkZWQg Y29udHJvbCBmdW5jdGlvbiB0b28uIFRoZXJlZm9yZSwgc29tZW9uZSBjYW4gdXNlIGl0IGZvciBN UExTIGNsaWVudA0KPiBsYXllciBvdmVyIEludGVybmV0LiBUbyBoYXZlIE1QTFMgY2xpZW50IGxh eWVyIG92ZXIgYW4gSUdQIHVuZGVybGluZyBuZXR3b3JrLA0KPiBJTU86IE1QTFMtaW4tTDJUUC1p bi1VRFAgaXMgYSBvdmVya2lsbCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZCBhDQo+IHNj aGVtYSB0byBzdXBwb3J0IElHUCB1bmRlcmx5aW5nIHRyYW5zcG9ydCB3aXRob3V0IHRvdWNoaW5n IGEgb3ZlcmxheSBoZWFkZXIuDQo+IFVEUCBlbmNhcHN1bGF0aW9uIGlzIHRoZSBiZXN0IGNob2lj ZSB0byBhY2NvbXBsaXNoIHRoYXQgYW5kIG1pbmltaXplIHRoZQ0KPiBjaGFuZ2VzIG9uIGV4aXN0 aW5nIHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVycywgbm8gY2hhbmdlIG9uIHRy YW5zaXQNCj4gcm91dGVycy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gTHVjeQ0KPiA+DQo+ID4N Cj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBYdXhpYW9o dSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAyMCwgMjAxMiA0OjE0IEFNDQo+ID4+IFRvOiBTaGFuZSBBbWFudGUNCj4gPj4gQ2M6IFJv Z2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmll dGYub3JnOw0KPiA+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K PiA+PiBTdWJqZWN0OiBEaXNjdXNzaW9uIG9uIGhvdyB0byB0cmFuc3BvcnQgTVBMUyBvdmVyIFVE UCB0dW5uZWxzDQo+ID4+DQo+ID4+IEhpIFNoYW5lLA0KPiA+Pg0KPiA+PiBUaGFua3MgZm9yIHlv dXIgZnVydGhlciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuDQo+ ID4+DQo+ID4+IE5vdGU6IEkgY2hhbmdlZCB0aGUgc3ViamVjdCBsaW5lIGFjY29yZGluZyB0byBM b2EncyBzdWdnZXN0aW9uLg0KPiA+Pg0KPiA+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+PiC3 orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldF0NCj4gPj4+ ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAyMjozOA0KPiA+Pj4gytW8/sjLOiBYdXhpYW9odQ0K PiA+Pj4gs63LzTogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1p bi0NCj4gPj4gdWRwQHRvb2xzLmlldGYub3JnOw0KPiA+Pj4gbXBsc0BpZXRmLm9yZzsgbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUg aWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+IG1wbHMtaW4tdWRwIGFu DQo+ID4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+DQo+ID4+PiBYaWFvaHUs DQo+ID4+Pg0KPiA+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCAxMTo1MCBQTSwgWHV4aWFvaHUgPHh1 eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+ Pj4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0K PiA+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMTE6NTgNCj4gPj4+Pj4gytW8/sjLOiBS b2dlcnMsIEpvc2gNCj4gPj4+Pj4gs63LzTogU2hhaHJhbSBEYXZhcmk7IFh1eGlhb2h1OyBkcmFm dC14dS1tcGxzLWluLQ0KPiA+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc7DQo+ID4+Pj4+IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4+Pj4+INb3zOI6IFJlOiBbbXBs c10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+ IG1wbHMtaW4tdWRwDQo+ID4+PiBhbg0KPiA+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFN LCAiUm9nZXJzLCBKb3NoIg0KPiA+PiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+DQo+ID4+Pj4+ IHdyb3RlOg0KPiA+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90 IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+IHNvbHV0aW9uDQo+ID4+Pj4+PiBhZGRyZXNzZXMg aW4gcHJhY3RpY2UgYW55IGxvbmdlci4NCj4gPj4+Pj4NCj4gPj4+Pj4gKzEuICBQbGVhc2UgZG8g bm90IGRlZmluZSB5ZXQgYW5vdGhlciBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbi4NCj4gPj4g VGhlDQo+ID4+PiBJRVRGDQo+ID4+Pj4+IGFscmVhZHkgc3RhbmRhcmRpemVkIE1QTFMgb3ZlciBH UkUuICBUaGUgSUVURiBoYXMgYWxzbw0KPiA+PiBzdGFuZGFyZGl6ZWQNCj4gPj4+IE1QTFMNCj4g Pj4+Pj4gb3ZlciBMMlRQdjMvVURQL0lQLCB3aGljaCBoYWQgc2VlbiBzb21lIGRlcGxveW1lbnQg aW4gYXQgbGVhc3Qgb25lLA0KPiA+PiB2ZXJ5DQo+ID4+Pj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdv cmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZg0KPiA+PiBMM1ZQTiBv dmVyDQo+ID4+PiBhbg0KPiA+Pj4+PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4+Pj4NCj4gPj4+PiBI aSBTaGFuZSwNCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rIHlvdSBmb3IgdGVsbGluZyB1cyB0aGVyZSBh cmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3Zlcg0KPiA+PiBJUCBpbiBhdA0KPiA+Pj4g bGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJl IHZlcnkNCj4gPj4gdmFsdWFibGUgdG8gdGhvc2UNCj4gPj4+IHBlb3BsZSB3aG8gaGFkIGJlbGll dmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1QTFMgb3ZlciBJUCBpbg0KPiA+PiB0b2Rh eSdzIFNQDQo+ID4+PiBuZXR3b3Jrcy4NCj4gPj4+Pg0KPiA+Pj4+PiBTZWU6IFJGQydzIDQ0NTQs IDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4gW05PVEU6IHRo ZSBkYXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJhY2sgaW4gdGhlIDIwMDYNCj4g Pj4+IHRpbWVmcmFtZSFdDQo+ID4+Pj4+ICAgIFJGQyA0NjY1IGZvciByZXF1aXJlbWVudHMgcmVs YXRlZCB0byBWUExTIHRoYXQgc2F5IHRoYXQgVlBMUw0KPiA+PiBtYXkgYmUNCj4gPj4+Pj4gY2Fy cmllZCBvdmVyIEwyVFB2Mw0KPiA+Pj4+PiAgICBBbmQsIGhlcmUncyBldmlkZW5jZSBzaG93aW5n IHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXMNCj4gPj4+IGltcGxlbWVudGVkDQo+ID4+Pj4+ IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+ID4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2Rv Y3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRtbA0KPiA+Pj4+DQo+ID4+Pj4g VGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlv bmVkIGluDQo+ID4+IHRoaXMgZHJhZnQNCj4gPj4+IEFORCBvdGhlciBkcmFmdHMsIHRoZSBtZWNo YW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9uIG9uIHRoZQ0KPiA+PiBTZXNzaW9u DQo+ID4+PiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGlu IHRoZSBHUkUgaGVhZGVyIGFzDQo+ID4+IGRlZmluZWQgaW4NCj4gPj4+IFtSRkMgNTY0MF0gaXMg bm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNvIGZhci4NCj4g Pj4+DQo+ID4+PiBGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nlc3MsIGluIHRoZSByZWxhdGl2ZWx5IHJl Y2VudCBwYXN0LCBpbg0KPiA+PiByZXF1ZXN0aW5nIGEgY29yZQ0KPiA+Pj4gcm91dGVyIHZlbmRv ciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4+ IGNhbGN1bGF0aW9ucyBpbg0KPiA+Pj4gX2V4aXN0aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBs b3llZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQgbXkNCj4gPj4gbmV0d29yay4NCj4gPj4+IEZ1 cnRoZXIsIEkgc3VzcGVjdCB0aGF0IG1vc3QgbGFyZ2UgbmV0d29yayBvcGVyYXRvcnMgYXJlIHNh dnZ5IGZvbGtzDQo+ID4+IGFuZA0KPiA+Pj4gdW5kZXJzdGFuZCB0aGUgaW50ZXJuYWwgYXJjaGl0 ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPiA+PiByZXN1bHQsIHRob3Nl DQo+ID4+PiBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxs eSBwb3NzaWJsZSBpbiB0aGlzDQo+ID4+IHJlZ2FyZC4NCj4gPj4+IFRodXMsIGl0IG1heSBiZSBh IHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhlaXINCj4gPj4g SFcNCj4gPj4+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlhdGUgY2hhbmdlcyBpbiB0aGVp ciBlcXVpcG1lbnQgdG8gYWNoaWV2ZQ0KPiA+PiB0aGVpcg0KPiA+Pj4gYnVzaW5lc3MgZ29hbHMu ICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJlIG5lY2Vzc2FyeSAuLi4gc2VlDQo+ ID4+IGJlbG93Lg0KPiA+Pg0KPiA+PiBDb3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgZXhwbGFpbiBo b3cgdG8gbWFrZSB0aGUgYWJvdmUgY2hhbmdlIGluDQo+ID4+IEVYSVNUSU5HIGhhcmR3YXJlIG9m IGFscmVhZHkgZGVwbG95ZWQgY29yZSByb3V0ZXJzPw0KPiA+Pg0KPiA+Pj4+IEluIGNvbnRyYXN0 LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mDQo+ID4+ IGJhbGFuY2luZyBJUA0KPiA+Pj4gdHJhZmZpYyBmbG93cyBiYXNlZCBvbiB0aGUgaGFzaCBvZiB0 aGUgZml2ZS10dXBsZSBvZiBVRFAgcGFja2V0cy4gQnkNCj4gPj4gdXNpbmcgdGhlDQo+ID4+PiBN UExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxh bmNpbmcNCj4gPj4gY2FwYWJpbGl0eSBvZg0KPiA+Pj4gbW9zdCBleGlzdGluZyBjb3JlIHJvdXRl cnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkNCj4gPj4gY2hhbmdlIHRv DQo+ID4+PiB0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQu DQo+ID4+Pg0KPiA+Pj4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5IG5vdCBlbmNhcHN1 bGF0ZSB0aGUgdHJhZmZpYyBpbg0KPiA+PiBNUExTL0wyVFB2Mywgd2hpY2gNCj4gPj4+IHVzZXMg VURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+ID4+DQo+ID4+IElmIEkgdW5kZXJzdGFuZCBp dCBjb3JyZWN0bHksIHlvdSBwcmVmZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLVVEUA0KPiA+ PiBpbnN0ZWFkIG9mIE1QTFMtaW4tVURQLCByaWdodD8NCj4gPj4NCj4gPj4+IElNSE8sIGEgYmV0 dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0K PiA+PiBSRkMgMzkzMSwNCj4gPj4+IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBjb25uZWN0aW9uIHVz ZWQgZm9yIGRhdGEgcGFja2V0cyAobm90IGNvbnRyb2wNCj4gPj4gcGFja2V0cykNCj4gPj4+IHRv IHVzZSBhIHZhcnlpbmcgc2V0IG9mIHNvdXJjZSBwb3J0cyAob3IsIHNvdXJjZSBJUCBhZGRyZXNz ZXMpLCBiYXNlZA0KPiA+PiBvbiBhIGhhc2gNCj4gPj4+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZl IGJldHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudA0KPiA+PiBpbiBh bg0KPiA+Pj4gSVAtb25seSBjb3JlLiAgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVudGF0aW9ucyB3 b3VsZCBiZSBiZXR0ZXIgb2ZmDQo+ID4+IGp1c3QgdXNpbmcNCj4gPj4+IHRoZSAiU2Vzc2lvbiBJ RCIgKGFuZCAiQ29va2llIikgZmllbGRzIGFzIHRoZSBkZW11bHRpcGxleG9yIHRvDQo+ID4+IGFz c29jaWF0ZQ0KPiA+Pj4gaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwyVFAg Q29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwNCj4gPj4gaXQncyBub3QNCj4gPj4+IGNsZWFyIHRv IG1lIHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG1heSAvYWxyZWFkeS8gZG8gdGhpcywN Cj4gPj4gbWFraW5nIGFueQ0KPiA+Pj4gImNoZWNrIiBvbiB0aGUgaW5jb21pbmcgc291cmNlIHBv cnQgdW5uZWNlc3NhcnkgZm9yIEwyVFAgZW5kLXN5c3RlbQ0KPiA+Pj4gaW1wbGVtZW50YXRpb25z Lg0KPiA+Pj4NCj4gPj4+IFRoZSBiZWF1dHkgb2YgdGhlIGFib3ZlIGFwcHJvYWNoIGlzOg0KPiA+ Pj4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBhIGNoYW5n ZSB0aGF0IGlzDQo+ID4+IGxpbWl0ZWQgdG8gdGhlDQo+ID4+PiAiY29udHJvbCBjaGFubmVsIiAo c29mdHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbQ0KPiA+PiBpbXBsZW1lbnRhdGlv bnMuDQo+ID4+PiBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRo IGV4aXN0aW5nIEwyVFB2Mw0KPiA+Pj4gaW1wbGVtZW50YXRpb25zLiAgKEwyVFB2MyBpbXBsZW1l bnRvcnMgd291bGQgbmVlZCB0byBjb21tZW50IG9uDQo+IHRoYXQpLg0KPiA+Pg0KPiA+PiBJTUhP LCBubyBtYXR0ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCAgdGhlIGhh cmR3YXJlIG9mDQo+ID4+IFBFIHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUuZy4sIGlu Z3Jlc3MgUEUgcm91dGVycyBuZWVkIHRvIGZpbGwNCj4gPj4gaW4gYW4gZW50cm9weSB2YWx1ZSBp biB0aGUgc291cmNlIHBvcnQgZmllbGQgb2YgVURQIGhlYWRlcnMuDQo+ID4+DQo+ID4+PiAyKSBU aGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJT ZXNzaW9uDQo+ID4+IElEIiBhbmQNCj4gPj4+ICJDb29raWUiIGZpZWxkcyB0byBlbnN1cmUgdGhl IHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yDQo+ID4+IHRoZQ0KPiA+Pj4g aWRlbnRpZmllZCBzZXNzaW9uLiAgUXVvdGluZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMx Og0KPiA+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4gICBMMlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBh cmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAzMi1iaXQNCj4gPj4gU2Vzc2lvbg0KPiA+Pj4gICBJ RCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENv b2tpZQ0KPiA+Pj4gICAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xKSwgcHJvdmlkZXMgYW4gYWRk aXRpb25hbCBjaGVjayB0byBlbnN1cmUNCj4gPj4+ICAgdGhhdCBhbiBhcnJpdmluZyBwYWNrZXQg aXMgaW50ZW5kZWQgZm9yIHRoZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+ID4+PiAgIFRodXMsIHVz ZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhDQo+ID4+ IGd1YXJhbnRlZQ0KPiA+Pj4gICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVyZm9y bWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZQ0KPiA+Pj4gICBTZXNzaW9uIElEIGl0c2VsZiB3YXMg bm90IGNvcnJ1cHRlZCBpbiB0cmFuc2l0Lg0KPiA+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4gLi4uIGlu IHJlZ2FyZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWEg Zm9sa3MNCj4gPj4gaGF2ZSwgaW4gdGhlDQo+ID4+PiBwYXN0LCBoYWQgL3N1YnN0YW50aWFsLyBj b25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9uIG9mIE1QTFMgb3ZlciBJUA0KPiA+PiB0cmFuc3Bv cnQuDQo+ID4+PiBJbiBmYWN0LCB0aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQgaW4gU2VjdGlvbiA3 LjYsICJTZWN1cml0eSIsIG9mIFJGQw0KPiA+PiA0NjY1Lg0KPiA+Pj4gKFRoZXJlJ3MgbGlrZWx5 IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdXNlIE1QTFMgZm9yDQo+ID4+ IHRyYW5zcG9ydCkuDQo+ID4+PiBXaGlsZSBJJ20gbm90IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVh IGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0KPiA+PiBkYWlseSB0cmFmZmljIG9uDQo+ID4+ PiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29u Y2VybiB3aWxsDQo+ID4+IGFyaXNlIGlmL3doZW4gdGhpcw0KPiA+Pj4gZHJhZnQgZ29lcyB0byB0 aGUgSUVTRyAuLi4NCj4gPj4NCj4gPj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhl IHJlYXNvbiBmb3IgeW91ciBwcmVmZXJlbmNlIG9mIE1QTFMtDQo+ID4+IGluLUwyVFB2My1pbi1V RFAgaXMgdGhhdCBpdCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdCBpcw0K PiA+PiBzbyBjb25jZXJuZWQsIGNhbiB5b3UgZXhwbGFpbiB3aHkgTVBMUy1pbi1HUkUgaXMgZmFy IG1vcmUgcG9wdWxhciB0aGFuDQo+ID4+IE1QTFMtaW4tTDJUUCBpbiBwcmFjdGljZT8NCj4gPj4N Cj4gPj4gQmVzdCByZWdhcmRzLA0KPiA+PiBYaWFvaHUNCj4gPj4NCj4gPj4+IDMpIEZpbmFsbHks IHRoaXMgYXBwcm9hY2ggb25seSBhZmZlY3RzIHRoZSBlbmQtc3lzdGVtcyB0aGF0IGltcGxlbWVu dA0KPiA+PiBMMlRQLCBmb3INCj4gPj4+IHR1bm5lbGluZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBu b3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG8NCj4gPj4gc3VwcG9ydA0KPiA+Pj4gTVBM Uy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLg0KPiA+Pj4NCj4gPj4+ IC1zaGFuZQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+ Pj4gWGlhb2h1DQo+ID4+Pj4NCj4gPj4+Pj4gSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9y IE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0IHdvdWxkDQo+ID4+IGhhdmUNCj4gPj4+IGJl ZW4NCj4gPj4+Pj4gbW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMs IHdpdGggZWl0aGVyIE1QTFMNCj4gPj4gb3Zlcg0KPiA+Pj4gR1JFIG9yDQo+ID4+Pj4+IE1QTFMg b3ZlciBMMlRQdjMuICAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSSB3 b3VsZA0KPiA+PiBub3RlDQo+ID4+PiB0aGF0DQo+ID4+Pj4+IHRoZSBtb3N0IGxpa2VseSByZWFz b25zIHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmUgc2V2ZXJhbCwNCj4gPj4gcHJh Y3RpY2FsDQo+ID4+Pj4+IG9wZXJhdGlvbmFsIGJlbmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcg d2l0aCBuYXRpdmUgTVBMUw0KPiA+Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4g dGhlIGRhdGEgcGxhbmUsIG5hbWVseToNCj4gPj4+Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4g Pj4+Pj4gLSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4gPj4+Pj4gLi4uIHRvIG5hbWUsIGJ1 dCBhIGZldy4gIFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxpbmcNCj4gPj4+ IGFyZ3VtZW50cw0KPiA+Pj4+PiB0byAndXBncmFkZScgbmV0d29yayBIVyB0byBzdXBwb3J0IE1Q TFMgZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcuDQo+ID4+Pj4+DQo+ID4+Pj4+IC1zaGFuZQ0KPiA+ Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLUpvc2gNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+ Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNv bS5jb20+DQo+ID4+PiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gRm9yIHNlcnZpY2UgcHJv dmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0aGVyZSBpcw0KPiA+PiBu byBuZWVkDQo+ID4+Pj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFJl Z2FyZHMsDQo+ID4+Pj4+Pj4gU2hhaHJhbQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+ PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdl aS5jb20+DQo+ID4+PiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJvdmlk ZSBhIE1QTFMtb3Zlci1JUA0KPiA+PiBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+IG1ldGhvZCB3 aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRvDQo+ID4+ IHRob3NlDQo+ID4+Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNw b3J0aW5nIE1QTFMgYXBwbGljYXRpb24NCj4gPj4gdHJhZmZpYw0KPiA+Pj4+Pj4+PiBhY3Jvc3Mg SVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQLCBOVkdSRSBhbmQN Cj4gPj4+IFZYTEFODQo+ID4+Pj4+Pj4+IGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBh bmQgdXNlIGNhc2VzLiBJZiB5b3UgYWJzb2x1dGVseQ0KPiA+PiBiZWxpZXZlDQo+ID4+Pj4+Pj4+ IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZp Yw0KPiA+PiBhY3Jvc3MgSVANCj4gPj4+Pj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9z ZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyDQo+ID4+IElQDQo+ID4+Pj4+Pj4+ IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMs IHBsZWFzZQ0KPiA+PiBzYXkNCj4gPj4+IHNvLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBCeSB0 aGUgd2F5LCBpdCBzZWVtcyB0aGlzDQo+ID4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21h aWwtDQo+ID4+IGFyY2hpdmUvd2ViL252bzMvY3VycmVudC9tc2cwMTg2NC5odG1sKSBpcw0KPiA+ Pj4+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRo ZSBmb2xsb3dpbmcNCj4gPj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4gKGkuZS4sIHdoZXRoZXIgb3Ig bm90IE1QTFMtYmFzZWQgVlBOIGlzIGFwcGxpY2FibGUgdG8gZGF0YQ0KPiA+PiBjZW50ZXJzKS4g SQ0KPiA+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhhdCB0aW1l LiBTYWRseSwNCj4gPj4gc3VycHJpc2luZ2x5IHNpbGVudA0KPiA+Pj4+Pj4+PiB0aWxsIG5vdy4N Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gU2lnaCwgSSBkaWRuJ3QgaW50ZW5kIHRvIHNheSB0aGUg YWJvdmUgb3RoZXJ3aXNlLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+Pj4+Pj4gt6K8/sjLOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo+ILT6 DQo+ID4+ILHtDQo+ID4+Pj4+IFMuDQo+ID4+Pj4+Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+ILei y83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPiA+Pj4+Pj4+Pj4gytW8/sjLOiBMb2EgQW5k ZXJzc29uDQo+ID4+Pj4+Pj4+PiCzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsNCj4gPj4+Pj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnDQo+ID4+Pj4+Pj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUg c3VwcG9ydCB0byBtYWtlDQo+ID4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiA+ Pj4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0 aW9uIGluDQo+ID4+IHRvZGF5J3MNCj4gPj4+Pj4+Pj4+IG1vZGVybiBtZXRybw0KPiA+Pj4+Pj4+ Pj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGlj YWwNCj4gPj4gYXBwbGljYXRpb24NCj4gPj4+Pj4+Pj4+IGluIGluIGRhdGENCj4gPj4+Pj4+Pj4+ IGNlbnRlciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1 Y2ggYXMNCj4gPj4gTlZHUkUNCj4gPj4+IGFuZA0KPiA+Pj4+Pj4+Pj4gVlhMQU4uDQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSXQgc2VlbXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBieXBh c3MgdGhlIE5WTzMgc29sdXRpb24NCj4gPj4gc2VsZWN0aW9uDQo+ID4+Pj4+Pj4+PiBwcm9jZXNz DQo+ID4+Pj4+Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+IFNoYWhyYW0NCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAxIEFN LCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gVGhpcyBpcyB0 byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+Pj4+Pj4+Pj4+IGRyYWZ0 LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4g Pj4+Pj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBl eHRlbmRlZCB3aXRoDQo+ID4+IG9uZSB3ZWVrLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4g UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1w bHMNCj4gPj4+IHdvcmtpbmcNCj4gPj4+Pj4+Pj4+PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMg YXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhbg0KPiA+PiB0ZWNobmljYWwNCj4gPj4+Pj4+Pj4+ PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYg eW91DQo+ID4+IHRoaW5rIHRoYXQNCj4gPj4+Pj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5v dCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cA0KPiA+PiBkb2N1bWVudC4NCj4gPj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFRoaXMgcG9sbCBlbmRzIEphbnVhcnkgMDcsIDIwMTMuDQo+ID4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBUaGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhp cyBkb2N1bWVudCAtDQo+ID4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMTk0MS8gLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28t YXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+IG1haWxpbmcgbGlz dA0KPiA+Pj4+Pj4+Pj4+IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIg Y2xhaW1zIHRoYW4gdGhvc2UNCj4gPj4gYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4+IGRpc2Nsb3NlZC4N Cj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0 aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZvciB0aGUNCj4gPj4gSVBSDQo+ID4+Pj4+Pj4+Pj4g cG9sbCkNCj4gPj4+Pj4+Pj4+PiBNYXJzaGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMgb25lIG9m IHRoZSBhdXRob3JzLiBNYXJzaGFsbA0KPiA+PiBoYXMNCj4gPj4+Pj4+Pj4+PiBkaXNjb250aW51 ZWQgYWxsIGludGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+ID4+IGF1 dGhvciB0ZWFtDQo+ID4+Pj4+Pj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3 b3JraW5nIGdyb3VwIGNoYWlycyBoYXMNCj4gPj4gdHJpZWQgdG8NCj4gPj4+Pj4+Pj4+PiBjb250 YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb24gdGhl DQo+ID4+IElQUg0KPiA+Pj4+Pj4+Pj4+IHBvbGwuDQo+ID4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQg bm8gc3VjY2VzcyBpbiB0aGlzLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gRnJvbSB2ZXJz aW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBhDQo+ID4+ Pj4+Pj4+Pj4gY28tYXV0aG9yLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gL0xvYQ0KPiA+ Pj4+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPiA+Pj4+Pj4+Pj4+IC0tDQo+ID4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICAgZW1haWw6DQo+ID4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNv bQ0KPiA+Pj4+Pj4+Pj4+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAg ICAgIGxvYUBwaS5udQ0KPiA+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAg ICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTINCj4gMTMNCj4gPj4+Pj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5Mg0KPiAxMw0KPiA+ Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+PiBtcGxzQGlldGYu b3JnDQo+ID4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+IG1wbHNA aWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPiA+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+PiBtcGxz QGlldGYub3JnDQo+ID4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+PiBtcGxzQGll dGYub3JnDQo+ID4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyDQo+ID4+IENhYmxlDQo+ID4+ Pj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yDQo+ID4+IHN1YmplY3QgdG8NCj4gPj4+Pj4gY29weXJpZ2h0IGJlbG9uZ2luZyB0 byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4gPj4gc29sZWx5 IGZvcg0KPiA+Pj4gdGhlDQo+ID4+Pj4+IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg dG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UNCj4gPj4gYXJlIG5vdCB0aGUNCj4gPj4+ Pj4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3Rp ZmllZCB0aGF0DQo+ID4+IGFueQ0KPiA+Pj4gZGlzc2VtaW5hdGlvbiwNCj4gPj4+Pj4gZGlzdHJp YnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRl bnRzDQo+ID4+IG9mIGFuZA0KPiA+Pj4+PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUNCj4gPj4gdW5sYXdmdWwuIElmIHlvdQ0KPiA+ Pj4+PiBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCj4gPj4gaW1tZWRpYXRlbHkgYW5kDQo+ID4+Pj4+IHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZA0KPiA+PiBhbnkg cHJpbnRvdXQuDQo+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IG1wbHNAaWV0 Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBs c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== From xuxiaohu@huawei.com Thu Dec 20 17:56:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF94621F8775 for ; Thu, 20 Dec 2012 17:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzCaIMqhLXrn for ; Thu, 20 Dec 2012 17:56:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6C1921E8034 for ; Thu, 20 Dec 2012 17:56:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOA59048; Fri, 21 Dec 2012 01:56:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:56:20 +0000 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 01:56:33 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 09:56:24 +0800 From: Xuxiaohu To: Shahram Davari , Lucy yong Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sszh5eWXqDbZUC4MEZ17BejhpghW8uAgAAGHQCAAAntgIABD+5A Date: Fri, 21 Dec 2012 01:56:23 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> 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.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 01:56:39 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFNoYWhyYW0gRGF2YXJpDQo+ ILeiy83KsbzkOiAyMDEyxOoxMtTCMjHI1SAxOjMxDQo+IMrVvP7IyzogTHVjeSB5b25nDQo+ILOt y806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsNCj4gbXBsc0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW21wbHNdIE1QTFMgY2xp ZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KPiANCj4gUGxlYXNlIGRv bid0IG1peCB1cCB0aGluZ3MuIFRoZSBNUExTIHByb3RvY29sIGRlc2lnbiBJIGFncmVlIG11c3Qg YmUgZG9uZSBieQ0KPiBNUExTIFdHLiBCdXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91ciBw cm9wb3NhbCBtZWV0cyB0aGUgbmV0d29yaw0KPiB2aXJ0dWFsaXphdGlvbiByZXF1aXJlbWVudHMu DQoNCkNhbiB5b3UgdGVsbCB1cyB3aGVyZSBNUExTLWluLUdSRS9JUCBbUkZDNDAyM10gYW5kIG90 aGVyIE1QTFMgb3ZlciBJUCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMgaGF2ZSBiZWVuIGRpc2N1 c3NlZCBiZWZvcmU/DQoNClNpbmNlIE1QTFMtaW4tVURQIGlzIGp1c3QgaW50ZW5kZWQgdG8gYmUg dXNlZCBpbiB0aGUgc2NlbmFyaW9zIHdoZXJlIE1QTFMtaW4tR1JFL0lQIGhhcyBiZWVuIHVzZWQg YW5kIGlzIHRvIGJlIHVzZWQsIE1QTFMtaW4tVURQIHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhl IHNhbWUgV0cgd2hlcmUgTVBMUy1pbi1HUkUvSVAgaGFzIGJlZW4gZGlzY3Vzc2VkLg0KDQpYaWFv aHUNCg0KPiBUaGUgTlZPMyB0YXNrIGlzIHRvIGRvY3VtZW50IHRoZSBpc3N1ZXMsIHJlcXVpcmVt ZW50cyBhbmQgZnJhbWV3b3JrIGZvcg0KPiBOdk8zLiBUaGVuIGlmIE1QTFMgb3ZlciBJUCBsb29r cyBsaWtlIGEgc3VpdGFibGUgc29sdXRpb24gdGhhdCBtZWV0cyB0aGUNCj4gcmVxdWlyZW1lbnRz IHN1Y2ggYXMgdGhlIHNjYWxlLCBtb2JpbGl0eSwgZXRjLCB0aGVuIHRoZXkgd2lsbCBhc2sgTVBM UyBXRyBmb3INCj4gcHJvdG9jb2wgZGVzaWduLg0KPiANCj4gU28gYmVmb3JlIHByb2NlZWRpbmcg dGhpcyBkcmFmdCwgSSB0aGluayB5b3Ugc2hvdWxkIHRha2UgaXQgdG8gTlZPMyBXRyBhbmQNCj4g Y29udmluY2UgdGhlbSB0aGlzIHNvbHV0aW9uIG1lZXRzIHRoZWlyIHJlcXVpcmVtZW50cyBhbmQg ZnJhbWV3b3JrLg0KPiANCj4gV2UgZG9uJ3Qgd2FudCBJRVRGIGRvIGRlc2lnbiBOIG51bWJlciBv ZiBzb2x1dGlvbnMgZm9yIHRoZSBzYW1lIHByb2JsZW0sIGRvDQo+IHdlPw0KPiANCj4gLVNoYWhy YW0NCj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gU2hhaHJhbQ0KPiANCj4gDQo+IE9uIERlYyAy MCwgMjAxMiwgYXQgODo1NiBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPiB3 cm90ZToNCj4gDQo+ID4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGlzIGRpc2N1c3Nl ZCB1bmRlciBudm8zIFdHLiBUaGlzIGRvZXMgbm90DQo+IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0 byBkZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEgdW5kZXJseWluZyBuZXR3b3JrIG9yIGENCj4g bmV3IHByb3RvY29sIGZvciBhIG92ZXJsYXkgbmV0d29yay4gSW4gZmFjdCwgcGVvcGxlIHRoZXJl IGFpbSBvbiBsZXZlcmFnZQ0KPiBzdGFuZGFyZCBuZXR3b3JrIHByb3RvY29scyB0byBhY2NvbXBs aXNoIHRoZW0uIElNTzogdGhlc2UgZXhwYW5zaW9ucyBvbiBhbg0KPiBleGlzdGluZyBzdGFuZGFy ZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhlIHByb3RvY29sIFdHIGdyb3Vw LCBpdA0KPiBzaG91bGQgbm90IGdpdmUgbnZvMyBXRyBmcmVlIHJpZ2h0IHRvIGVuaGFuY2UgdGhl c2UgcHJvdG9jb2xzLiBGb3IgYSBicmFuZA0KPiBuZXcgcHJvdG9jb2wgZm9yIG5ldHdvcmsgdmly dHVhbGl6YXRpb24gb3ZlcmxheSwgbnZvMyBXRyBtYXkgYmUgdGhlIHBsYWNlIHRvDQo+IHN0YXJ0 Lg0KPiA+DQo+ID4gTHVjeQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbV0NCj4g Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDEwOjM0IEFNDQo+ID4+IFRvOiBM dWN5IHlvbmcNCj4gPj4gQ2M6IFNoYW5lIEFtYW50ZTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7DQo+ID4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJ R1AgdW5kZXJseWluZyBuZXR3b3JrDQo+ID4+DQo+ID4+IE5ldHdvcmsgdmlydHVhbGl6YXRpb24g b3ZlcmxheSBtdXN0IGJlIGRpc2N1c3NlZCBhbmQgY29uc2VudGVkICBpbiBOVk8zDQo+ID4+IFdH Lg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBTaGFocmFtDQo+ID4+DQo+ID4+DQo+ID4+IE9u IERlYyAyMCwgMjAxMiwgYXQgNzozOSBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWku Y29tPiB3cm90ZToNCj4gPj4NCj4gPj4+IEhpIFNoYW5lLA0KPiA+Pj4NCj4gPj4+IEkgdW5kZXJz dGFuZCBvcGVyYXRvciBjb25jZXJuIG9uIGEgbmV3IGVuY2Fwc3VsYXRpb24gdG8gYW4gZXhpc3Rp bmcNCj4gPj4gbmV0d29yay4NCj4gPj4+DQo+ID4+PiBIb3dldmVyLCBNUExTLWluLVVEUCBkb2Vz IG5vdCBhaW0gb24gY2hhbmdpbmcgZXhpc3RpbmcgU1AgSVAvTVBMUw0KPiA+PiBuZXR3b3JrIGF0 IGFsbC4NCj4gPj4+IE1QTFMtaW4tVURQIGlzIHRvIGVuYWJsZSBNUExTIGNsaWVudCBsYXllciB0 byBiZSBkZWNvdXBsZWQgZnJvbSBNUExTDQo+ID4+IHNlcnZlciBsYXllciBhbmQgdXNlIE1QTFMg Y2xpZW50IGxheWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFzDQo+ID4+IGEgdW5k ZXJseWluZyBuZXR3b3JrIGZvciB0cmFuc3BvcnQuIFN1Y2ggYXBwbGljYXRpb24gaXMgZm9yIERD LiBZb3UgbWF5DQo+ID4+IGFyZ3VlIHdoeSBub3QgdXNlIHRoZSBHUkUgd2hpY2ggaXMgZm9yIE1Q TFMgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJsaW5nDQo+ID4+IG5ldHdvcmsuIFdlIGhhdmUgcG9p bnRlZCBvdXQgaW4gdGhlIGRyYWZ0IHRoYXQgY3VycmVudCByb3V0ZXJzIGluIERDDQo+ID4+IGJh cmVseSBzdXBwb3J0IEdSRSBiYXNlZCBsb2FkIGJhbGFuY2luZyBhbmQgTVBMUy1pbi1HUkUgYXJl IGJhcmVseSB1c2VkDQo+ID4+IGluIFNQIG5ldHdvcmtzIHRvby4gTW9zdCBvZiByb3V0ZXJzIGlu IERDIHBlcmZvcm0gdXBkIHBvcnQgYmFzZWQgbG9hZA0KPiA+PiBiYWxhbmNpbmcgbm93Lg0KPiA+ Pj4NCj4gPj4+IEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhlIFVEUCBlbmNh cHN1bGF0aW9uIGhhcw0KPiA+PiBhZHZhbnRhZ2Ugb3ZlciBHUkUgZW5jYXBzdWxhdGlvbiB0b28u IEluIFVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgZnJhbWUNCj4gPj4gaGVhZGVyIGRlY291cGxlcyB0 aGUgb3ZlcmxheSBhbmQgdW5kZXJseWluZyBuZXR3b3JrIGNsZWFybHksIGkuZS4gb3V0ZXINCj4g Pj4gaGVhZGVyIGFuZCBvdmVybGF5IGhlYWRlci4gVURQIGJlbG9uZ3MgdG8gb3V0ZXIgaGVhZGVy LCB3aGljaA0KPiA+PiB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBvbmx5LiBIb3dldmVyLCBHUkUg aGVhZGVyIGhhcyB0aGUgZmllbGRzIGZvcg0KPiA+PiB0aGUgb3ZlcmxheSBuZXR3b3JrIGFuZCB1 c2VzIHRoZSBrZXkgZmllbGQgZm9yIGZsb3cgZW50cm9weS4gRm9yIGxvYWQNCj4gPj4gYmFsYW5j aW5nLCBpdCByZXF1aXJlcyB0aGUgdW5kZXJseWluZyBuZXR3b3JrIHVzZXMgR1JFIGhlYWRlciB0 b28uIEluDQo+ID4+IHNob3J0LCBHUkUgdGllcyB0aGUgb3ZlcmxheSBhbmQgdW5kZXJseWluZyBu ZXR3b3JrcyB0b2dldGhlci4gU2luY2UgaXQNCj4gPj4gaGFzIG5vdCB1c2VkIGEgbG90LCBwZW9w bGUgYXJlIG5vdCBhd2FyZSBvZiB0aGUgZGlzYWR2YW50YWdlIG9mIHN1Y2gNCj4gPj4gY291cGxp bmcuDQo+ID4+Pg0KPiA+Pj4gQXMgdGhlIGluZHVzdHJ5IG1vdmVzIHRvd2FyZCBuZXR3b3JrIHZp cnR1YWxpemF0aW9uIG92ZXJsYXkgYW5kDQo+ID4+IGRlY291cGxlcyBvdmVybGF5IG5ldHdvcmtz IGZyb20gdGhlIHVuZGVybHlpbmcgbmV0d29yay4gQSBjbGVhcg0KPiA+PiBzZXBhcmF0aW9uIG9m IG92ZXJsYXkgaGVhZGVyIGFuZCB1bmRlcmx5aW5nIGhlYWRlciBpcyBhICJNVVNUIiBpbiBteQ0K PiA+PiBvcGluaW9uLiBJZiB3ZSBjb3VudCBHUkUgYXMgdGhlIG92ZXJsYXkgaGVhZGVyLCB0aGVu IGZvciBJUHY0DQo+ID4+IHVuZGVybHlpbmcgbmV0d29yaywgdGhlcmUgaXMgbm8gZmllbGQgZm9y IHRoZSBmbG93IGVudHJvcHkuIFRoaXMgaXMgdGhlDQo+ID4+IHJlYXNvbiB3ZSBwcm9wb3NlIHRo ZSBVRFAgZW5jYXBzdWxhdGlvbjogZm9yIGFuIElHUCBiYXNlZCB1bmRlcmx5aW5nDQo+ID4+IG5l dHdvcmsuIEluIGZhY3QsIGl0IGNhbiBzdXBwb3J0IGFueSBvdmVybGF5IG5ldHdvcmsgYmVzaWRl IE1QTFMgY2xpZW50DQo+ID4+IGxheWVyIChlLmcuIFZYTEFOLCBMMlRQLWluLVVEUCwgZXRjKS4N Cj4gPj4+DQo+ID4+PiBZb3UgcG9pbnQgb3V0IHVzaW5nIE1QTFMtaW4tTDJUUC1pbi1VRFAgaW5z dGVhZC4gWWVzLCBNUExTLWluLUwyVFAtDQo+ID4+IGluLVVEUCBzY2hlbWEgYWxzbyBwcm92aWRl cyBhIG92ZXJsYXkgKEwyVFApIGFuZCB1bmRlcmx5aW5nIChJUCkNCj4gPj4gbmV0d29yayBkZWNv dXBsaW5nLiBMMlRQIHByb3RvY29sIChyZmMzOTMxKSBwcm92aWRlcyBnb29kIHNlY3VyaXR5DQo+ ID4+IG1lY2hhbmlzbSBhbmQgaGFzIHRoZSBlbWJlZGRlZCBjb250cm9sIGZ1bmN0aW9uIHRvby4g VGhlcmVmb3JlLA0KPiBzb21lb25lDQo+ID4+IGNhbiB1c2UgaXQgZm9yIE1QTFMgY2xpZW50IGxh eWVyIG92ZXIgSW50ZXJuZXQuIFRvIGhhdmUgTVBMUyBjbGllbnQNCj4gPj4gbGF5ZXIgb3ZlciBh biBJR1AgdW5kZXJsaW5nIG5ldHdvcmssIElNTzogTVBMUy1pbi1MMlRQLWluLVVEUCBpcyBhDQo+ ID4+IG92ZXJraWxsIGFuZCB0b28gY29tcGxleC4gSGVyZSB3ZSBuZWVkIGEgc2NoZW1hIHRvIHN1 cHBvcnQgSUdQDQo+ID4+IHVuZGVybHlpbmcgdHJhbnNwb3J0IHdpdGhvdXQgdG91Y2hpbmcgYSBv dmVybGF5IGhlYWRlci4gVURQDQo+ID4+IGVuY2Fwc3VsYXRpb24gaXMgdGhlIGJlc3QgY2hvaWNl IHRvIGFjY29tcGxpc2ggdGhhdCBhbmQgbWluaW1pemUgdGhlDQo+ID4+IGNoYW5nZXMgb24gZXhp c3Rpbmcgcm91dGVycywgZS5nLiBjaGFuZ2UgYXQgZWRnZSByb3V0ZXJzLCBubyBjaGFuZ2Ugb24N Cj4gPj4gdHJhbnNpdCByb3V0ZXJzLg0KPiA+Pj4NCj4gPj4+IFJlZ2FyZHMsDQo+ID4+PiBMdWN5 DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4+PiBGcm9tOiBYdXhpYW9odSBbbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb21dDQo+ID4+ Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDQ6MTQgQU0NCj4gPj4+PiBUbzog U2hhbmUgQW1hbnRlDQo+ID4+Pj4gQ2M6IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRy YWZ0LXh1LW1wbHMtaW4tDQo+ID4+IHVkcEB0b29scy5pZXRmLm9yZzsNCj4gPj4+PiBtcGxzQGll dGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IERpc2N1 c3Npb24gb24gaG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIgVURQIHR1bm5lbHMNCj4gPj4+Pg0K PiA+Pj4+IEhpIFNoYW5lLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIg Y29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0KPiA+Pj4+DQo+ID4+ Pj4gTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdzIHN1 Z2dlc3Rpb24uDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+ILei vP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0KPiA+Pj4+ PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMjI6MzgNCj4gPj4+Pj4gytW8/sjLOiBYdXhpYW9o dQ0KPiA+Pj4+PiCzrcvNOiBSb2dlcnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFmdC14dS1t cGxzLWluLQ0KPiA+Pj4+IHVkcEB0b29scy5pZXRmLm9yZzsNCj4gPj4+Pj4gbXBsc0BpZXRmLm9y ZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+Pj4g1vfM4jogUmU6IFttcGxzXSBw b2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS0NCj4gPj4+PiBt cGxzLWluLXVkcCBhbg0KPiA+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+ Pj4NCj4gPj4+Pj4gWGlhb2h1LA0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0 IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4NCj4gd3JvdGU6DQo+ID4+ Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+Pj4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFtt YWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0XQ0KPiA+Pj4+Pj4+ILeiy83KsbzkOiAyMDEyxOox MtTCMTnI1SAxMTo1OA0KPiA+Pj4+Pj4+IMrVvP7IyzogUm9nZXJzLCBKb3NoDQo+ID4+Pj4+Pj4g s63LzTogU2hhaHJhbSBEYXZhcmk7IFh1eGlhb2h1OyBkcmFmdC14dS1tcGxzLWluLQ0KPiA+Pj4+ IHVkcEB0b29scy5pZXRmLm9yZzsNCj4gPj4+Pj4+PiBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZw0KPiA+Pj4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUg aWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+Pj4gbXBscy1pbi11ZHAN Cj4gPj4+Pj4gYW4NCj4gPj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAi Um9nZXJzLCBKb3NoIg0KPiA+Pj4+IDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbT4NCj4gPj4+Pj4+ PiB3cm90ZToNCj4gPj4+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8g bm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+Pj4gc29sdXRpb24NCj4gPj4+Pj4+Pj4gYWRk cmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiArMS4g IFBsZWFzZSBkbyBub3QgZGVmaW5lIHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0 aW9uLg0KPiA+Pj4+IFRoZQ0KPiA+Pj4+PiBJRVRGDQo+ID4+Pj4+Pj4gYWxyZWFkeSBzdGFuZGFy ZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvDQo+ID4+Pj4gc3RhbmRhcmRp emVkDQo+ID4+Pj4+IE1QTFMNCj4gPj4+Pj4+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhh ZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdA0KPiA+PiBvbmUsDQo+ID4+Pj4gdmVy eQ0KPiA+Pj4+Pj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8g c3VwcG9ydCBjYXJyaWFnZSBvZg0KPiA+Pj4+IEwzVlBOIG92ZXINCj4gPj4+Pj4gYW4NCj4gPj4+ Pj4+PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU2hhbmUsDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmsgeW91IGZvciB0ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwg ZGVwbG95bWVudHMgb2YgTVBMUyBvdmVyDQo+ID4+Pj4gSVAgaW4gYXQNCj4gPj4+Pj4gbGVhc3Qg b25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkN Cj4gPj4+PiB2YWx1YWJsZSB0byB0aG9zZQ0KPiA+Pj4+PiBwZW9wbGUgd2hvIGhhZCBiZWxpZXZl ZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlvbiBvZiBNUExTIG92ZXIgSVAgaW4NCj4gPj4+PiB0b2Rh eSdzIFNQDQo+ID4+Pj4+IG5ldHdvcmtzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBTZWU6IFJGQydz IDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4+PiBb Tk9URTogdGhlIGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUg MjAwNg0KPiA+Pj4+PiB0aW1lZnJhbWUhXQ0KPiA+Pj4+Pj4+ICAgUkZDIDQ2NjUgZm9yIHJlcXVp cmVtZW50cyByZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTDQo+ID4+Pj4gbWF5IGJl DQo+ID4+Pj4+Pj4gY2FycmllZCBvdmVyIEwyVFB2Mw0KPiA+Pj4+Pj4+ICAgQW5kLCBoZXJlJ3Mg ZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0IG9uZSB2ZW5kb3IgaGFzDQo+ID4+Pj4+IGlt cGxlbWVudGVkDQo+ID4+Pj4+Pj4gSVBWUE4ncyBvdmVyIEwyVFB2MzoNCj4gPj4gaHR0cDovL3d3 dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5o dG1sDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92 ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlvbmVkIGluDQo+ID4+Pj4gdGhpcyBkcmFmdA0KPiA+Pj4+ PiBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxj dWxhdGlvbiBvbg0KPiA+PiB0aGUNCj4gPj4+PiBTZXNzaW9uDQo+ID4+Pj4+IElEIGZpZWxkIGlu IHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgYXMN Cj4gPj4+PiBkZWZpbmVkIGluDQo+ID4+Pj4+IFtSRkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBw b3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNvIGZhci4NCj4gPj4+Pj4NCj4gPj4+Pj4g RldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwg aW4NCj4gPj4+PiByZXF1ZXN0aW5nIGEgY29yZQ0KPiA+Pj4+PiByb3V0ZXIgdmVuZG9yIHRvIHN1 cHBvcnQgY2hhbmdlcyB0byB0aGUgaW5wdXQta2V5cyB1c2VkIGluIGhhc2gNCj4gPj4+PiBjYWxj dWxhdGlvbnMgaW4NCj4gPj4+Pj4gX2V4aXN0aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3ll ZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQgbXkNCj4gPj4+PiBuZXR3b3JrLg0KPiA+Pj4+PiBG dXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBz YXZ2eQ0KPiA+PiBmb2xrcw0KPiA+Pj4+IGFuZA0KPiA+Pj4+PiB1bmRlcnN0YW5kIHRoZSBpbnRl cm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuICBBcyBhDQo+ID4+Pj4g cmVzdWx0LCB0aG9zZQ0KPiA+Pj4+PiBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlz IG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzDQo+ID4+Pj4gcmVnYXJkLg0KPiA+Pj4+ PiBUaHVzLCBpdCBtYXkgYmUgYSBxdWVzdGlvbiBvZiAibWV0aG9kcyIgbmVjZXNzYXJ5IHRvIGNv bnZpbmNlIHRoZWlyDQo+ID4+Pj4gSFcNCj4gPj4+Pj4gc3VwcGxpZXIocykgdG8gbWFrZSBhcHBy b3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0bw0KPiA+PiBhY2hpZXZlDQo+ID4+ Pj4gdGhlaXINCj4gPj4+Pj4gYnVzaW5lc3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5 IG5vdCBldmVuIGJlIG5lY2Vzc2FyeSAuLi4NCj4gPj4gc2VlDQo+ID4+Pj4gYmVsb3cuDQo+ID4+ Pj4NCj4gPj4+PiBDb3VsZCB5b3UgcGxlYXNlIGJyaWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0 aGUgYWJvdmUgY2hhbmdlIGluDQo+ID4+Pj4gRVhJU1RJTkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBk ZXBsb3llZCBjb3JlIHJvdXRlcnM/DQo+ID4+Pj4NCj4gPj4+Pj4+IEluIGNvbnRyYXN0LCBtb3N0 IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mDQo+ID4+Pj4gYmFs YW5jaW5nIElQDQo+ID4+Pj4+IHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2YgdGhl IGZpdmUtdHVwbGUgb2YgVURQIHBhY2tldHMuDQo+ID4+IEJ5DQo+ID4+Pj4gdXNpbmcgdGhlDQo+ ID4+Pj4+IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBs b2FkLWJhbGFuY2luZw0KPiA+Pj4+IGNhcGFiaWxpdHkgb2YNCj4gPj4+Pj4gbW9zdCBleGlzdGlu ZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkNCj4g Pj4+PiBjaGFuZ2UgdG8NCj4gPj4+Pj4gdGhlbS4gVGhhdCBpcyB0aGUgbWFqb3IgbW90aXZhdGlv biBvZiB0aGlzIGRyYWZ0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiB0aGlzIGlzIGEgY29uY2Vybiwg dGhlbiB3aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFmZmljIGluDQo+ID4+Pj4gTVBMUy9MMlRQ djMsIHdoaWNoDQo+ID4+Pj4+IHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+ID4+ Pj4NCj4gPj4+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB5b3UgcHJlZmVyIHRvIHVz ZSBNUExTLWluLUwyVFB2My1pbi0NCj4gPj4gVURQDQo+ID4+Pj4gaW5zdGVhZCBvZiBNUExTLWlu LVVEUCwgcmlnaHQ/DQo+ID4+Pj4NCj4gPj4+Pj4gSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5 IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAoPykgY2hhbmdlIHRvDQo+ID4+Pj4gUkZDIDM5MzEs DQo+ID4+Pj4+IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBjb25uZWN0aW9uIHVzZWQgZm9yIGRhdGEg cGFja2V0cyAobm90IGNvbnRyb2wNCj4gPj4+PiBwYWNrZXRzKQ0KPiA+Pj4+PiB0byB1c2UgYSB2 YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwNCj4g Pj4gYmFzZWQNCj4gPj4+PiBvbiBhIGhhc2gNCj4gPj4+Pj4gY2FsY3VsYXRpb24sIHRvIGFjaGll dmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92ZXIgZXhpc3RpbmcNCj4gPj4gZXF1aXBtZW50DQo+ ID4+Pj4gaW4gYW4NCj4gPj4+Pj4gSVAtb25seSBjb3JlLiAgTDJUUCBlbmQtc3lzdGVtIGltcGxl bWVudGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIgb2ZmDQo+ID4+Pj4ganVzdCB1c2luZw0KPiA+Pj4+ PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBs ZXhvciB0bw0KPiA+Pj4+IGFzc29jaWF0ZQ0KPiA+Pj4+PiBpbmNvbWluZyBwYWNrZXRzIHdpdGgg dGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9sIENoYW5uZWwuICBJbiBmYWN0LA0KPiA+Pj4+IGl0 J3Mgbm90DQo+ID4+Pj4+IGNsZWFyIHRvIG1lIHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IG1heSAvYWxyZWFkeS8gZG8gdGhpcywNCj4gPj4+PiBtYWtpbmcgYW55DQo+ID4+Pj4+ICJjaGVj ayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1z eXN0ZW0NCj4gPj4+Pj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgYmVh dXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCj4gPj4+Pj4gMSkgSSB3b3VsZCB0aGluayB0 aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBhIGNoYW5nZSB0aGF0IGlzDQo+ID4+Pj4gbGlt aXRlZCB0byB0aGUNCj4gPj4+Pj4gImNvbnRyb2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBvZiBleGlz dGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+PiBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+Pj4+IEhl Y2ssIGl0IG1heSBldmVuIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgTDJU UHYzDQo+ID4+Pj4+IGltcGxlbWVudGF0aW9ucy4gIChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxk IG5lZWQgdG8gY29tbWVudCBvbg0KPiA+PiB0aGF0KS4NCj4gPj4+Pg0KPiA+Pj4+IElNSE8sIG5v IG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsICB0aGUgaGFyZHdh cmUNCj4gPj4gb2YNCj4gPj4+PiBQRSByb3V0ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcu LCBpbmdyZXNzIFBFIHJvdXRlcnMgbmVlZCB0bw0KPiA+PiBmaWxsDQo+ID4+Pj4gaW4gYW4gZW50 cm9weSB2YWx1ZSBpbiB0aGUgc291cmNlIHBvcnQgZmllbGQgb2YgVURQIGhlYWRlcnMuDQo+ID4+ Pj4NCj4gPj4+Pj4gMikgVGhlcmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUg Z2V0cyBieSB1c2luZyAiU2Vzc2lvbg0KPiA+Pj4+IElEIiBhbmQNCj4gPj4+Pj4gIkNvb2tpZSIg ZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZA0K PiA+PiBmb3INCj4gPj4+PiB0aGUNCj4gPj4+Pj4gaWRlbnRpZmllZCBzZXNzaW9uLiAgUXVvdGlu ZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOg0KPiA+Pj4+PiAtLS1zbmlwLS0tDQo+ID4+ Pj4+ICBMMlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEg YSAzMi1iaXQNCj4gPj4+PiBTZXNzaW9uDQo+ID4+Pj4+ICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEg aGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KPiA+Pj4+PiAgKGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8NCj4g Pj4gZW5zdXJlDQo+ID4+Pj4+ICB0aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBm b3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4NCj4gPj4+Pj4gIFRodXMsIHVzZSBvZiBhIENvb2tp ZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhDQo+ID4+Pj4gZ3VhcmFudGVl DQo+ID4+Pj4+ICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVyZm9ybWVkIHByb3Bl cmx5IGFuZCB0aGF0IHRoZQ0KPiA+Pj4+PiAgU2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3Jy dXB0ZWQgaW4gdHJhbnNpdC4NCj4gPj4+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4+PiAuLi4gaW4gcmVn YXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYQ0KPiA+ PiBmb2xrcw0KPiA+Pj4+IGhhdmUsIGluIHRoZQ0KPiA+Pj4+PiBwYXN0LCBoYWQgL3N1YnN0YW50 aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9uIG9mIE1QTFMgb3Zlcg0KPiA+PiBJUA0K PiA+Pj4+IHRyYW5zcG9ydC4NCj4gPj4+Pj4gSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0 ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZg0KPiA+PiBSRkMNCj4gPj4+PiA0NjY1 Lg0KPiA+Pj4+PiAoVGhlcmUncyBsaWtlbHkgc2ltaWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFm dHMgdGhhdCB1c2UgTVBMUyBmb3INCj4gPj4+PiB0cmFuc3BvcnQpLg0KPiA+Pj4+PiBXaGlsZSBJ J20gbm90IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0 bw0KPiA+Pj4+IGRhaWx5IHRyYWZmaWMgb24NCj4gPj4+Pj4gdGhlIE1QTFMgV0cgbWFpbGluZyBs aXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0aGlzIGNvbmNlcm4gd2lsbA0KPiA+Pj4+IGFyaXNl IGlmL3doZW4gdGhpcw0KPiA+Pj4+PiBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KPiA+Pj4+ DQo+ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhlIHJlYXNvbiBmb3IgeW91 ciBwcmVmZXJlbmNlIG9mDQo+ID4+IE1QTFMtDQo+ID4+Pj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0 aGF0IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0eSBmZWF0dXJlLiBJZiB0aGF0DQo+ID4+IGlzDQo+ ID4+Pj4gc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxhaW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZh ciBtb3JlIHBvcHVsYXINCj4gPj4gdGhhbg0KPiA+Pj4+IE1QTFMtaW4tTDJUUCBpbiBwcmFjdGlj ZT8NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+PiBYaWFvaHUNCj4gPj4+Pg0K PiA+Pj4+PiAzKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5 c3RlbXMgdGhhdA0KPiA+PiBpbXBsZW1lbnQNCj4gPj4+PiBMMlRQLCBmb3INCj4gPj4+Pj4gdHVu bmVsaW5nIG9mIE1QTFMvSVAsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFuIGVudGlyZSBpbmR1c3Ry eSB0bw0KPiA+Pj4+IHN1cHBvcnQNCj4gPj4+Pj4gTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0 aGVpciBwcm9kdWN0IGxpbmVzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAtc2hhbmUNCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUN Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1QTFMg b3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0DQo+ID4+IHdvdWxkDQo+ID4+Pj4gaGF2ZQ0KPiA+Pj4+ PiBiZWVuDQo+ID4+Pj4+Pj4gbW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZl bmRvcnMsIHdpdGggZWl0aGVyIE1QTFMNCj4gPj4+PiBvdmVyDQo+ID4+Pj4+IEdSRSBvcg0KPiA+ Pj4+Pj4+IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3Mg YSB3YXkpLiAgSQ0KPiA+PiB3b3VsZA0KPiA+Pj4+IG5vdGUNCj4gPj4+Pj4gdGhhdA0KPiA+Pj4+ Pj4+IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVy ZSBhcmUNCj4gPj4gc2V2ZXJhbCwNCj4gPj4+PiBwcmFjdGljYWwNCj4gPj4+Pj4+PiBvcGVyYXRp b25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdvaW5nIHdpdGggbmF0aXZlIE1QTFMNCj4gPj4+ Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4gdGhlIGRhdGEgcGxhbmUsIG5hbWVs eToNCj4gPj4+Pj4+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0ZQ0KPiA+Pj4+Pj4+IC0gTVBMUyBUcmFm ZmljIEVuZ2luZWVyaW5nDQo+ID4+Pj4+Pj4gLi4uIHRvIG5hbWUsIGJ1dCBhIGZldy4gIFRob3Nl IGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxpbmcNCj4gPj4+Pj4gYXJndW1lbnRzDQo+ ID4+Pj4+Pj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3Vs YXRpb24vc3dpdGNoaW5nLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gLXNoYW5lDQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtSm9zaA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJy b2FkY29tLmNvbT4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBGb3Ig c2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdhY3kgYW5kIHRoZXJl DQo+ID4+IGlzDQo+ID4+Pj4gbm8gbmVlZA0KPiA+Pj4+Pj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6 MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+DQo+ID4+Pj4+IHdyb3RlOg0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXIt SVANCj4gPj4+PiBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0 ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gPj4+PiB0aG9zZQ0K PiA+Pj4+Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5n IE1QTFMgYXBwbGljYXRpb24NCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+Pj4+Pj4gYWNyb3NzIElQ IG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4gPj4g YW5kDQo+ID4+Pj4+IFZYTEFODQo+ID4+Pj4+Pj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBhZHZv Y2F0b3JzIGFuZCB1c2UgY2FzZXMuIElmIHlvdQ0KPiA+PiBhYnNvbHV0ZWx5DQo+ID4+Pj4gYmVs aWV2ZQ0KPiA+Pj4+Pj4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMg YXBwbGljYXRpb24gdHJhZmZpYw0KPiA+Pj4+IGFjcm9zcyBJUA0KPiA+Pj4+Pj4+Pj4+IG5ldHdv cmtzIGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMNCj4g Pj4gb3Zlcg0KPiA+Pj4+IElQDQo+ID4+Pj4+Pj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMgc2hv dWxkIGJlIG1vdmVkIHRvIEhpc3RvcmljIHN0YXR1cywNCj4gPj4gcGxlYXNlDQo+ID4+Pj4gc2F5 DQo+ID4+Pj4+IHNvLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQnkgdGhlIHdheSwgaXQg c2VlbXMgdGhpcw0KPiA+Pj4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ID4+ Pj4gYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+Pj4+Pj4+ Pj4ganVzdCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9s bG93aW5nDQo+ID4+Pj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBu b3QgTVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+ID4+Pj4gY2VudGVycyku IEkNCj4gPj4+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhhdCB0 aW1lLiBTYWRseSwNCj4gPj4+PiBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+Pj4+Pj4+Pj4gdGls bCBub3cuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQg dG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBY aWFvaHUNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g Pj4+Pj4+Pj4+Pj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddDQo+ID4+ILT6DQo+ID4+Pj4gse0NCj4gPj4+Pj4+PiBTLg0KPiA+Pj4+ Pj4+Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNcjVIDEz OjM0DQo+ID4+Pj4+Pj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+Pj4+Pj4+Pj4+PiCz rcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsN Cj4gPj4+Pj4+Pj4+Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4g 1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZQ0K PiA+Pj4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiA+Pj4+Pj4+Pj4+PiBtcGxz IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gSSBk b24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGluDQo+ ID4+Pj4gdG9kYXkncw0KPiA+Pj4+Pj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4gPj4+Pj4+Pj4+Pj4g YW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwN Cj4gPj4+PiBhcHBsaWNhdGlvbg0KPiA+Pj4+Pj4+Pj4+PiBpbiBpbiBkYXRhDQo+ID4+Pj4+Pj4+ Pj4+IGNlbnRlciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25z IHN1Y2ggYXMNCj4gPj4+PiBOVkdSRQ0KPiA+Pj4+PiBhbmQNCj4gPj4+Pj4+Pj4+Pj4gVlhMQU4u DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0 cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uDQo+ID4+Pj4gc2VsZWN0aW9uDQo+ID4+ Pj4+Pj4+Pj4+IHByb2Nlc3MNCj4gPj4+Pj4+Pj4+Pj4gYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBp biBNUExTIFdHLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+ Pj4+Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+IE9uIERlYyAxNCwgMjAxMiwgYXQgMTowMSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 PiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+ ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyB0byBzdGFydCBhICJ0d28gd2Vl ayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+Pj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAt MDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pj4+Pj4+Pj4+Pj4gRHVl IHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0aA0K PiA+Pj4+IG9uZSB3ZWVrLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzDQo+ID4+ Pj4+IHdvcmtpbmcNCj4gPj4+Pj4+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBp ZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuDQo+ID4+Pj4gdGVjaG5pY2FsDQo+ID4+Pj4+Pj4+Pj4+ PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYg eW91DQo+ID4+Pj4gdGhpbmsgdGhhdA0KPiA+Pj4+Pj4+Pj4+Pj4gdGhlIGRvY3VtZW50IHNob3Vs ZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gPj4+PiBkb2N1bWVudC4NCj4g Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAy MDEzLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xh aW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+ PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3Jv dXANCj4gPj4+PiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IHRoYXQgdGhleSBhcmUgbm90 IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UNCj4gPj4+PiBhbHJlYWR5 DQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ Pj4gSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQg Zm9yDQo+ID4+IHRoZQ0KPiA+Pj4+IElQUg0KPiA+Pj4+Pj4+Pj4+Pj4gcG9sbCkNCj4gPj4+Pj4+ Pj4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2YgdGhlIGF1dGhvcnMu IE1hcnNoYWxsDQo+ID4+Pj4gaGFzDQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjb250aW51ZWQgYWxsIGlu dGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+ID4+Pj4gYXV0aG9yIHRl YW0NCj4gPj4+Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2lu ZyBncm91cCBjaGFpcnMgaGFzDQo+ID4+Pj4gdHJpZWQgdG8NCj4gPj4+Pj4+Pj4+Pj4+IGNvbnRh Y3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbg0KPiA+ PiB0aGUNCj4gPj4+PiBJUFINCj4gPj4+Pj4+Pj4+Pj4+IHBvbGwuDQo+ID4+Pj4+Pj4+Pj4+PiBX ZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4+Pj4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJz aGFsbCBhcyBhDQo+ID4+Pj4+Pj4+Pj4+PiBjby1hdXRob3IuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+Pj4gL0xvYQ0KPiA+Pj4+Pj4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+ID4+ Pj4+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPiA+Pj4+ Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KPiA+Pj4+Pj4+Pj4+Pj4gU3IgU3Ry YXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51DQo+ID4+Pj4+ Pj4+Pj4+PiBFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAgICAgIHBob25lOiArNDYg MTAgNzE3DQo+IDUyDQo+ID4+IDEzDQo+ID4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArNDYgNzY3IDcyIDkyDQo+IDEzDQo+ID4+Pj4+Pj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+ Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4g Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K PiA+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+Pj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+PiBtcGxz QGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ Pj4+PiBtcGxzQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4g Pj4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l IFdhcm5lcg0KPiA+Pj4+IENhYmxlDQo+ID4+Pj4+Pj4gcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4gPj4+PiBzdWJqZWN0IHRv DQo+ID4+Pj4+Pj4gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQNCj4gPj4+PiBzb2xlbHkgZm9yDQo+ID4+Pj4+IHRoZQ0KPiA+ Pj4+Pj4+IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRk cmVzc2VkLiBJZiB5b3UNCj4gPj4+PiBhcmUgbm90IHRoZQ0KPiA+Pj4+Pj4+IGludGVuZGVkIHJl Y2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdA0KPiA+ Pj4+IGFueQ0KPiA+Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPiA+Pj4+Pj4+IGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZQ0KPiA+PiBjb250ZW50 cw0KPiA+Pj4+IG9mIGFuZA0KPiA+Pj4+Pj4+IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KPiA+Pj4+IHVubGF3ZnVsLiBJZiB5b3UN Cj4gPj4+Pj4+PiBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXINCj4gPj4+PiBpbW1lZGlhdGVseSBhbmQNCj4gPj4+Pj4+PiBwZXJtYW5l bnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQN Cj4gPj4+PiBhbnkgcHJpbnRvdXQuDQo+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ ID4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+ PiBtcGxzQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg== From davarish@yahoo.com Fri Dec 21 00:10:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4A21F8A63 for ; Fri, 21 Dec 2012 00:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2lnJ-40EtFM for ; Fri, 21 Dec 2012 00:10:05 -0800 (PST) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5371C21F850E for ; Fri, 21 Dec 2012 00:10:04 -0800 (PST) Received: from [98.139.212.146] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 08:10:03 -0000 Received: from [98.139.215.229] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 08:10:03 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 08:10:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 630365.13301.bm@omp1069.mail.bf1.yahoo.com Received: (qmail 15158 invoked by uid 60001); 21 Dec 2012 08:10:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356077403; bh=FgW98wpRmHhNDQqAYOd7rVuvtB9/U/fd3ccpAwLKRQw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OYJWGEqYQ/ji0bk+jhWpPbBbHUQ4cAoDceGY5IzIayH1eGA1In7vWak/xHLL+YddHkTfD9jiWIYJLAVFhNoSPs01a8Xyrj9+c+Dq4s9t5fgfyTntQTGCcPWQXb4TBIrBPNtvojsWfXsR90s8SVz76q9OIFoCVN0qvJp9jDC7NCQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pHzhmlf7DK8wNvNCkfmS/ll8+gIz2VEGmCC6bZyCfyb39izE4rT3g66rOThOoMQuEa944Cf7NqsTs7WsPEaglx1xOwkFUe5xv7mN3xkDMOXauHcQgf9W9ERYxemx0Exfix8llx0pdp+YRet5kvun6Ac+0AlHMhBle2UCgdfRFvs=; X-YMail-OSG: 977UTrAVM1mEMZsLecsumn.PAwiP2L98vk2lO7SMzbUe1Xa wkd3t2I8qOfhARNI2v17wiIth4xGHa1i.esW3E_cYrBG1MfalZdNwmSMvmnq VgV4zk07xMgEXkfXteKbEhEdQcZvzSpeUU1WLU73kc1nWYHcsdoyR5kwZFCk 7MbNbyzL_l6QkfRFMy4nVv4WlPHCyhx9N6PITiq64vBQsRpxV8d7QbGXaK3m TKQ8Ex_85m8cRg3rVITrW4Jt2xnOx0kCPevv55K00GTcjFqZfiH6NL3Uk0Rp Q8_JqeaVDGdd4Tk7CQTONnifZxPRndsvHjguY7V0Bb5ewLAvyD2NyKh3LKMM UAAvnm5wsQuwKSZPobDUglcxDyMw.7LeB_UBrKkJ_wYSWfmUp6ckJql9sZr. OqhabmB_PTEEq2JEtBKFlPCpkHuV90lsYWLS6DGoRzEU0CTR5Bz10vIAL8nv .bf9FqYGsFp9QUtX61P7HuMboS6gcBPn8GTut.l.iTsm1BAXppv5ntZduC8o vJBS7ZejOgA42QGGwTysoligL.wFqoQgz0JlsgrFwuC4gN8xkH2mdzWz_hlp gVFifvD449uKcnr7AolPQHhAezNOYXAfS8.TIlXTxFeth1A6WbJz4CSzJUl3 T9t9NChrHZVHgltnIOvE- Received: from [98.248.36.11] by web162502.mail.bf1.yahoo.com via HTTP; Fri, 21 Dec 2012 00:10:03 PST X-Rocket-MIMEInfo: 001.001, SGksCgpJIHRoaW5rIHdlIGFyZSBpbiBhIHZpY2lvdXMgY3ljbGUuIENvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGljaCBuZXR3b3JrIG9wZXJhdG9yIGlzIGFza2luZyBmb3IgTVBMUyBvdmVyIFVEUCBhbmQgd2hhdCBpcyB0aGUgYXBwbGljYXRpb24uwqAgQWxzbyBob3cgZG8geW91IHBsYW4gdG8gYWRkcmVzcyB0aGUgTVBMUyBNdWx0aWNhc3QgKHdoaWNoIGlzIHByb2JhYmx5IG1vcmUgaW1wb3J0YW50IHRoYW4gaW1wcm92aW5nIHRoZSBsb2FkIGJhbGFuY2luZyksIGdpdmVuIHRoYXQgUkZDNDAyMyBkb2UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.129.483 References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> Message-ID: <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> Date: Fri, 21 Dec 2012 00:10:03 -0800 (PST) From: "S. Davari" To: Xuxiaohu , Shahram Davari , Lucy yong In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1314897756-30534226-1356077403=:99620" Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 08:10:07 -0000 ---1314897756-30534226-1356077403=:99620 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI think we are in a vicious cycle. Could you please clarify which = network operator is asking for MPLS over UDP and what is the application.= =C2=A0 Also how do you plan to address the MPLS Multicast (which is probabl= y more important than improving the load balancing), given that RFC4023 doe= s not support Multicast.=0A=0AThanks,=0AShahram=0A=0A=0A=0A=0A_____________= ___________________=0A From: Xuxiaohu =0ATo: Shahram D= avari ; Lucy yong =0ACc: "draft= -xu-mpls-in-udp@tools.ietf.org" ; "mpl= s@ietf.org" ; "mpls-chairs@tools.ietf.org" =0ASent: Thursday, December 20, 2012 5:56:23 PM=0ASubject: Re: = [mpls] MPLS client layer over an IGP underlying network=0A =0A=0A=0A> -----= =E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> =E5=8F=91=E4=BB=B6=E4=BA=BA: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =E4=BB=A3=E8=A1=A8=0A>= Shahram Davari=0A> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412= =E6=9C=8821=E6=97=A5 1:31=0A> =E6=94=B6=E4=BB=B6=E4=BA=BA: Lucy yong=0A> = =E6=8A=84=E9=80=81: draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.= ietf.org;=0A> mpls@ietf.org=0A> =E4=B8=BB=E9=A2=98: Re: [mpls] MPLS client = layer over an IGP underlying network=0A> =0A> Please don't mix up things. T= he MPLS protocol design I agree must be done by=0A> MPLS WG. But the questi= on is whether your proposal meets the network=0A> virtualization requiremen= ts.=0A=0ACan you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over= IP encapsulation mechanisms have been discussed before?=0A=0ASince MPLS-in= -UDP is just intended to be used in the scenarios where MPLS-in-GRE/IP has = been used and is to be used, MPLS-in-UDP should be discussed in the same WG= where MPLS-in-GRE/IP has been discussed.=0A=0AXiaohu=0A=0A> The NVO3 task = is to document the issues, requirements and framework for=0A> NvO3. Then if= MPLS over IP looks like a suitable solution that meets the=0A> requirement= s such as the scale, mobility, etc, then they will ask MPLS WG for=0A> prot= ocol design.=0A> =0A> So before proceeding this draft, I think you should t= ake it to NVO3 WG and=0A> convince them this solution meets their requireme= nts and framework.=0A> =0A> We don't want IETF do design N number of soluti= ons for the same problem, do=0A> we?=0A> =0A> -Shahram=0A> =0A> =0A> =0A> R= egards,=0A> Shahram=0A> =0A> =0A> On Dec 20, 2012, at 8:56 AM, "Lucy yong" = wrote:=0A> =0A> > Network virtualization overlay is = discussed under nvo3 WG. This does not=0A> mean that nvo3 WG has to design = a new protocol for a underlying network or a=0A> new protocol for a overlay= network. In fact, people there aim on leverage=0A> standard network protoc= ols to accomplish them. IMO: these expansions on an=0A> existing standard p= rotocol have to be worked out in the protocol WG group, it=0A> should not g= ive nvo3 WG free right to enhance these protocols. For a brand=0A> new prot= ocol for network virtualization overlay, nvo3 WG may be the place to=0A> st= art.=0A> >=0A> > Lucy=0A> >=0A> >> -----Original Message-----=0A> >> From: = Shahram Davari [mailto:davari@broadcom.com]=0A> >> Sent: Thursday, December= 20, 2012 10:34 AM=0A> >> To: Lucy yong=0A> >> Cc: Shane Amante; draft-xu-m= pls-in-udp@tools.ietf.org; mpls@ietf.org;=0A> >> mpls-chairs@tools.ietf.org= =0A> >> Subject: Re: [mpls] MPLS client layer over an IGP underlying networ= k=0A> >>=0A> >> Network virtualization overlay must be discussed and consen= ted=C2=A0 in NVO3=0A> >> WG.=0A> >>=0A> >> Regards,=0A> >> Shahram=0A> >>= =0A> >>=0A> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" wrote:=0A> >>=0A> >>> Hi Shane,=0A> >>>=0A> >>> I understand operator c= oncern on a new encapsulation to an existing=0A> >> network.=0A> >>>=0A> >>= > However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS=0A> >> = network at all.=0A> >>> MPLS-in-UDP is to enable MPLS client layer to be de= coupled from MPLS=0A> >> server layer and use MPLS client layer as overlay = network and an IGP as=0A> >> a underlying network for transport. Such appli= cation is for DC. You may=0A> >> argue why not use the GRE which is for MPL= S layer over an IGP underling=0A> >> network. We have pointed out in the dr= aft that current routers in DC=0A> >> barely support GRE based load balanci= ng and MPLS-in-GRE are barely used=0A> >> in SP networks too. Most of route= rs in DC perform upd port based load=0A> >> balancing now.=0A> >>>=0A> >>> = >From the architecture perspective, the UDP encapsulation has=0A> >> advanta= ge over GRE encapsulation too. In UDP encapsulation, the frame=0A> >> heade= r decouples the overlay and underlying network clearly, i.e. outer=0A> >> h= eader and overlay header. UDP belongs to outer header, which=0A> >> underly= ing network uses only. However, GRE header has the fields for=0A> >> the ov= erlay network and uses the key field for flow entropy. For load=0A> >> bala= ncing, it requires the underlying network uses GRE header too. In=0A> >> sh= ort, GRE ties the overlay and underlying networks together. Since it=0A> >>= has not used a lot, people are not aware of the disadvantage of such=0A> >= > coupling.=0A> >>>=0A> >>> As the industry moves toward network virtualiza= tion overlay and=0A> >> decouples overlay networks from the underlying netw= ork. A clear=0A> >> separation of overlay header and underlying header is a= "MUST" in my=0A> >> opinion. If we count GRE as the overlay header, then f= or IPv4=0A> >> underlying network, there is no field for the flow entropy. = This is the=0A> >> reason we propose the UDP encapsulation: for an IGP base= d underlying=0A> >> network. In fact, it can support any overlay network be= side MPLS client=0A> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).=0A> >>>=0A> >= >> You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-in-L2TP-=0A> = >> in-UDP schema also provides a overlay (L2TP) and underlying (IP)=0A> >> = network decoupling. L2TP protocol (rfc3931) provides good security=0A> >> m= echanism and has the embedded control function too. Therefore,=0A> someone= =0A> >> can use it for MPLS client layer over Internet. To have MPLS client= =0A> >> layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP is a= =0A> >> overkill and too complex. Here we need a schema to support IGP=0A> = >> underlying transport without touching a overlay header. UDP=0A> >> encap= sulation is the best choice to accomplish that and minimize the=0A> >> chan= ges on existing routers, e.g. change at edge routers, no change on=0A> >> t= ransit routers.=0A> >>>=0A> >>> Regards,=0A> >>> Lucy=0A> >>>=0A> >>>=0A> >= >>=0A> >>>> -----Original Message-----=0A> >>>> From: Xuxiaohu [mailto:xuxi= aohu@huawei.com]=0A> >>>> Sent: Thursday, December 20, 2012 4:14 AM=0A> >>>= > To: Shane Amante=0A> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls= -in-=0A> >> udp@tools.ietf.org;=0A> >>>> mpls@ietf.org; mpls-chairs@tools.i= etf.org=0A> >>>> Subject: Discussion on how to transport MPLS over UDP tunn= els=0A> >>>>=0A> >>>> Hi Shane,=0A> >>>>=0A> >>>> Thanks for your further c= omments and please see my response inline.=0A> >>>>=0A> >>>> Note: I change= d the subject line according to Loa's suggestion.=0A> >>>>=0A> >>>>> -----= =E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> >>>>> =E5=8F=91=E4=BB=B6=E4= =BA=BA: Shane Amante [mailto:shane@castlepoint.net]=0A> >>>>> =E5=8F=91=E9= =80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8819=E6=97=A5 22:38=0A> >>>= >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu=0A> >>>>> =E6=8A=84=E9=80=81: Roge= rs, Josh; Shahram Davari; draft-xu-mpls-in-=0A> >>>> udp@tools.ietf.org;=0A= > >>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org=0A> >>>>> =E4=B8=BB=E9=A2= =98: Re: [mpls] poll to see if we have support to make draft-xu-=0A> >>>> m= pls-in-udp an=0A> >>>>> mpls working group document=0A> >>>>>=0A> >>>>> Xia= ohu,=0A> >>>>>=0A> >>>>> On Dec 18, 2012, at 11:50 PM, Xuxiaohu =0A> wrote:=0A> >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6--= ---=0A> >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Shane Amante [mailto:shane@cas= tlepoint.net]=0A> >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9= =B412=E6=9C=8819=E6=97=A5 11:58=0A> >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ro= gers, Josh=0A> >>>>>>> =E6=8A=84=E9=80=81: Shahram Davari; Xuxiaohu; draft-= xu-mpls-in-=0A> >>>> udp@tools.ietf.org;=0A> >>>>>>> mpls@ietf.org; mpls-ch= airs@tools.ietf.org=0A> >>>>>>> =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see = if we have support to make draft-xu-=0A> >>>> mpls-in-udp=0A> >>>>> an=0A> = >>>>>>> mpls working group document=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>> On = Dec 18, 2012, at 8:50 AM, "Rogers, Josh"=0A> >>>> = =0A> >>>>>>> wrote:=0A> >>>>>>>> I share your SP perspective, and do not se= e the problem this=0A> >>>> solution=0A> >>>>>>>> addresses in practice any= longer.=0A> >>>>>>>=0A> >>>>>>> +1.=C2=A0 Please do not define yet another= MPLS-over-IP encapsulation.=0A> >>>> The=0A> >>>>> IETF=0A> >>>>>>> alread= y standardized MPLS over GRE.=C2=A0 The IETF has also=0A> >>>> standardized= =0A> >>>>> MPLS=0A> >>>>>>> over L2TPv3/UDP/IP, which had seen some deploym= ent in at least=0A> >> one,=0A> >>>> very=0A> >>>>>>> large operator networ= k that I'm aware of to support carriage of=0A> >>>> L3VPN over=0A> >>>>> an= =0A> >>>>>>> IP-only network.=0A> >>>>>>=0A> >>>>>> Hi Shane,=0A> >>>>>>=0A= > >>>>>> Thank you for telling us there are actual deployments of MPLS over= =0A> >>>> IP in at=0A> >>>>> least one, very large operator network. This f= act must be very=0A> >>>> valuable to those=0A> >>>>> people who had believ= ed there is no application of MPLS over IP in=0A> >>>> today's SP=0A> >>>>>= networks.=0A> >>>>>>=0A> >>>>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE= 3 over L2TPv3=0A> >>>>>>> [NOTE: the dates the above were published was bac= k in the 2006=0A> >>>>> timeframe!]=0A> >>>>>>>=C2=A0 RFC 4665 for require= ments related to VPLS that say that VPLS=0A> >>>> may be=0A> >>>>>>> carrie= d over L2TPv3=0A> >>>>>>>=C2=A0 And, here's evidence showing that at least= one vendor has=0A> >>>>> implemented=0A> >>>>>>> IPVPN's over L2TPv3:=0A> = >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html = =0A> >>>>>>=0A> >>>>>> Thanks again for sharing the above information. As m= entioned in=0A> >>>> this draft=0A> >>>>> AND other drafts, the mechanism o= f performing hash calculation on=0A> >> the=0A> >>>> Session=0A> >>>>> ID f= ield in the L2TPv3 header or the Key field in the GRE header as=0A> >>>> de= fined in=0A> >>>>> [RFC 5640] is not widely supported by existing core rout= ers so far.=0A> >>>>>=0A> >>>>> FWIW, I have had success, in the relatively= recent past, in=0A> >>>> requesting a core=0A> >>>>> router vendor to supp= ort changes to the input-keys used in hash=0A> >>>> calculations in=0A> >>>= >> _existing_ hardware, already deployed (extensively) throughout my=0A> >>= >> network.=0A> >>>>> Further, I suspect that most large network operators = are savvy=0A> >> folks=0A> >>>> and=0A> >>>>> understand the internal archi= tecture of their HW fairly well.=C2=A0 As a=0A> >>>> result, those=0A> >>>>= > same operators know what is and is not technically possible in this=0A> >= >>> regard.=0A> >>>>> Thus, it may be a question of "methods" necessary to = convince their=0A> >>>> HW=0A> >>>>> supplier(s) to make appropriate change= s in their equipment to=0A> >> achieve=0A> >>>> their=0A> >>>>> business go= als.=C2=A0 :-)=C2=A0 However, this may not even be necessary ...=0A> >> see= =0A> >>>> below.=0A> >>>>=0A> >>>> Could you please briefly explain how to = make the above change in=0A> >>>> EXISTING hardware of already deployed cor= e routers?=0A> >>>>=0A> >>>>>> In contrast, most existing core routers are = already capable of=0A> >>>> balancing IP=0A> >>>>> traffic flows based on t= he hash of the five-tuple of UDP packets.=0A> >> By=0A> >>>> using the=0A> = >>>>> MPLS-in-UDP encapsulation, the already available load-balancing=0A> >= >>> capability of=0A> >>>>> most existing core routers can be leveraged wit= hout requiring any=0A> >>>> change to=0A> >>>>> them. That is the major mot= ivation of this draft.=0A> >>>>>=0A> >>>>> If this is a concern, then why n= ot encapsulate the traffic in=0A> >>>> MPLS/L2TPv3, which=0A> >>>>> uses UD= P/IP, in the first place?=0A> >>>>=0A> >>>> If I understand it correctly, y= ou prefer to use MPLS-in-L2TPv3-in-=0A> >> UDP=0A> >>>> instead of MPLS-in-= UDP, right?=0A> >>>>=0A> >>>>> IMHO, a better proposal may be to consider a= [minor] (?) change to=0A> >>>> RFC 3931,=0A> >>>>> which would allow the c= onnection used for data packets (not control=0A> >>>> packets)=0A> >>>>> to= use a varying set of source ports (or, source IP addresses),=0A> >> based= =0A> >>>> on a hash=0A> >>>>> calculation, to achieve better load-balancing= over existing=0A> >> equipment=0A> >>>> in an=0A> >>>>> IP-only core.=C2= =A0 L2TP end-system implementations would be better off=0A> >>>> just using= =0A> >>>>> the "Session ID" (and "Cookie") fields as the demultiplexor to= =0A> >>>> associate=0A> >>>>> incoming packets with the associated L2TP Con= trol Channel.=C2=A0 In fact,=0A> >>>> it's not=0A> >>>>> clear to me that e= xisting implementations may /already/ do this,=0A> >>>> making any=0A> >>>>= > "check" on the incoming source port unnecessary for L2TP end-system=0A> >= >>>> implementations.=0A> >>>>>=0A> >>>>> The beauty of the above approach = is:=0A> >>>>> 1) I would think that the above is most likely a change that = is=0A> >>>> limited to the=0A> >>>>> "control channel" (software) of existi= ng L2TP end-system=0A> >>>> implementations.=0A> >>>>> Heck, it may even be= backwards compatible with existing L2TPv3=0A> >>>>> implementations.=C2=A0= (L2TPv3 implementors would need to comment on=0A> >> that).=0A> >>>>=0A> >= >>> IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,=C2=A0 the hardwar= e=0A> >> of=0A> >>>> PE routers needs to be upgraded, e.g., ingress PE rout= ers need to=0A> >> fill=0A> >>>> in an entropy value in the source port fie= ld of UDP headers.=0A> >>>>=0A> >>>>> 2) There is a substantial added secur= ity one gets by using "Session=0A> >>>> ID" and=0A> >>>>> "Cookie" fields t= o ensure the received L2TPv3 packet is intended=0A> >> for=0A> >>>> the=0A>= >>>>> identified session.=C2=A0 Quoting from Section 8.2 of RFC 3931:=0A> = >>>>> ---snip---=0A> >>>>>=C2=A0 L2TPv3 provides traffic separation for its= VPNs via a 32-bit=0A> >>>> Session=0A> >>>>>=C2=A0 ID in the L2TPv3 data h= eader.=C2=A0 When present, the L2TPv3 Cookie=0A> >>>>>=C2=A0 (described in = Section 4.1), provides an additional check to=0A> >> ensure=0A> >>>>>=C2=A0= that an arriving packet is intended for the identified session.=0A> >>>>>= =C2=A0 Thus, use of a Cookie with the Session ID provides an extra=0A> >>>>= guarantee=0A> >>>>>=C2=A0 that the Session ID lookup was performed properl= y and that the=0A> >>>>>=C2=A0 Session ID itself was not corrupted in trans= it.=0A> >>>>> ---snip---=0A> >>>>> ... in regard to this question alone, I = know the Security Area=0A> >> folks=0A> >>>> have, in the=0A> >>>>> past, h= ad /substantial/ concerns about encapsulation of MPLS over=0A> >> IP=0A> >>= >> transport.=0A> >>>>> In fact, this is why you see text in Section 7.6, "= Security", of=0A> >> RFC=0A> >>>> 4665.=0A> >>>>> (There's likely similar l= anguage in other drafts that use MPLS for=0A> >>>> transport).=0A> >>>>> Wh= ile I'm not sure that Security Area folks pay much attention to=0A> >>>> da= ily traffic on=0A> >>>>> the MPLS WG mailing list, I'm fairly confident thi= s concern will=0A> >>>> arise if/when this=0A> >>>>> draft goes to the IESG= ...=0A> >>>>=0A> >>>> If I understand it correctly, the reason for your pr= eference of=0A> >> MPLS-=0A> >>>> in-L2TPv3-in-UDP is that it has an added = security feature. If that=0A> >> is=0A> >>>> so concerned, can you explain = why MPLS-in-GRE is far more popular=0A> >> than=0A> >>>> MPLS-in-L2TP in pr= actice?=0A> >>>>=0A> >>>> Best regards,=0A> >>>> Xiaohu=0A> >>>>=0A> >>>>> = 3) Finally, this approach only affects the end-systems that=0A> >> implemen= t=0A> >>>> L2TP, for=0A> >>>>> tunneling of MPLS/IP, and does not require a= n entire industry to=0A> >>>> support=0A> >>>>> MPLS/UDP encapsulation in t= heir product lines.=0A> >>>>>=0A> >>>>> -shane=0A> >>>>>=0A> >>>>>=0A> >>>>= >>=0A> >>>>>> Best regards,=0A> >>>>>> Xiaohu=0A> >>>>>>=0A> >>>>>>> If the= re was market demand for MPLS over IP, then clearly it=0A> >> would=0A> >>>= > have=0A> >>>>> been=0A> >>>>>>> more widely implemented by equipment vend= ors, with either MPLS=0A> >>>> over=0A> >>>>> GRE or=0A> >>>>>>> MPLS over = L2TPv3.=C2=A0 (Where there's a will, there's a way).=C2=A0 I=0A> >> would= =0A> >>>> note=0A> >>>>> that=0A> >>>>>>> the most likely reasons this did = not pan out was there are=0A> >> several,=0A> >>>> practical=0A> >>>>>>> op= erational benefits one gets from going with native MPLS=0A> >>>>>>> encapsu= lation/switching within the data plane, namely:=0A> >>>>>>> - MPLS Fast Re-= Route=0A> >>>>>>> - MPLS Traffic Engineering=0A> >>>>>>> ... to name, but a= few.=C2=A0 Those have tended to be quite compelling=0A> >>>>> arguments=0A= > >>>>>>> to 'upgrade' network HW to support MPLS encapsulation/switching.= =0A> >>>>>>>=0A> >>>>>>> -shane=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>>> -Josh= =0A> >>>>>>>>=0A> >>>>>>>>=0A> >>>>>>>> On 12/18/12 12:31 AM, "Shahram Dava= ri" =0A> >>>>> wrote:=0A> >>>>>>>>=0A> >>>>>>>>> For s= ervice provider domain, MPLS over IP is legacy and there=0A> >> is=0A> >>>>= no need=0A> >>>>>>>>> to improve it.=0A> >>>>>>>>>=0A> >>>>>>>>> Regards,= =0A> >>>>>>>>> Shahram=0A> >>>>>>>>>=0A> >>>>>>>>>=0A> >>>>>>>>> On Dec 17,= 2012, at 8:02 PM, "Xuxiaohu" =0A> >>>>> wrote:=0A> >>= >>>>>>>=0A> >>>>>>>>>> Shahram,=0A> >>>>>>>>>>=0A> >>>>>>>>>> This draft is= ONLY intended to provide a MPLS-over-IP=0A> >>>> encapsulation=0A> >>>>>>>= >>> method with a better load-balancing applicability so far to=0A> >>>> th= ose=0A> >>>>>>>>>> operators who happen to require transporting MPLS applic= ation=0A> >>>> traffic=0A> >>>>>>>>>> across IP networks. I believe MPLS-ba= sed VPN over IP, NVGRE=0A> >> and=0A> >>>>> VXLAN=0A> >>>>>>>>>> each have = their own advocators and use cases. If you=0A> >> absolutely=0A> >>>> belie= ve=0A> >>>>>>>>>> it's meaningless of transporting MPLS application traffic= =0A> >>>> across IP=0A> >>>>>>>>>> networks and therefore those existing RF= Cs related to MPLS=0A> >> over=0A> >>>> IP=0A> >>>>>>>>>> tunneling mechani= sms should be moved to Historic status,=0A> >> please=0A> >>>> say=0A> >>>>= > so.=0A> >>>>>>>>>>=0A> >>>>>>>>>> By the way, it seems this=0A> >>>>>>>>>= > (http://www.ietf.org/mail- =0A> >>>> archive/web/nvo3/current/msg01864.ht= ml) is=0A> >>>>>>>>>> just the right thread suitable for you to make the fo= llowing=0A> >>>> argument=0A> >>>>>>>>>> (i.e., whether or not MPLS-based V= PN is applicable to data=0A> >>>> centers). I=0A> >>>>>>>>>> had thought yo= u would speak up at that time. Sadly,=0A> >>>> surprisingly silent=0A> >>>>= >>>>>> till now.=0A> >>>>>>>>>>=0A> >>>>>>>>>> Sigh, I didn't intend to say= the above otherwise.=0A> >>>>>>>>>>=0A> >>>>>>>>>> Xiaohu=0A> >>>>>>>>>>= =0A> >>>>>>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> >>>>>>>= >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls-bounces@ietf.org [mailto:mpls-bounce= s@ietf.org]=0A> >> =E4=BB=A3=0A> >>>> =E8=A1=A8=0A> >>>>>>> S.=0A> >>>>>>>>= >>> Davari=0A> >>>>>>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9= =B412=E6=9C=8815=E6=97=A5 13:34=0A> >>>>>>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA= : Loa Andersson=0A> >>>>>>>>>>> =E6=8A=84=E9=80=81: draft-xu-mpls-in-udp@to= ols.ietf.org; mpls@ietf.org;=0A> >>>>>>>>>>> mpls-chairs@tools.ietf.org=0A>= >>>>>>>>>>> =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see if we have support = to make=0A> >>>>>>>>>>> draft-xu-mpls-in-udp an=0A> >>>>>>>>>>> mpls workin= g group document=0A> >>>>>>>>>>>=0A> >>>>>>>>>>> I don't support this draft= since it has no application in=0A> >>>> today's=0A> >>>>>>>>>>> modern met= ro=0A> >>>>>>>>>>> and core, where MPLS is dominant, and its only practical= =0A> >>>> application=0A> >>>>>>>>>>> in in data=0A> >>>>>>>>>>> center, wh= ich already is crowded with other solutions such as=0A> >>>> NVGRE=0A> >>>>= > and=0A> >>>>>>>>>>> VXLAN.=0A> >>>>>>>>>>>=0A> >>>>>>>>>>> It seems the a= uthors are trying to bypass the NVO3 solution=0A> >>>> selection=0A> >>>>>>= >>>>> process=0A> >>>>>>>>>>> by advancing the draft in MPLS WG.=0A> >>>>>>= >>>>>=0A> >>>>>>>>>>> Regards,=0A> >>>>>>>>>>> Shahram=0A> >>>>>>>>>>>=0A> = >>>>>>>>>>>=0A> >>>>>>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote:=0A> >>>>>>>>>>>=0A> >>>>>>>>>>>> Working group,=0A> >>>>>>>>= >>>>=0A> >>>>>>>>>>>> This is to start a "two week" poll on adopting=0A> >>= >>>>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document.=0A> >= >>>>>>>>>>> Due to the holiday season this poll has been extended with=0A> = >>>> one week.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> Please send your comments = (support/not support) to the mpls=0A> >>>>> working=0A> >>>>>>>>>>>> group = mailing list (mpls at ietf.org). Please give an=0A> >>>> technical=0A> >>>>= >>>>>>>> motivation for your support/not support, especially if you=0A> >>>= > think that=0A> >>>>>>>>>>>> the document should not be adopted as a worki= ng group=0A> >>>> document.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> This poll end= s January 07, 2013.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> There is one IPR clai= m against this document -=0A> >>>>>>>>>>>> https://datatracker.ietf.org/ipr= /1941/ .=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> All the active co-authors has st= ated on the working group=0A> >>>> mailing list=0A> >>>>>>>>>>>> that they = are not aware of any other IPR claims than those=0A> >>>> already=0A> >>>>>= >>>>>>> disclosed.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> However, up to version= -03 (the document that we used for=0A> >> the=0A> >>>> IPR=0A> >>>>>>>>>>>= > poll)=0A> >>>>>>>>>>>> Marshall Eubanks was listed as one of the authors.= Marshall=0A> >>>> has=0A> >>>>>>>>>>>> discontinued all interactions with = the IETF, including the=0A> >>>> author team=0A> >>>>>>>>>>>> of draft-xu-m= pls-in-udp-06. The working group chairs has=0A> >>>> tried to=0A> >>>>>>>>>= >>> contact Marshall by other means, to try get a response on=0A> >> the=0A= > >>>> IPR=0A> >>>>>>>>>>>> poll.=0A> >>>>>>>>>>>> We have had no success i= n this.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> From version -04 the authors deci= ded to remove Marshall as a=0A> >>>>>>>>>>>> co-author.=0A> >>>>>>>>>>>>=0A= > >>>>>>>>>>>> /Loa=0A> >>>>>>>>>>>> (mpls wg co-chair)=0A> >>>>>>>>>>>> --= =0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> Loa Andersson=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = email:=0A> >>>>>>>>>>> loa.andersson@ericsson.com=0A> >>>>>>>>>>>> Sr Strat= egy and Standards Manager=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.n= u=0A> >>>>>>>>>>>> Ericsson Inc=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 phone: +46 10 717=0A> 52= =0A> >> 13=0A> >>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 +46 767 72 92=0A> 13=0A> >>>>>>>>>>>> ___________________= ____________________________=0A> >>>>>>>>>>>> mpls mailing list=0A> >>>>>>>= >>>>> mpls@ietf.org=0A> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/= mpls =0A> >>>>>>>>>>> _______________________________________________=0A> >= >>>>>>>>>> mpls mailing list=0A> >>>>>>>>>>> mpls@ietf.org=0A> >>>>>>>>>>> = https://www.ietf.org/mailman/listinfo/mpls =0A> >>>>>>>>>> ________________= _______________________________=0A> >>>>>>>>>> mpls mailing list=0A> >>>>>>= >>>> mpls@ietf.org=0A> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpl= s =0A> >>>>>>>>> _______________________________________________=0A> >>>>>>= >>> mpls mailing list=0A> >>>>>>>>> mpls@ietf.org=0A> >>>>>>>>> https://www= .ietf.org/mailman/listinfo/mpls =0A> >>>>>>>>=0A> >>>>>>>>=0A> >>>>>>>> Thi= s E-mail and any of its attachments may contain Time Warner=0A> >>>> Cable= =0A> >>>>>>> proprietary information, which is privileged, confidential, or= =0A> >>>> subject to=0A> >>>>>>> copyright belonging to Time Warner Cable. = This E-mail is intended=0A> >>>> solely for=0A> >>>>> the=0A> >>>>>>> use o= f the individual or entity to which it is addressed. If you=0A> >>>> are no= t the=0A> >>>>>>> intended recipient of this E-mail, you are hereby notifie= d that=0A> >>>> any=0A> >>>>> dissemination,=0A> >>>>>>> distribution, copy= ing, or action taken in relation to the=0A> >> contents=0A> >>>> of and=0A>= >>>>>>> attachments to this E-mail is strictly prohibited and may be=0A> >= >>> unlawful. If you=0A> >>>>>>> have received this E-mail in error, please= notify the sender=0A> >>>> immediately and=0A> >>>>>>> permanently delete = the original and any copy of this E-mail and=0A> >>>> any printout.=0A> >>>= >>>>> _______________________________________________=0A> >>>>>>>> mpls mai= ling list=0A> >>>>>>>> mpls@ietf.org=0A> >>>>>>>> https://www.ietf.org/mail= man/listinfo/mpls =0A> >>>=0A> >>> ________________________________________= _______=0A> >>> mpls mailing list=0A> >>> mpls@ietf.org=0A> >>> https://www= .ietf.org/mailman/listinfo/mpls =0A> ______________________________________= _________=0A> mpls mailing list=0A> mpls@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/mpls =0A_______________________________________________=0A= mpls mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/m= pls ---1314897756-30534226-1356077403=:99620 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think we= are in a vicious cycle. Could you please clarify which network operator is= asking for MPLS over UDP and what is the application.  Also how do yo= u plan to address the MPLS Multicast (which is probably more important than= improving the load balancing), given that RFC4023 does not support Multica= st.

Thanks,
Shahram


From: X= uxiaohu <xuxiaohu@huawei.com>
To: Shahram Davari <davari@broadcom.com>; Lucy yong <lucy.yong@huawei.com>
Cc:= "draft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@= tools.ietf.org>; "mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@too= ls.ietf.org" <mpls-chairs@tools.ietf.org>
Sent: Thursday, December 20, 2012 5:56:23 PM
= Subject: Re: [mpls] MPLS = client layer over an IGP underlying network



= > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB= =B6=E4=BA=BA: mpls-bounces@ietf.org [mailto:mpls-bounces@= ietf.org] =E4=BB=A3=E8=A1=A8
> Shahram Davari
> =E5=8F=91= =E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8821=E6=97=A5 1:31
&g= t; =E6=94=B6=E4=BB=B6=E4=BA=BA: Lucy yong
> =E6=8A=84=E9=80=81: draft-xu-mpls-in-udp@t= ools.ietf.org; mpls-chairs@tools.ietf.org;
>= mpls@iet= f.org
> =E4=B8=BB=E9=A2=98: Re: [mpls] MPLS client layer over an = IGP underlying network
>
> Please don't mix up things. The MPL= S protocol design I agree must be done by
> MPLS WG. But the question= is whether your proposal meets the network
> virtualization requirem= ents.

Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS = over IP encapsulation mechanisms have been discussed before?

Since M= PLS-in-UDP is just intended to be used in the scenarios where MPLS-in-GRE/I= P has been used and is to be used, MPLS-in-UDP should be discussed in the s= ame WG where MPLS-in-GRE/IP has been discussed.

Xiaohu

> T= he NVO3 task is to document the issues, requirements and framework for
> NvO3. Then = if MPLS over IP looks like a suitable solution that meets the
> requi= rements such as the scale, mobility, etc, then they will ask MPLS WG for> protocol design.
>
> So before proceeding this draft, I = think you should take it to NVO3 WG and
> convince them this solution= meets their requirements and framework.
>
> We don't want IET= F do design N number of solutions for the same problem, do
> we?
&= gt;
> -Shahram
>
>
>
> Regards,
> S= hahram
>
>
> On Dec 20, 2012, at 8:56 AM, "Lucy yong" &= lt;lucy.yong@huawei.com> wrote:
>
> > Network v= irtualization overlay is discussed under nvo3 WG. This does not
> mea= n that nvo3 WG has to design a new protocol for a underlying network or a
> new protocol for a overlay network. In fact, people there aim on= leverage
> standard network protocols to accomplish them. IMO: these= expansions on an
> existing standard protocol have to be worked out = in the protocol WG group, it
> should not give nvo3 WG free right to = enhance these protocols. For a brand
> new protocol for network virtu= alization overlay, nvo3 WG may be the place to
> start.
> ><= br>> > Lucy
> >
> >> -----Original Message-----<= br>> >> From: Shahram Davari [mailto:davari@broadcom.com]> >> Sent: Thursday, December 20, 2012 10:34 AM
> >>= To: Lucy yong
> >> Cc: Shane Amante; draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.o= rg;
> >> mpls-chairs@tools.ietf.org> >> Subject: Re: [mpls] MPLS client layer over an IGP underlying= network
> >>
> >> Network virtualization overlay m= ust be discussed and consented  in NVO3
> >> WG.
> &= gt;>
> >> Regards,
> >> Shahram
> >>=
> >>
> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong"= <lucy.yong@huawei.com> wrote:
> >>
> >= >> Hi Shane,
> >>>
> >>> I understand o= perator concern on a new encapsulation to an existing
> >> netw= ork.
> >>>
> >>> However, MPLS-in-UDP does no= t aim on changing existing SP IP/MPLS
> >> network at all.
> &= gt;>> MPLS-in-UDP is to enable MPLS client layer to be decoupled from= MPLS
> >> server layer and use MPLS client layer as overlay ne= twork and an IGP as
> >> a underlying network for transport. Su= ch application is for DC. You may
> >> argue why not use the GR= E which is for MPLS layer over an IGP underling
> >> network. W= e have pointed out in the draft that current routers in DC
> >>= barely support GRE based load balancing and MPLS-in-GRE are barely used> >> in SP networks too. Most of routers in DC perform upd port b= ased load
> >> balancing now.
> >>>
> >= >> From the architecture perspective, the UDP encapsulation has
&g= t; >> advantage over GRE encapsulation too. In UDP encapsulation, the= frame
> >> header decouples the overlay and underlying network clearly, i.e. outer
> >> header and overlay header. UD= P belongs to outer header, which
> >> underlying network uses o= nly. However, GRE header has the fields for
> >> the overlay ne= twork and uses the key field for flow entropy. For load
> >> ba= lancing, it requires the underlying network uses GRE header too. In
>= >> short, GRE ties the overlay and underlying networks together. Sin= ce it
> >> has not used a lot, people are not aware of the disa= dvantage of such
> >> coupling.
> >>>
> &g= t;>> As the industry moves toward network virtualization overlay and<= br>> >> decouples overlay networks from the underlying network. A = clear
> >> separation of overlay header and underlying header i= s a "MUST" in my
> >> opinion. If we count GRE as the overlay h= eader, then for IPv4
> >> underlying network, there is no field for the flow entropy. This is the
> >> reason we prop= ose the UDP encapsulation: for an IGP based underlying
> >> net= work. In fact, it can support any overlay network beside MPLS client
>= ; >> layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >>>
&g= t; >>> You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-= in-L2TP-
> >> in-UDP schema also provides a overlay (L2TP) and = underlying (IP)
> >> network decoupling. L2TP protocol (rfc3931= ) provides good security
> >> mechanism and has the embedded co= ntrol function too. Therefore,
> someone
> >> can use it = for MPLS client layer over Internet. To have MPLS client
> >> l= ayer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP is a
> &= gt;> overkill and too complex. Here we need a schema to support IGP
&= gt; >> underlying transport without touching a overlay header. UDP
> >> encapsulation is the best choice to accomplish that a= nd minimize the
> >> changes on existing routers, e.g. change a= t edge routers, no change on
> >> transit routers.
> >= >>
> >>> Regards,
> >>> Lucy
> &g= t;>>
> >>>
> >>>
> >>>&g= t; -----Original Message-----
> >>>> From: Xuxiaohu [mail= to:xuxiaohu@huawei.com]
> >>>> Sent: Thursday, Dec= ember 20, 2012 4:14 AM
> >>>> To: Shane Amante
> &g= t;>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> = >> udp@tools.ietf.org;
> >>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>> Subj= ect: Discussion on how to transport MPLS over UDP tunnels
> >>&= gt;>
> >>>> Hi Shane,
> >>>>
>= >>>> Thanks for your further comments and please see my respon= se inline.
> >>>>
> >>>> Note: I change= d the subject line according to Loa's suggestion.
> >>>><= br>> >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=
> >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Shane Amante [ma= ilto:shane@castlepoint.net]
> >>>>> =E5=8F= =91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8819=E6=97=A5 22:38> >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu
> &= gt;>>>> =E6=8A=84=E9=80=81: Rogers, Josh; Shahram Davari; draft= -xu-mpls-in-
> >>>> u= dp@tools.ietf.org;
> >>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>>> =E4=B8=BB= =E9=A2=98: Re: [mpls] poll to see if we have support to make draft-xu-
&= gt; >>>> mpls-in-udp an
> >>>>> mpls worki= ng group document
> >>>>>
> >>>>>= Xiaohu,
> >>>>>
> >>>>> On Dec 1= 8, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com>
> w= rote:
> >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB= =B6-----
> >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: = Shane Amante [mailto:shane@castlepoint.net]
> &= gt;>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5= =B9=B412=E6=9C=8819=E6=97=A5 11:58
> >>>>>>> =E6= =94=B6=E4=BB=B6=E4=BA=BA: Rogers, Josh
> >>>>>>>= =E6=8A=84=E9=80=81: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-
> &g= t;>>> udp@tools.ietf.org;
> >>>>>>>= ; mpls@ie= tf.org; mpls-chairs@tools.ietf.org
> >>= ;>>>>> =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see if we have= support to make draft-xu-
> >>>> mpls-in-udp
> >= ;>>>> an
> >>>>>>> mpls working grou= p document
> >>>>>>>
> >>>>>= ;>>
> >>>>>>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh"> >>>> <josh.rogers@twcable.com>
&= gt; >>>>>>> wrote:
> >>>>>>>= ;> I share your SP perspective, and do not see the problem this
> = >>>> solution
> >>>>>>>> addresse= s in practice any longer.
> >>>>>>>
> >= >>>>>> +1.  Please do not define yet another MPLS-ov= er-IP encapsulation.
> >>>> The
> >>>>&= gt; IETF
> >>>>>>> already standardized MPLS ove= r GRE.  The IETF has also
> >>>> standardized
>= ; >>>>> MPLS
> >>>>>>> over L2TPv= 3/UDP/IP, which had seen some deployment in at least
> >> one,
> >>>> very
> >>>>>>> la= rge operator network that I'm aware of to support carriage of
> >&= gt;>> L3VPN over
> >>>>> an
> >>>= >>>> IP-only network.
> >>>>>>
> = >>>>>> Hi Shane,
> >>>>>>
>= >>>>>> Thank you for telling us there are actual deploym= ents of MPLS over
> >>>> IP in at
> >>>>= ;> least one, very large operator network. This fact must be very
>= ; >>>> valuable to those
> >>>>> people wh= o had believed there is no application of MPLS over IP in
> >>&= gt;> today's SP
> >>>>> networks.
> >>&= gt;>>>
> >>>>>>> See: RFC's 4454, 4719,= 4591, 4349 for PWE3 over L2TPv3
> >>>>>>> [NOTE: the dates the above were published was= back in the 2006
> >>>>> timeframe!]
> >>= >>>>>  RFC 4665 for requirements related to VPLS that = say that VPLS
> >>>> may be
> >>>>>&= gt;> carried over L2TPv3
> >>>>>>>  And= , here's evidence showing that at least one vendor has
> >>>= >> implemented
> >>>>>>> IPVPN's over L2TP= v3:
> >> http://www.cisco.com/en/US/do= cs/ios/12_0s/feature/guide/csgl3vpn.html=0A
> >>>>>= ;>
> >>>>>> Thanks again for sharing the above i= nformation. As mentioned in
> >>>> this draft
> >= ;>>>> AND other drafts, the mechanism of performing hash calcul= ation on
> >> the
> >>>> Session
> >= >>>> ID field in the L2TPv3 header or the Key field in the GRE = header as
> >>>> defined in
> >>>>> = [RFC 5640] is not widely supported by existing core routers so far.
>= >>>>>
> >>>>> FWIW, I have had success= , in the relatively recent past, in
> >>>> requesting a c= ore
> >>>>> router vendor to support changes to the in= put-keys used in hash
> >>>> calculations in
> >= >>>> _existing_ hardware, already deployed (extensively) throug= hout my
> >>>> network.
> >>>>> Further, I suspect that most large n= etwork operators are savvy
> >> folks
> >>>> = and
> >>>>> understand the internal architecture of th= eir HW fairly well.  As a
> >>>> result, those
&g= t; >>>>> same operators know what is and is not technically = possible in this
> >>>> regard.
> >>>>&= gt; Thus, it may be a question of "methods" necessary to convince their
= > >>>> HW
> >>>>> supplier(s) to make a= ppropriate changes in their equipment to
> >> achieve
> &= gt;>>> their
> >>>>> business goals.  :-= )  However, this may not even be necessary ...
> >> see> >>>> below.
> >>>>
> >>>= > Could you please briefly explain how to make the above change in
> >>>> EXISTING hardware of already deployed core rou= ters?
> >>>>
> >>>>>> In contrast= , most existing core routers are already capable of
> >>>>= ; balancing IP
> >>>>> traffic flows based on the hash= of the five-tuple of UDP packets.
> >> By
> >>>= > using the
> >>>>> MPLS-in-UDP encapsulation, the = already available load-balancing
> >>>> capability of
= > >>>>> most existing core routers can be leveraged witho= ut requiring any
> >>>> change to
> >>>>= ;> them. That is the major motivation of this draft.
> >>>= ;>>
> >>>>> If this is a concern, then why not e= ncapsulate the traffic in
> >>>> MPLS/L2TPv3, which
&g= t; >>>>> uses UDP/IP, in the first place?
> >>>>
> >>>> If I understand it correctly, yo= u prefer to use MPLS-in-L2TPv3-in-
> >> UDP
> >>>= ;> instead of MPLS-in-UDP, right?
> >>>>
> >&= gt;>>> IMHO, a better proposal may be to consider a [minor] (?) ch= ange to
> >>>> RFC 3931,
> >>>>> whi= ch would allow the connection used for data packets (not control
> &g= t;>>> packets)
> >>>>> to use a varying set o= f source ports (or, source IP addresses),
> >> based
> &g= t;>>> on a hash
> >>>>> calculation, to achie= ve better load-balancing over existing
> >> equipment
> &= gt;>>> in an
> >>>>> IP-only core.  L2TP= end-system implementations would be better off
> >>>> ju= st using
> >>>>> the "Session ID" (and "Cookie") fields as the demultiplexor to
> >>>> associat= e
> >>>>> incoming packets with the associated L2TP Co= ntrol Channel.  In fact,
> >>>> it's not
> >= ;>>>> clear to me that existing implementations may /already/ d= o this,
> >>>> making any
> >>>>> "c= heck" on the incoming source port unnecessary for L2TP end-system
> &= gt;>>>> implementations.
> >>>>>
> &= gt;>>>> The beauty of the above approach is:
> >>&g= t;>> 1) I would think that the above is most likely a change that is<= br>> >>>> limited to the
> >>>>> "contr= ol channel" (software) of existing L2TP end-system
> >>>>= implementations.
> >>>>> Heck, it may even be backwar= ds compatible with existing L2TPv3
> >>>>> implementations.  (L2TPv3 implementors would need to comment on
&g= t; >> that).
> >>>>
> >>>> IMHO, = no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,  the hardware
> = >> of
> >>>> PE routers needs to be upgraded, e.g.,= ingress PE routers need to
> >> fill
> >>>> = in an entropy value in the source port field of UDP headers.
> >&g= t;>>
> >>>>> 2) There is a substantial added sec= urity one gets by using "Session
> >>>> ID" and
> &= gt;>>>> "Cookie" fields to ensure the received L2TPv3 packet is= intended
> >> for
> >>>> the
> >>= ;>>> identified session.  Quoting from Section 8.2 of RFC 393= 1:
> >>>>> ---snip---
> >>>>>&nbs= p; L2TPv3 provides traffic separation for its VPNs via a 32-bit
> >>>> Session
> >>>>> = ID in the L2TPv3 data header.  When present, the L2TPv3 Cookie
>= ; >>>>>  (described in Section 4.1), provides an additi= onal check to
> >> ensure
> >>>>>  th= at an arriving packet is intended for the identified session.
> >&= gt;>>>  Thus, use of a Cookie with the Session ID provides an= extra
> >>>> guarantee
> >>>>> = ; that the Session ID lookup was performed properly and that the
> &g= t;>>>>  Session ID itself was not corrupted in transit.> >>>>> ---snip---
> >>>>> ... in r= egard to this question alone, I know the Security Area
> >> fol= ks
> >>>> have, in the
> >>>>> past,= had /substantial/ concerns about encapsulation of MPLS over
> >> IP
> >>>> transport.
> >>>>&g= t; In fact, this is why you see text in Section 7.6, "Security", of
>= >> RFC
> >>>> 4665.
> >>>>> (= There's likely similar language in other drafts that use MPLS for
> &= gt;>>> transport).
> >>>>> While I'm not sure= that Security Area folks pay much attention to
> >>>> da= ily traffic on
> >>>>> the MPLS WG mailing list, I'm f= airly confident this concern will
> >>>> arise if/when th= is
> >>>>> draft goes to the IESG ...
> >>= >>
> >>>> If I understand it correctly, the reason = for your preference of
> >> MPLS-
> >>>> in-L= 2TPv3-in-UDP is that it has an added security feature. If that
> >= > is
> >>>> so concerned, can you explain why MPLS-in-GRE is far more popular
> >> than
> >>>= > MPLS-in-L2TP in practice?
> >>>>
> >>>= ;> Best regards,
> >>>> Xiaohu
> >>>>= ;
> >>>>> 3) Finally, this approach only affects the e= nd-systems that
> >> implement
> >>>> L2TP, f= or
> >>>>> tunneling of MPLS/IP, and does not require = an entire industry to
> >>>> support
> >>>= >> MPLS/UDP encapsulation in their product lines.
> >>>= ;>>
> >>>>> -shane
> >>>>><= br>> >>>>>
> >>>>>>
> >&= gt;>>>> Best regards,
> >>>>>> Xiaohu> >>>>>>
> >>>>>>> If the= re was market demand for MPLS over IP, then clearly it
> >> would
> >>>> have
> >>>>> = been
> >>>>>>> more widely implemented by equipm= ent vendors, with either MPLS
> >>>> over
> >>= ;>>> GRE or
> >>>>>>> MPLS over L2TPv3.=   (Where there's a will, there's a way).  I
> >> woul= d
> >>>> note
> >>>>> that
> &= gt;>>>>>> the most likely reasons this did not pan out wa= s there are
> >> several,
> >>>> practical> >>>>>>> operational benefits one gets from going= with native MPLS
> >>>>>>> encapsulation/switch= ing within the data plane, namely:
> >>>>>>> - M= PLS Fast Re-Route
> >>>>>>> - MPLS Traffic Engin= eering
> >>>>>>> ... to name, but a few.  Those have tended to be quite compelling
> >>>&g= t;> arguments
> >>>>>>> to 'upgrade' network = HW to support MPLS encapsulation/switching.
> >>>>>>= ;>
> >>>>>>> -shane
> >>>>&= gt;>>
> >>>>>>>
> >>>>&g= t;>>> -Josh
> >>>>>>>>
> >&= gt;>>>>>>
> >>>>>>>> On 12/= 18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com>
>= >>>>> wrote:
> >>>>>>>>
&g= t; >>>>>>>>> For service provider domain, MPLS o= ver IP is legacy and there
> >> is
> >>>> no = need
> >>>>>>>>> to improve it.
> >>>>>>>>>
> >>>>>>>&= gt;> Regards,
> >>>>>>>>> Shahram
&g= t; >>>>>>>>>
> >>>>>>>= ;>>
> >>>>>>>>> On Dec 17, 2012, at = 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com>
> >>>= >> wrote:
> >>>>>>>>>
> >&g= t;>>>>>>>> Shahram,
> >>>>>>= ;>>>>
> >>>>>>>>>> This dra= ft is ONLY intended to provide a MPLS-over-IP
> >>>> enca= psulation
> >>>>>>>>>> method with a be= tter load-balancing applicability so far to
> >>>> those<= br>> >>>>>>>>>> operators who happen to require transporting MPLS application
> >>>> traffic
= > >>>>>>>>>> across IP networks. I believe= MPLS-based VPN over IP, NVGRE
> >> and
> >>>>= ;> VXLAN
> >>>>>>>>>> each have thei= r own advocators and use cases. If you
> >> absolutely
> = >>>> believe
> >>>>>>>>>> i= t's meaningless of transporting MPLS application traffic
> >>&g= t;> across IP
> >>>>>>>>>> networks = and therefore those existing RFCs related to MPLS
> >> over
= > >>>> IP
> >>>>>>>>>> t= unneling mechanisms should be moved to Historic status,
> >> pl= ease
> >>>> say
> >>>>> so.
> = >>>>>>>>>>
> >>>>>>>>>> By the way, it seems this
>= >>>>>>>>>> (http://www.ietf.org/mail-=0A
> >>&g= t;> archive/web/nvo3/current/msg01864.html) is
> >>>>&= gt;>>>>> just the right thread suitable for you to make the = following
> >>>> argument
> >>>>>>= ;>>>> (i.e., whether or not MPLS-based VPN is applicable to dat= a
> >>>> centers). I
> >>>>>>>= >>> had thought you would speak up at that time. Sadly,
> &g= t;>>> surprisingly silent
> >>>>>>>>= >> till now.
> >>>>>>>>>>
>= >>>>>>>>>> Sigh, I didn't intend to say the = above otherwise.
> >>>>>>>>>>
> &= gt;>>>>>>>>> Xiaohu
> >>>>>= >>>>>
> >>>>>>>>>>> -= ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> >>>>>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]<= br>> >> =E4=BB=A3
> >>>> =E8=A1=A8
> >&= gt;>>>>> S.
> >>>>>>>>>>= > Davari
> >>>>>>>>>>> =E5=8F=91= =E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8815=E6=97=A5 13:34
&= gt; >>>>>>>>>>> =E6=94=B6=E4=BB=B6=E4=BA= =BA: Loa Andersson
> >>>>>>>>>>> =E6= =8A=84=E9=80=81: draft-xu-mpls-in-udp@to= ols.ietf.org; mpls@ietf.org;
> >>>>>>>>>>= ;> mpls-chairs@tools.ietf.org
> >>>>>&= gt;>>>>> =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see if we ha= ve support to make
> >>>>>>>>>>> dra= ft-xu-mpls-in-udp an
> >>>>>>>>>>> m= pls working group document
> >>>>>>>>>>= >
> >>>>>>>>>>> I don't support t= his draft since it has no application in
> >>>> today's> >>>>>>>>>>> modern metro
> &g= t;>>>>>>>>>> and core, where MPLS is dominant= , and its only practical
> >>>> application
> >&= gt;>>>>>>>>> in in data
> >>>>= >>>>>>> center, which already is crowded with other so= lutions such as
> >>>> NVGRE
> >>>>> and> >>>>>>>>>>> VXLAN.
> >>&= gt;>>>>>>>>
> >>>>>>>>= ;>>> It seems the authors are trying to bypass the NVO3 solution> >>>> selection
> >>>>>>>>&= gt;>> process
> >>>>>>>>>>> by= advancing the draft in MPLS WG.
> >>>>>>>>&g= t;>>
> >>>>>>>>>>> Regards,> >>>>>>>>>>> Shahram
> >>= >>>>>>>>>
> >>>>>>>&g= t;>>>
> >>>>>>>>>>> On Dec = 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
> >>>>>>>>>>>
> >>>>>&= gt;>>>>>> Working group,
> >>>>>>= >>>>>>
> >>>>>>>>>>&g= t;> This is to start a "two week" poll on adopting
> >>>&= gt;>>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS work= ing group document.
> >>>>>>>>>>>>= ; Due to the holiday season this poll has been extended with
> >&g= t;>> one week.
> >>>>>>>>>>>&g= t;
> >>>>>>>>>>>> Please send you= r comments (support/not support) to the mpls
> >>>>> w= orking
> >>>>>>>>>>>> group maili= ng list (mpls at ietf.org). Please give an
> >>>> technic= al
> >>>>>>>>>>>> motivation for your support/not support, especially if you
> >>= ;>> think that
> >>>>>>>>>>>&g= t; the document should not be adopted as a working group
> >>&g= t;> document.
> >>>>>>>>>>>>> >>>>>>>>>>>> This poll ends Janu= ary 07, 2013.
> >>>>>>>>>>>>
&= gt; >>>>>>>>>>>> There is one IPR claim= against this document -
> >>>>>>>>>>&g= t;> https://datatracker.ietf.org/ipr/1941/ .
> >>>>>&= gt;>>>>>>
> >>>>>>>>>>= ;>> All the active co-authors has stated on the working group
>= >>>> mailing list
> >>>>>>>>>>>> that they are not aware o= f any other IPR claims than those
> >>>> already
> = >>>>>>>>>>>> disclosed.
> >>= ;>>>>>>>>>>
> >>>>>>&= gt;>>>>> However, up to version -03 (the document that we us= ed for
> >> the
> >>>> IPR
> >>&g= t;>>>>>>>>> poll)
> >>>>>&g= t;>>>>>> Marshall Eubanks was listed as one of the author= s. Marshall
> >>>> has
> >>>>>>&g= t;>>>>> discontinued all interactions with the IETF, includi= ng the
> >>>> author team
> >>>>>>= ;>>>>>> of draft-xu-mpls-in-udp-06. The working group cha= irs has
> >>>> tried to
> >>>>>>>>>>>> contact Marshall by other= means, to try get a response on
> >> the
> >>>&= gt; IPR
> >>>>>>>>>>>> poll.
&= gt; >>>>>>>>>>>> We have had no success= in this.
> >>>>>>>>>>>>
> = >>>>>>>>>>>> From version -04 the autho= rs decided to remove Marshall as a
> >>>>>>>>= >>>> co-author.
> >>>>>>>>>>= ;>>
> >>>>>>>>>>>> /Loa
= > >>>>>>>>>>>> (mpls wg co-chair)> >>>>>>>>>>>> --
> >>&= gt;>>>>>>>>>
> >>>>>>>= ;>>>>>
> >>>>>>>>>>>> Loa Andersson   = ;                     em= ail:
> >>>>>>>>>>> = loa.andersson@ericsson.com
> >>>>>>>>>= >>> Sr Strategy and Standards Manager        &= nbsp;   loa@= pi.nu
> >>>>>>>>>>>> Ericsson= Inc                    &= nbsp;     phone: +46 10 717
> 52
> >> 13
>= ; >>>>>>>>>>>>      &nbs= p;                     &n= bsp;           +46 767 72 92
> 13
> >>>>>>>>>>>> _________________________= ______________________
> >>>>>>>>>>>= > mpls mailing list
> >>>>>>>>>>>= > mpls= @ietf.org
> >>>>>>>>>>>> https:= //www.ietf.org/mailman/listinfo/mpls=0A
> >>>>>>= ;>>>>> _______________________________________________
&g= t; >>>>>>>>>>> mpls mailing list
> &= gt;>>>>>>>>>> mpls@ietf.org
> >>>&g= t;>>>>>>> https://www.ietf.org/mailman/listinfo/mpls=0A<= /a>
> >>>>>>>>>> ______________________= _________________________
> >>>>>>>>>> = mpls mailing list
> >>>>>>>>>> mpls@ietf.org=
> >>>>>>>>>> https://www.ietf.org/mailma= n/listinfo/mpls=0A
> >>>>>>>>> _______= ________________________________________
> >>>>>>&g= t;>> mpls mailing list
> >>>>>>>>> <= a ymailto=3D"mailto:mpls@ietf.org" href=3D"mailto:mpls@ietf.org">mpls@ietf.= org
> >>>>>>>>> https://www.ietf.org/mai= lman/listinfo/mpls=0A
> >>>>>>>>
> = >>>>>>>>
> >>>>>>>> T= his E-mail and any of its attachments may contain Time Warner
> >&= gt;>> Cable
> >>>>>>> proprietary informat= ion, which is privileged, confidential, or
> >>>> subject= to
> >>>>>>> copyright belonging to Time Warner= Cable. This E-mail is intended
> >>>> solely for
>= >>>>> the
> >>>>>>> use of the i= ndividual or entity to which it is addressed. If you
> >>>&g= t; are not the
> >>>>>>> intended recipient of t= his E-mail, you are hereby notified that
> >>>> any
&g= t; >>>>> dissemination,
> >>>>>>>= distribution, copying, or action taken in relation to the
> >> contents
> >>>> of and
> >>>>>>&= gt; attachments to this E-mail is strictly prohibited and may be
> &g= t;>>> unlawful. If you
> >>>>>>> have r= eceived this E-mail in error, please notify the sender
> >>>= > immediately and
> >>>>>>> permanently delet= e the original and any copy of this E-mail and
> >>>> any= printout.
> >>>>>>>> _______________________= ________________________
> >>>>>>>> mpls mail= ing list
> >>>>>>>> mpls@ietf.org
> >>= >>>>>> https://www.ietf.org/mailman/listinfo/mpls=0A> >>>
> >>> ___________________________________= ____________
> >>> mpls mailing list
> >>> mpls@ietf.o= rg
> >>> https://www.ietf.org/mailman/listinfo/mpls=0A=
> _______________________________________________
> mpls maili= ng list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls= =0A
_______________________________________________
mpls mailing = list
m= pls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

---1314897756-30534226-1356077403=:99620-- From Thomas.Beckhaus@telekom.de Fri Dec 21 04:54:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624D821F8909 for ; Fri, 21 Dec 2012 04:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSorgqptAArw for ; Fri, 21 Dec 2012 04:54:47 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9275621F8816 for ; Fri, 21 Dec 2012 04:54:44 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 21 Dec 2012 13:54:42 +0100 Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.13]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 21 Dec 2012 13:54:42 +0100 From: To: Date: Fri, 21 Dec 2012 13:54:41 +0100 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Thread-Index: Ac3dwoBYLmkbVGWmSsKVtGDthicSBgBt8LaA Message-ID: References: <50D17A08.8050109@pi.nu> In-Reply-To: <50D17A08.8050109@pi.nu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-dod@tools.ietf.org Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 12:54:47 -0000 Support (as author). Thomas > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf Of Loa Andersson > Sent: Wednesday, December 19, 2012 9:26 AM > To: mpls@ietf.org > Cc: mpls-chairs@tools.ietf.org; > > Subject: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod > Importance: High > > > Working Group, > > This is to start a working group last call on > draft-ietf-mpls-ldp-dod-03. This working last call is extended > due to the upcoming holidays. > > Please send your comments to the mpls working group mailing > list (mpls@ietf.org). > > Please send both technical comments, and if you are happy with the > document as is also indications of support. > > There are no IPR claims against this draft. > > All the co-authors has stated that they are not ware of any IPRs. > > This working group last call will end on January 15, 2013. > > /Loa > for the wg co-chairs > > -- > > > Loa Andersson email: > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Fri Dec 21 05:55:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F421F8470 for ; Fri, 21 Dec 2012 05:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yelsPEAeBCEh for ; Fri, 21 Dec 2012 05:55:30 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1E21F846B for ; Fri, 21 Dec 2012 05:55:30 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id AE1508244B; Fri, 21 Dec 2012 14:55:28 +0100 (CET) Message-ID: <50D46A4B.1020403@pi.nu> Date: Fri, 21 Dec 2012 14:55:23 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org, draft-ietf-mpls-tp-security-framework@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] upcoming wg last for two documens X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:55:34 -0000 Working Group, We have two working group documents: - draft-ietf-mpls-tp-use-cases-and-design - draft-ietf-mpls-tp-security-framework That has been either taken back into the working groups or returned to us after the AD review. Both draft has been updated addressing all comments from the AD review. The changes to the documents are substantial. The Working Group chairs will issue new full scale working group last call for both documents. The "MPLS-TP Security Framework" will be working group last called starting January 7, 2013. The "MPLS-TP Applicability; Use Cases and Design" will be working group last calle starting a week later (January 14, 2013). However, nothing stops you starting your review already now. /Loa for -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Fri Dec 21 05:58:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844FF21F84E0 for ; Fri, 21 Dec 2012 05:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.552 X-Spam-Level: X-Spam-Status: No, score=-101.552 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jM3+rAinwLw for ; Fri, 21 Dec 2012 05:58:34 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id D544A21F8472 for ; Fri, 21 Dec 2012 05:58:33 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id CAFFB8244B; Fri, 21 Dec 2012 14:58:32 +0100 (CET) Message-ID: <50D46B03.7080201@pi.nu> Date: Fri, 21 Dec 2012 14:58:27 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-mpls-tp-security-framework@tools.ietf.org, "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-use-cases-and-design@tools.ietf.org Subject: [mpls] upcoming working group last call for two documents X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 13:58:34 -0000 Working Group, We have two working group documents: - draft-ietf-mpls-tp-use-cases-and-design - draft-ietf-mpls-tp-security-framework That has been either taken back into the working groups or returned to us after the AD review. Both draft has been updated addressing all comments from the AD review. The changes to the documents are substantial. The Working Group chairs will issue new full scale working group last call for both documents. The "MPLS-TP Security Framework" will be working group last called starting January 7, 2013. The "MPLS-TP Applicability; Use Cases and Design" will be working group last calle starting a week later (January 14, 2013). However, nothing stops you starting your review already now. /Loa PS I will stop using my webmail, it does things to my subject lines :( -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From agmalis@gmail.com Fri Dec 21 10:32:36 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D35621F8697 for ; Fri, 21 Dec 2012 10:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.861 X-Spam-Level: X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnqa-dHiSA3R for ; Fri, 21 Dec 2012 10:32:34 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4724E21F86C0 for ; Fri, 21 Dec 2012 10:32:34 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so4224985iak.12 for ; Fri, 21 Dec 2012 10:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FReZlkYcZ7alBo2Uy8HPDh1Bc2WfWXcY0BnFrPS1oGc=; b=Soh0xTKnOXvjFIC+rRrVcC0DAy+ldKaaSAkPsaD/kB0z6ZwXkGqYMfotfVCRIxpmEX bVutwpRjeR3kmxghNUbAHe61TfYZCSpN2Uz/fWVKJIGfADwBxKk2Wpzatrm1joJ8fpSv yJfkV9gINYakzOBmVmkt3yDQiRqMmCh+UDfCt9QaYocDQaHLWiEri0x/h2U+JL2PVLe+ 7DeKg+n+AhvuG0qMX0NHlzyWqG+5CqWdtNaxpZSPyTqWPAKx0BjNmAiekftvG9LcyBvy r4b6dC1Au/tQ63or9/VCKO5OPWzoXMIVg1j/iRy400v7lDOMZCw0pWKeZitacT6L/afb Opow== Received: by 10.50.178.67 with SMTP id cw3mr14496191igc.53.1356114753712; Fri, 21 Dec 2012 10:32:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.51.228 with HTTP; Fri, 21 Dec 2012 10:32:13 -0800 (PST) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> From: "Andrew G. Malis" Date: Fri, 21 Dec 2012 13:32:13 -0500 Message-ID: To: Shane Amante Content-Type: multipart/alternative; boundary=e89a8f6438962b72cb04d1611245 Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 18:32:36 -0000 --e89a8f6438962b72cb04d1611245 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I've commented earlier on this draft, and like Shane, I remain unconvinced of its utility. I still don't think it has any utility at all for core backbone networks - just use native MPLS, or if you must tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I guess I could be convinced, but I would like to see a clear justification in the form of requirements from nvo3 that could only be met by this draft. Thanks, Andy On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante wrote= : > Xiaohu, > > On Dec 18, 2012, at 11:50 PM, Xuxiaohu wrote: > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58 > >> =CA=D5=BC=FE=C8=CB: Rogers, Josh > >> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.iet= f.org; > >> mpls@ietf.org; mpls-chairs@tools.ietf.org > >> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an > >> mpls working group document > >> > >> > >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" > >> wrote: > >>> I share your SP perspective, and do not see the problem this solution > >>> addresses in practice any longer. > >> > >> +1. Please do not define yet another MPLS-over-IP encapsulation. The > IETF > >> already standardized MPLS over GRE. The IETF has also standardized MP= LS > >> over L2TPv3/UDP/IP, which had seen some deployment in at least one, ve= ry > >> large operator network that I'm aware of to support carriage of L3VPN > over an > >> IP-only network. > > > > Hi Shane, > > > > Thank you for telling us there are actual deployments of MPLS over IP i= n > at least one, very large operator network. This fact must be very valuabl= e > to those people who had believed there is no application of MPLS over IP = in > today's SP networks. > > > >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 > >> [NOTE: the dates the above were published was back in the 2006 > timeframe!] > >> RFC 4665 for requirements related to VPLS that say that VPLS may b= e > >> carried over L2TPv3 > >> And, here's evidence showing that at least one vendor has > implemented > >> IPVPN's over L2TPv3: > >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html > > > > Thanks again for sharing the above information. As mentioned in this > draft AND other drafts, the mechanism of performing hash calculation on t= he > Session ID field in the L2TPv3 header or the Key field in the GRE header = as > defined in [RFC 5640] is not widely supported by existing core routers so > far. > > FWIW, I have had success, in the relatively recent past, in requesting a > core router vendor to support changes to the input-keys used in hash > calculations in _existing_ hardware, already deployed (extensively) > throughout my network. Further, I suspect that most large network > operators are savvy folks and understand the internal architecture of the= ir > HW fairly well. As a result, those same operators know what is and is no= t > technically possible in this regard. Thus, it may be a question of > "methods" necessary to convince their HW supplier(s) to make appropriate > changes in their equipment to achieve their business goals. :-) However= , > this may not even be necessary ... see below. > > > > In contrast, most existing core routers are already capable of balancin= g > IP traffic flows based on the hash of the five-tuple of UDP packets. By > using the MPLS-in-UDP encapsulation, the already available load-balancing > capability of most existing core routers can be leveraged without requiri= ng > any change to them. That is the major motivation of this draft. > > If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3= , > which uses UDP/IP, in the first place? > > IMHO, a better proposal may be to consider a [minor] (?) change to RFC > 3931, which would allow the connection used for data packets (not control > packets) to use a varying set of source ports (or, source IP addresses), > based on a hash calculation, to achieve better load-balancing over existi= ng > equipment in an IP-only core. L2TP end-system implementations would be > better off just using the "Session ID" (and "Cookie") fields as the > demultiplexor to associate incoming packets with the associated L2TP > Control Channel. In fact, it's not clear to me that existing > implementations may /already/ do this, making any "check" on the incoming > source port unnecessary for L2TP end-system implementations. > > The beauty of the above approach is: > 1) I would think that the above is most likely a change that is limited t= o > the "control channel" (software) of existing L2TP end-system > implementations. Heck, it may even be backwards compatible with existing > L2TPv3 implementations. (L2TPv3 implementors would need to comment on > that). > 2) There is a substantial added security one gets by using "Session ID" > and "Cookie" fields to ensure the received L2TPv3 packet is intended for > the identified session. Quoting from Section 8.2 of RFC 3931: > ---snip--- > L2TPv3 provides traffic separation for its VPNs via a 32-bit Session > ID in the L2TPv3 data header. When present, the L2TPv3 Cookie > (described in Section 4.1), provides an additional check to ensure > that an arriving packet is intended for the identified session. > Thus, use of a Cookie with the Session ID provides an extra guarantee > that the Session ID lookup was performed properly and that the > Session ID itself was not corrupted in transit. > ---snip--- > ... in regard to this question alone, I know the Security Area folks have= , > in the past, had /substantial/ concerns about encapsulation of MPLS over = IP > transport. In fact, this is why you see text in Section 7.6, "Security", > of RFC 4665. (There's likely similar language in other drafts that use > MPLS for transport). While I'm not sure that Security Area folks pay muc= h > attention to daily traffic on the MPLS WG mailing list, I'm fairly > confident this concern will arise if/when this draft goes to the IESG ... > 3) Finally, this approach only affects the end-systems that implement > L2TP, for tunneling of MPLS/IP, and does not require an entire industry t= o > support MPLS/UDP encapsulation in their product lines. > > -shane > > > > > > Best regards, > > Xiaohu > > > >> If there was market demand for MPLS over IP, then clearly it would hav= e > been > >> more widely implemented by equipment vendors, with either MPLS over GR= E > or > >> MPLS over L2TPv3. (Where there's a will, there's a way). I would not= e > that > >> the most likely reasons this did not pan out was there are several, > practical > >> operational benefits one gets from going with native MPLS > >> encapsulation/switching within the data plane, namely: > >> - MPLS Fast Re-Route > >> - MPLS Traffic Engineering > >> ... to name, but a few. Those have tended to be quite compelling > arguments > >> to 'upgrade' network HW to support MPLS encapsulation/switching. > >> > >> -shane > >> > >> > >>> -Josh > >>> > >>> > >>> On 12/18/12 12:31 AM, "Shahram Davari" wrote: > >>> > >>>> For service provider domain, MPLS over IP is legacy and there is no > need > >>>> to improve it. > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> > >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" wrote: > >>>> > >>>>> Shahram, > >>>>> > >>>>> This draft is ONLY intended to provide a MPLS-over-IP encapsulation > >>>>> method with a better load-balancing applicability so far to those > >>>>> operators who happen to require transporting MPLS application traff= ic > >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and VXL= AN > >>>>> each have their own advocators and use cases. If you absolutely > believe > >>>>> it's meaningless of transporting MPLS application traffic across IP > >>>>> networks and therefore those existing RFCs related to MPLS over IP > >>>>> tunneling mechanisms should be moved to Historic status, please say > so. > >>>>> > >>>>> By the way, it seems this > >>>>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) i= s > >>>>> just the right thread suitable for you to make the following argume= nt > >>>>> (i.e., whether or not MPLS-based VPN is applicable to data centers)= . > I > >>>>> had thought you would speak up at that time. Sadly, surprisingly > silent > >>>>> till now. > >>>>> > >>>>> Sigh, I didn't intend to say the above otherwise. > >>>>> > >>>>> Xiaohu > >>>>> > >>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@iet= f.org] =B4=FA=B1=ED > >> S. > >>>>>> Davari > >>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34 > >>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersson > >>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; > >>>>>> mpls-chairs@tools.ietf.org > >>>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make > >>>>>> draft-xu-mpls-in-udp an > >>>>>> mpls working group document > >>>>>> > >>>>>> I don't support this draft since it has no application in today's > >>>>>> modern metro > >>>>>> and core, where MPLS is dominant, and its only practical applicati= on > >>>>>> in in data > >>>>>> center, which already is crowded with other solutions such as NVGR= E > and > >>>>>> VXLAN. > >>>>>> > >>>>>> It seems the authors are trying to bypass the NVO3 solution > selection > >>>>>> process > >>>>>> by advancing the draft in MPLS WG. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>>> > >>>>>> > >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: > >>>>>> > >>>>>>> Working group, > >>>>>>> > >>>>>>> This is to start a "two week" poll on adopting > >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. > >>>>>>> Due to the holiday season this poll has been extended with one > week. > >>>>>>> > >>>>>>> Please send your comments (support/not support) to the mpls worki= ng > >>>>>>> group mailing list (mpls at ietf.org). Please give an technical > >>>>>>> motivation for your support/not support, especially if you think > that > >>>>>>> the document should not be adopted as a working group document. > >>>>>>> > >>>>>>> This poll ends January 07, 2013. > >>>>>>> > >>>>>>> There is one IPR claim against this document - > >>>>>>> https://datatracker.ietf.org/ipr/1941/ . > >>>>>>> > >>>>>>> All the active co-authors has stated on the working group mailing > list > >>>>>>> that they are not aware of any other IPR claims than those alread= y > >>>>>>> disclosed. > >>>>>>> > >>>>>>> However, up to version -03 (the document that we used for the IPR > >>>>>>> poll) > >>>>>>> Marshall Eubanks was listed as one of the authors. Marshall has > >>>>>>> discontinued all interactions with the IETF, including the author > team > >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried to > >>>>>>> contact Marshall by other means, to try get a response on the IPR > >>>>>>> poll. > >>>>>>> We have had no success in this. > >>>>>>> > >>>>>>> From version -04 the authors decided to remove Marshall as a > >>>>>>> co-author. > >>>>>>> > >>>>>>> /Loa > >>>>>>> (mpls wg co-chair) > >>>>>>> -- > >>>>>>> > >>>>>>> > >>>>>>> Loa Andersson email: > >>>>>> loa.andersson@ericsson.com > >>>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>>> +46 767 72 92 13 > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner Cable > >> proprietary information, which is privileged, confidential, or subject > to > >> copyright belonging to Time Warner Cable. This E-mail is intended > solely for the > >> use of the individual or entity to which it is addressed. If you are > not the > >> intended recipient of this E-mail, you are hereby notified that any > dissemination, > >> distribution, copying, or action taken in relation to the contents of > and > >> attachments to this E-mail is strictly prohibited and may be unlawful. > If you > >> have received this E-mail in error, please notify the sender > immediately and > >> permanently delete the original and any copy of this E-mail and any > printout. > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --e89a8f6438962b72cb04d1611245 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I've commented earlier on this draft, and like Shane, = I remain unconvinced of its utility. I still don't think it has any uti= lity at all for core backbone networks - just use native MPLS, or if you mu= st tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data ce= nter applications, I guess I could be convinced, but I would like to see a = clear justification in the form of requirements from nvo3 that could only b= e met by this draft.

Thanks,
Andy


On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@= castlepoint.net> wrote:
Xiaohu,

On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make dr= aft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encapsulat= ion.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage o= f L3VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one v= endor has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s= /feature/guide/csgl3vpn.html
>
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so = far.

FWIW, I have had success, in the relatively recent past, in req= uesting a core router vendor to support changes to the input-keys used in h= ash calculations in _existing_ hardware, already deployed (extensively) thr= oughout my network.  Further, I suspect that most large network operat= ors are savvy folks and understand the internal architecture of their HW fa= irly well.  As a result, those same operators know what is and is not = technically possible in this regard.  Thus, it may be a question of &q= uot;methods" necessary to convince their HW supplier(s) to make approp= riate changes in their equipment to achieve their business goals.  :-)=  However, this may not even be necessary ... see below.


> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring = any change to them. That is the major motivation of this draft.

If this is a concern, then why not encapsulate the traffic in MPLS/L2= TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipm= ent in an IP-only core.  L2TP end-system implementations would be bett= er off just using the "Session ID" (and "Cookie") field= s as the demultiplexor to associate incoming packets with the associated L2= TP Control Channel.  In fact, it's not clear to me that existing i= mplementations may /already/ do this, making any "check" on the i= ncoming source port unnecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on= that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in o= ther drafts that use MPLS for transport).  While I'm not sure that= Security Area folks pay much attention to daily traffic on the MPLS WG mai= ling list, I'm fairly confident this concern will arise if/when this dr= aft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane


>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a w= ay).  I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/swit= ching.
>>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application = traffic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.<= br> >>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8= =D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
>>>>>> mpls= -chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have su= pport to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no app= lication in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.= andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13=
>>>>>>>             &nbs= p;                     &n= bsp;      +46 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org=
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--e89a8f6438962b72cb04d1611245-- From lucy.yong@huawei.com Fri Dec 21 11:27:40 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490C21F8814 for ; Fri, 21 Dec 2012 11:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=-2.272, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2qeD-Nqdr2c for ; Fri, 21 Dec 2012 11:27:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB821F869E for ; Fri, 21 Dec 2012 11:27:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOB27343; Fri, 21 Dec 2012 19:27:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 19:27:15 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 19:27:31 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 11:27:28 -0800 From: Lucy yong To: "Andrew G. Malis" , Shane Amante Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3baG6lNZW4xfyUOAvM96G0N/cZggt7EAgANl+4D//4fyUA== Date: Fri, 21 Dec 2012 19:27:28 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.159] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44864DEDdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:27:40 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44864DEDdfweml505mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QW5keSwNCg0KSGVyZSBpcyB0aGUgdGV4dCBmcm9tIGRyYWZ0LWlldGYtbnZvMy1kYXRhcGxhbmUt cmVxdWlyZW1lbnRzLTAwLnR4dA0KDQogIDMuMy4yLjEuIExBRyBhbmQgRUNNUA0KDQogICAgICAg Rm9yIHBlcmZvcm1hbmNlIHJlYXNvbnMsIG11bHRpcGF0aCBvdmVyIExBRyBhbmQgRUNNUCBwYXRo cyBTSE9VTEQgYmUNCiAgICAgICBzdXBwb3J0ZWQuDQoNCiAgICAgICBMQUcgKExpbmsgQWdncmVn YXRpb24gR3JvdXApIFtJRUVFIDgwMi4xQVgtMjAwOF0gYW5kIEVDTVAgKEVxdWFsDQogICAgICAg Q29zdCBNdWx0aSBQYXRoKSBhcmUgY29tbW9ubHkgdXNlZCB0ZWNobmlxdWVzIHRvIHBlcmZvcm0g bG9hZC0NCiAgICAgICBiYWxhbmNpbmcgb2YgbWljcm9mbG93cyBvdmVyIGEgc2V0IG9mIGEgcGFy YWxsZWwgbGlua3MgZWl0aGVyIGF0DQogICAgICAgTGF5ZXItMiAoTEFHKSBvciBMYXllci0zIChF Q01QKS4gRXhpc3RpbmcgZGVwbG95ZWQgaGFyZHdhcmUNCiAgICAgICBpbXBsZW1lbnRhdGlvbnMg b2YgTEFHIGFuZCBFQ01QIHVzZXMgYSBoYXNoIG9mIHZhcmlvdXMgZmllbGRzIGluIHRoZQ0KICAg ICAgICBlbmNhcHN1bGF0aW9uIChvdXRlcm1vc3QpIGhlYWRlcihzKSAoZS5nLiBzb3VyY2UgYW5k IGRlc3RpbmF0aW9uIE1BQw0KICAgICAgIGFkZHJlc3NlcyBmb3Igbm9uLUlQIHRyYWZmaWMsIHNv dXJjZSBhbmQgZGVzdGluYXRpb24gSVAgYWRkcmVzc2VzLA0KICAgICAgIEw0IHByb3RvY29sLCBM NCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVycywgZXRjKS4NCiAgICAgICBGdXJ0 aGVybW9yZSwgaGFyZHdhcmUgZGVwbG95ZWQgZm9yIHRoZSB1bmRlcmxheSBuZXR3b3JrKHMpIHdp bGwgYmUNCiAgICAgICBtb3N0IG9mdGVuIHVuYXdhcmUgb2YgdGhlIGNhcnJpZWQsIGlubmVybW9z dCBMMiBmcmFtZXMgb3IgTDMgcGFja2V0cw0KICAgICAgIHRyYW5zbWl0dGVkIGJ5IHRoZSBUUy4g VGh1cywgaW4gb3JkZXIgdG8gcGVyZm9ybSBmaW5lLWdyYWluZWQgbG9hZC0NCiAgICAgICBiYWxh bmNpbmcgb3ZlciBMQUcgYW5kIEVDTVAgcGF0aHMgaW4gdGhlIHVuZGVybHlpbmcgbmV0d29yaywg dGhlDQogICAgICAgZW5jYXBzdWxhdGlvbiBNVVNUIHJlc3VsdCBpbiBzdWZmaWNpZW50IGVudHJv cHkgdG8gZXhlcmNpc2UgYWxsDQogICAgICAgcGF0aHMgdGhyb3VnaCBzZXZlcmFsIExBRy9FQ01Q IGhvcHMuIFRoZSBlbnRyb3B5IGluZm9ybWF0aW9uIE1BWSBiZQ0KICAgICAgIGluZmVycmVkIGZy b20gdGhlIE5WTzMgb3ZlcmxheSBoZWFkZXIgb3IgdW5kZXJsYXkgaGVhZGVyLg0KDQpPdXIgZHJh ZnQgcHJvdmlkZXMgYW4gYWR2YW5jZWQgc29sdXRpb24gaW4gdGhpcyBzcGFjZS4NCg0KTHVjeQ0K DQpGcm9tOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbmRyZXcgRy4gTWFsaXMNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MjEsIDIwMTIgMTI6MzIgUE0NClRvOiBTaGFuZSBBbWFudGUNCkNjOiBkcmFmdC14dS1tcGxzLWlu LXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0 IHRvIG1ha2UgZHJhZnQteHUtbXBscy1pbi11ZHAgYW4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50DQoNCkkndmUgY29tbWVudGVkIGVhcmxpZXIgb24gdGhpcyBkcmFmdCwgYW5kIGxpa2UgU2hh bmUsIEkgcmVtYWluIHVuY29udmluY2VkIG9mIGl0cyB1dGlsaXR5LiBJIHN0aWxsIGRvbid0IHRo aW5rIGl0IGhhcyBhbnkgdXRpbGl0eSBhdCBhbGwgZm9yIGNvcmUgYmFja2JvbmUgbmV0d29ya3Mg LSBqdXN0IHVzZSBuYXRpdmUgTVBMUywgb3IgaWYgeW91IG11c3QgdHVubmVsIE1QTFMgb3ZlciBJ UCwgdGhlIEdSRSBvciBMMlRQdjMgZW5jYXBzdWxhdGlvbnMuIFJlZ2FyZGluZyBkYXRhIGNlbnRl ciBhcHBsaWNhdGlvbnMsIEkgZ3Vlc3MgSSBjb3VsZCBiZSBjb252aW5jZWQsIGJ1dCBJIHdvdWxk IGxpa2UgdG8gc2VlIGEgY2xlYXIganVzdGlmaWNhdGlvbiBpbiB0aGUgZm9ybSBvZiByZXF1aXJl bWVudHMgZnJvbSBudm8zIHRoYXQgY291bGQgb25seSBiZSBtZXQgYnkgdGhpcyBkcmFmdC4NCg0K VGhhbmtzLA0KQW5keQ0KDQpPbiBXZWQsIERlYyAxOSwgMjAxMiBhdCA5OjM4IEFNLCBTaGFuZSBB bWFudGUgPHNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0 Pj4gd3JvdGU6DQpYaWFvaHUsDQoNCk9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4gd3Jv dGU6DQotLS0tLdPKvP7Urbz+LS0tLS0NCj4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86 c2hhbmVAY2FzdGxlcG9pbnQubmV0PG1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQ+XQ0KPj4g t6LLzcqxvOQ6IDIwMTLE6jEy1MIxOcjVIDExOjU4DQo+PiDK1bz+yMs6IFJvZ2VycywgSm9zaA0K Pj4gs63LzTogU2hhaHJhbSBEYXZhcmk7IFh1eGlhb2h1OyBkcmFmdC14dS1tcGxzLWluLXVkcEB0 b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+ Ow0KPj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+INb3zOI6 IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQt eHUtbXBscy1pbi11ZHAgYW4NCj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPj4NCj4+ DQo+PiBPbiBEZWMgMTgsIDIwMTIsIGF0IDg6NTAgQU0sICJSb2dlcnMsIEpvc2giIDxqb3NoLnJv Z2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dlcnNAdHdjYWJsZS5jb20+Pg0KPj4gd3Jv dGU6DQo+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUg cHJvYmxlbSB0aGlzIHNvbHV0aW9uDQo+Pj4gYWRkcmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25n ZXIuDQo+Pg0KPj4gKzEuICBQbGVhc2UgZG8gbm90IGRlZmluZSB5ZXQgYW5vdGhlciBNUExTLW92 ZXItSVAgZW5jYXBzdWxhdGlvbi4gIFRoZSBJRVRGDQo+PiBhbHJlYWR5IHN0YW5kYXJkaXplZCBN UExTIG92ZXIgR1JFLiAgVGhlIElFVEYgaGFzIGFsc28gc3RhbmRhcmRpemVkIE1QTFMNCj4+IG92 ZXIgTDJUUHYzL1VEUC9JUCwgd2hpY2ggaGFkIHNlZW4gc29tZSBkZXBsb3ltZW50IGluIGF0IGxl YXN0IG9uZSwgdmVyeQ0KPj4gbGFyZ2Ugb3BlcmF0b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBv ZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mIEwzVlBOIG92ZXIgYW4NCj4+IElQLW9ubHkgbmV0d29y ay4NCj4NCj4gSGkgU2hhbmUsDQo+DQo+IFRoYW5rIHlvdSBmb3IgdGVsbGluZyB1cyB0aGVyZSBh cmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3ZlciBJUCBpbiBhdCBsZWFzdCBvbmUsIHZl cnkgbGFyZ2Ugb3BlcmF0b3IgbmV0d29yay4gVGhpcyBmYWN0IG11c3QgYmUgdmVyeSB2YWx1YWJs ZSB0byB0aG9zZSBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlv biBvZiBNUExTIG92ZXIgSVAgaW4gdG9kYXkncyBTUCBuZXR3b3Jrcy4NCj4NCj4+IFNlZTogUkZD J3MgNDQ1NCwgNDcxOSwgNDU5MSwgNDM0OSBmb3IgUFdFMyBvdmVyIEwyVFB2Mw0KPj4gW05PVEU6 IHRoZSBkYXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJhY2sgaW4gdGhlIDIwMDYg dGltZWZyYW1lIV0NCj4+ICAgICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g VlBMUyB0aGF0IHNheSB0aGF0IFZQTFMgbWF5IGJlDQo+PiBjYXJyaWVkIG92ZXIgTDJUUHYzDQo+ PiAgICAgQW5kLCBoZXJlJ3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0IG9uZSB2ZW5k b3IgaGFzIGltcGxlbWVudGVkDQo+PiBJUFZQTidzIG92ZXIgTDJUUHYzOg0KPj4gaHR0cDovL3d3 dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3MvMTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5o dG1sDQo+DQo+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmluZyB0aGUgYWJvdmUgaW5mb3JtYXRpb24u IEFzIG1lbnRpb25lZCBpbiB0aGlzIGRyYWZ0IEFORCBvdGhlciBkcmFmdHMsIHRoZSBtZWNoYW5p c20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9uIG9uIHRoZSBTZXNzaW9uIElEIGZpZWxk IGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBLZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIg YXMgZGVmaW5lZCBpbiBbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0 aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuDQpGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nlc3MsIGluIHRo ZSByZWxhdGl2ZWx5IHJlY2VudCBwYXN0LCBpbiByZXF1ZXN0aW5nIGEgY29yZSByb3V0ZXIgdmVu ZG9yIHRvIHN1cHBvcnQgY2hhbmdlcyB0byB0aGUgaW5wdXQta2V5cyB1c2VkIGluIGhhc2ggY2Fs Y3VsYXRpb25zIGluIF9leGlzdGluZ18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVu c2l2ZWx5KSB0aHJvdWdob3V0IG15IG5ldHdvcmsuICBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBt b3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBzYXZ2eSBmb2xrcyBhbmQgdW5kZXJzdGFu ZCB0aGUgaW50ZXJuYWwgYXJjaGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMg YSByZXN1bHQsIHRob3NlIHNhbWUgb3BlcmF0b3JzIGtub3cgd2hhdCBpcyBhbmQgaXMgbm90IHRl Y2huaWNhbGx5IHBvc3NpYmxlIGluIHRoaXMgcmVnYXJkLiAgVGh1cywgaXQgbWF5IGJlIGEgcXVl c3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVpciBIVyBzdXBwbGll cihzKSB0byBtYWtlIGFwcHJvcHJpYXRlIGNoYW5nZXMgaW4gdGhlaXIgZXF1aXBtZW50IHRvIGFj aGlldmUgdGhlaXIgYnVzaW5lc3MgZ29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBl dmVuIGJlIG5lY2Vzc2FyeSAuLi4gc2VlIGJlbG93Lg0KDQoNCj4gSW4gY29udHJhc3QsIG1vc3Qg ZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBhbHJlYWR5IGNhcGFibGUgb2YgYmFsYW5jaW5nIElQ IHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUtdHVwbGUgb2YgVURQ IHBhY2tldHMuIEJ5IHVzaW5nIHRoZSBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxy ZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmcgY2FwYWJpbGl0eSBvZiBtb3N0IGV4aXN0aW5n IGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJhZ2VkIHdpdGhvdXQgcmVxdWlyaW5nIGFueSBjaGFu Z2UgdG8gdGhlbS4gVGhhdCBpcyB0aGUgbWFqb3IgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0K SWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZp YyBpbiBNUExTL0wyVFB2Mywgd2hpY2ggdXNlcyBVRFAvSVAsIGluIHRoZSBmaXJzdCBwbGFjZT8N Cg0KSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAo PykgY2hhbmdlIHRvIFJGQyAzOTMxLCB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1 c2VkIGZvciBkYXRhIHBhY2tldHMgKG5vdCBjb250cm9sIHBhY2tldHMpIHRvIHVzZSBhIHZhcnlp bmcgc2V0IG9mIHNvdXJjZSBwb3J0cyAob3IsIHNvdXJjZSBJUCBhZGRyZXNzZXMpLCBiYXNlZCBv biBhIGhhc2ggY2FsY3VsYXRpb24sIHRvIGFjaGlldmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92 ZXIgZXhpc3RpbmcgZXF1aXBtZW50IGluIGFuIElQLW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3Rl bSBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgYmV0dGVyIG9mZiBqdXN0IHVzaW5nIHRoZSAiU2Vz c2lvbiBJRCIgKGFuZCAiQ29va2llIikgZmllbGRzIGFzIHRoZSBkZW11bHRpcGxleG9yIHRvIGFz c29jaWF0ZSBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9s IENoYW5uZWwuICBJbiBmYWN0LCBpdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucyBtYXkgL2FscmVhZHkvIGRvIHRoaXMsIG1ha2luZyBhbnkgImNoZWNrIiBv biB0aGUgaW5jb21pbmcgc291cmNlIHBvcnQgdW5uZWNlc3NhcnkgZm9yIEwyVFAgZW5kLXN5c3Rl bSBpbXBsZW1lbnRhdGlvbnMuDQoNClRoZSBiZWF1dHkgb2YgdGhlIGFib3ZlIGFwcHJvYWNoIGlz Og0KMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBhIGNoYW5n ZSB0aGF0IGlzIGxpbWl0ZWQgdG8gdGhlICJjb250cm9sIGNoYW5uZWwiIChzb2Z0d2FyZSkgb2Yg ZXhpc3RpbmcgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVudGF0aW9ucy4gIEhlY2ssIGl0IG1heSBl dmVuIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgTDJUUHYzIGltcGxlbWVu dGF0aW9ucy4gIChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxkIG5lZWQgdG8gY29tbWVudCBvbiB0 aGF0KS4NCjIpIFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdldHMg YnkgdXNpbmcgIlNlc3Npb24gSUQiIGFuZCAiQ29va2llIiBmaWVsZHMgdG8gZW5zdXJlIHRoZSBy ZWNlaXZlZCBMMlRQdjMgcGFja2V0IGlzIGludGVuZGVkIGZvciB0aGUgaWRlbnRpZmllZCBzZXNz aW9uLiAgUXVvdGluZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOg0KLS0tc25pcC0tLQ0K ICAgTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEg MzItYml0IFNlc3Npb24NCiAgIElEIGluIHRoZSBMMlRQdjMgZGF0YSBoZWFkZXIuICBXaGVuIHBy ZXNlbnQsIHRoZSBMMlRQdjMgQ29va2llDQogICAoZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4xKSwg cHJvdmlkZXMgYW4gYWRkaXRpb25hbCBjaGVjayB0byBlbnN1cmUNCiAgIHRoYXQgYW4gYXJyaXZp bmcgcGFja2V0IGlzIGludGVuZGVkIGZvciB0aGUgaWRlbnRpZmllZCBzZXNzaW9uLg0KICAgVGh1 cywgdXNlIG9mIGEgQ29va2llIHdpdGggdGhlIFNlc3Npb24gSUQgcHJvdmlkZXMgYW4gZXh0cmEg Z3VhcmFudGVlDQogICB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVyZm9ybWVkIHBy b3Blcmx5IGFuZCB0aGF0IHRoZQ0KICAgU2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0 ZWQgaW4gdHJhbnNpdC4NCi0tLXNuaXAtLS0NCi4uLiBpbiByZWdhcmQgdG8gdGhpcyBxdWVzdGlv biBhbG9uZSwgSSBrbm93IHRoZSBTZWN1cml0eSBBcmVhIGZvbGtzIGhhdmUsIGluIHRoZSBwYXN0 LCBoYWQgL3N1YnN0YW50aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9uIG9mIE1QTFMg b3ZlciBJUCB0cmFuc3BvcnQuICBJbiBmYWN0LCB0aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQgaW4g U2VjdGlvbiA3LjYsICJTZWN1cml0eSIsIG9mIFJGQyA0NjY1LiAgKFRoZXJlJ3MgbGlrZWx5IHNp bWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdXNlIE1QTFMgZm9yIHRyYW5zcG9y dCkuICBXaGlsZSBJJ20gbm90IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVhIGZvbGtzIHBheSBtdWNo IGF0dGVudGlvbiB0byBkYWlseSB0cmFmZmljIG9uIHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdCwg SSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGwgYXJpc2UgaWYvd2hlbiB0aGlz IGRyYWZ0IGdvZXMgdG8gdGhlIElFU0cgLi4uDQozKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9u bHkgYWZmZWN0cyB0aGUgZW5kLXN5c3RlbXMgdGhhdCBpbXBsZW1lbnQgTDJUUCwgZm9yIHR1bm5l bGluZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkg dG8gc3VwcG9ydCBNUExTL1VEUCBlbmNhcHN1bGF0aW9uIGluIHRoZWlyIHByb2R1Y3QgbGluZXMu DQoNCi1zaGFuZQ0KDQoNCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUNCj4NCj4+IElmIHRo ZXJlIHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92ZXIgSVAsIHRoZW4gY2xlYXJseSBpdCB3 b3VsZCBoYXZlIGJlZW4NCj4+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2 ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExTIG92ZXIgR1JFIG9yDQo+PiBNUExTIG92ZXIgTDJUUHYz LiAgKFdoZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkgd291bGQgbm90ZSB0 aGF0DQo+PiB0aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBub3QgcGFuIG91dCB3YXMg dGhlcmUgYXJlIHNldmVyYWwsIHByYWN0aWNhbA0KPj4gb3BlcmF0aW9uYWwgYmVuZWZpdHMgb25l IGdldHMgZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+PiBlbmNhcHN1bGF0aW9uL3N3aXRj aGluZyB3aXRoaW4gdGhlIGRhdGEgcGxhbmUsIG5hbWVseToNCj4+IC0gTVBMUyBGYXN0IFJlLVJv dXRlDQo+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZw0KPj4gLi4uIHRvIG5hbWUsIGJ1dCBh IGZldy4gIFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxpbmcgYXJndW1lbnRz DQo+PiB0byAndXBncmFkZScgbmV0d29yayBIVyB0byBzdXBwb3J0IE1QTFMgZW5jYXBzdWxhdGlv bi9zd2l0Y2hpbmcuDQo+Pg0KPj4gLXNoYW5lDQo+Pg0KPj4NCj4+PiAtSm9zaA0KPj4+DQo+Pj4N Cj4+PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2Fk Y29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KPj4+DQo+Pj4+IEZv ciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQIGlzIGxlZ2FjeSBhbmQgdGhl cmUgaXMgbm8gbmVlZA0KPj4+PiB0byBpbXByb3ZlIGl0Lg0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0K Pj4+PiBTaGFocmFtDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIERlYyAxNywgMjAxMiwgYXQgODowMiBQ TSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KPj4+Pg0KPj4+Pj4gU2hhaHJhbSwNCj4+Pj4+DQo+Pj4+PiBUaGlzIGRy YWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0 aW9uDQo+Pj4+PiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2FkLWJhbGFuY2luZyBhcHBsaWNhYmls aXR5IHNvIGZhciB0byB0aG9zZQ0KPj4+Pj4gb3BlcmF0b3JzIHdobyBoYXBwZW4gdG8gcmVxdWly ZSB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+Pj4+PiBhY3Jvc3MgSVAg bmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQLCBOVkdSRSBhbmQgVlhM QU4NCj4+Pj4+IGVhY2ggaGF2ZSB0aGVpciBvd24gYWR2b2NhdG9ycyBhbmQgdXNlIGNhc2VzLiBJ ZiB5b3UgYWJzb2x1dGVseSBiZWxpZXZlDQo+Pj4+PiBpdCdzIG1lYW5pbmdsZXNzIG9mIHRyYW5z cG9ydGluZyBNUExTIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWNyb3NzIElQDQo+Pj4+PiBuZXR3b3Jr cyBhbmQgdGhlcmVmb3JlIHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBNUExTIG92ZXIg SVANCj4+Pj4+IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3Jp YyBzdGF0dXMsIHBsZWFzZSBzYXkgc28uDQo+Pj4+Pg0KPj4+Pj4gQnkgdGhlIHdheSwgaXQgc2Vl bXMgdGhpcw0KPj4+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9udm8z L2N1cnJlbnQvbXNnMDE4NjQuaHRtbCkgaXMNCj4+Pj4+IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBz dWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZyBhcmd1bWVudA0KPj4+Pj4gKGku ZS4sIHdoZXRoZXIgb3Igbm90IE1QTFMtYmFzZWQgVlBOIGlzIGFwcGxpY2FibGUgdG8gZGF0YSBj ZW50ZXJzKS4gSQ0KPj4+Pj4gaGFkIHRob3VnaHQgeW91IHdvdWxkIHNwZWFrIHVwIGF0IHRoYXQg dGltZS4gU2FkbHksIHN1cnByaXNpbmdseSBzaWxlbnQNCj4+Pj4+IHRpbGwgbm93Lg0KPj4+Pj4N Cj4+Pj4+IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lzZS4N Cj4+Pj4+DQo+Pj4+PiBYaWFvaHUNCj4+Pj4+DQo+Pj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ Pj4+Pj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZz5dILT6se0NCj4+IFMuDQo+Pj4+Pj4gRGF2YXJpDQo+Pj4+Pj4gt6LLzcqxvOQ6 IDIwMTLE6jEy1MIxNcjVIDEzOjM0DQo+Pj4+Pj4gytW8/sjLOiBMb2EgQW5kZXJzc29uDQo+Pj4+ Pj4gs63LzTogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz47DQo+Pj4+Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPj4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0 byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UNCj4+Pj4+PiBkcmFmdC14dS1tcGxzLWlu LXVkcCBhbg0KPj4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KPj4+Pj4+DQo+Pj4+ Pj4gSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9u IGluIHRvZGF5J3MNCj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4+Pj4+PiBhbmQgY29yZSwgd2hlcmUg TVBMUyBpcyBkb21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0aWNhbCBhcHBsaWNhdGlvbg0KPj4+ Pj4+IGluIGluIGRhdGENCj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3 aXRoIG90aGVyIHNvbHV0aW9ucyBzdWNoIGFzIE5WR1JFIGFuZA0KPj4+Pj4+IFZYTEFOLg0KPj4+ Pj4+DQo+Pj4+Pj4gSXQgc2VlbXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBieXBhc3MgdGhl IE5WTzMgc29sdXRpb24gc2VsZWN0aW9uDQo+Pj4+Pj4gcHJvY2Vzcw0KPj4+Pj4+IGJ5IGFkdmFu Y2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ Pj4gU2hhaHJhbQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6 MDEgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6 DQo+Pj4+Pj4NCj4+Pj4+Pj4gV29ya2luZyBncm91cCwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBp cyB0byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPj4+Pj4+PiBkcmFmdC14 dS1tcGxzLWluLXVkcC0wNiBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+Pj4+ Pj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVk IHdpdGggb25lIHdlZWsuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcNCj4+Pj4+Pj4gZ3Jv dXAgbWFpbGluZyBsaXN0IChtcGxzIGF0IGlldGYub3JnPGh0dHA6Ly9pZXRmLm9yZz4pLiBQbGVh c2UgZ2l2ZSBhbiB0ZWNobmljYWwNCj4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0 L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0DQo+Pj4+Pj4+IHRoZSBk b2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBUaGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVu dCAtDQo+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28tYXV0aG9ycyBoYXMgc3RhdGVkIG9uIHRo ZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiB0aGF0IHRoZXkgYXJlIG5vdCBh d2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWltcyB0aGFuIHRob3NlIGFscmVhZHkNCj4+Pj4+Pj4g ZGlzY2xvc2VkLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBIb3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAo dGhlIGRvY3VtZW50IHRoYXQgd2UgdXNlZCBmb3IgdGhlIElQUg0KPj4+Pj4+PiBwb2xsKQ0KPj4+ Pj4+PiBNYXJzaGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMgb25lIG9mIHRoZSBhdXRob3JzLiBN YXJzaGFsbCBoYXMNCj4+Pj4+Pj4gZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0 aGUgSUVURiwgaW5jbHVkaW5nIHRoZSBhdXRob3IgdGVhbQ0KPj4+Pj4+PiBvZiBkcmFmdC14dS1t cGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcyB0cmllZCB0bw0KPj4+ Pj4+PiBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9u c2Ugb24gdGhlIElQUg0KPj4+Pj4+PiBwb2xsLg0KPj4+Pj4+PiBXZSBoYXZlIGhhZCBubyBzdWNj ZXNzIGluIHRoaXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhv cnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPj4+Pj4+PiBjby1hdXRob3IuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IC9Mb2ENCj4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+Pj4+Pj4+ IC0tDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IExvYSBBbmRlcnNzb24gICAgICAgICAgICAg ICAgICAgICAgICAgZW1haWw6DQo+Pj4+Pj4gbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208bWFp bHRvOmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPg0KPj4+Pj4+PiBTciBTdHJhdGVneSBhbmQg U3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4N Cj4+Pj4+Pj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2 IDEwIDcxNyA1MiAxMzx0ZWw6JTJCNDYlMjAxMCUyMDcxNyUyMDUyJTIwMTM+DQo+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMzx0 ZWw6JTJCNDYlMjA3NjclMjA3MiUyMDkyJTIwMTM+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0 DQo+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbXBscyBtYWls aW5nIGxpc3QNCj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG1wbHMg bWFpbGluZyBsaXN0DQo+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG1wbHMg bWFpbGluZyBsaXN0DQo+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+DQo+Pj4N Cj4+PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBU aW1lIFdhcm5lciBDYWJsZQ0KPj4gcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHBy aXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0bw0KPj4gY29weXJpZ2h0IGJlbG9u Z2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUNCj4+IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQg aXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4+IGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwNCj4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0 aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQNCj4+IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91DQo+PiBo YXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kDQo+PiBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbXBscyBtYWlsaW5n IGxpc3QNCj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4NCj4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxp c3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D44864DEDdfweml505mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Andy,

 <= /p>

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 <= /p>

  3.3.2.1. LAG and ECMP=  

 

    &nbs= p;  For performance reasons, multipath over LAG and ECMP paths SHOULD = be

    &nbs= p;  supported.

 

    &nbs= p;  LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal

    &nbs= p;  Cost Multi Path) are commonly used techniques to perform load= -

    &nbs= p;  balancing of microflows over a set of a parallel links either at

    &nbs= p;  Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware

    &nbs= p;  implementations of LAG and ECMP uses a hash of various fields= in the

    &nbs= p;   encapsulation (outermost) header(s) (e.g. source and de= stination MAC

    &nbs= p;  addresses for non-IP traffic, source and destination IP addre= sses,

    &nbs= p;  L4 protocol, L4 source and destination port numbers, etc).

    &nbs= p;  Furthermore, hardware deployed for the underlay network(s) wi= ll be

    &nbs= p;  most often unaware of the carried, innermost L2 frames or L3 = packets

    &nbs= p;  transmitted by the TS. Thus, in order to perform fine-grained= load-

    &nbs= p;  balancing over LAG and ECMP paths in the underlying network, the

    &nbs= p;  encapsulation MUST result in sufficient entropy to exercise a= ll

    &nbs= p;  paths through several LAG/ECMP hops. The entropy information = MAY be

    &nbs= p;  inferred from the NVO3 overlay header or underlay header.

 

Our draft provides an advanc= ed solution in this space.

 <= /p>

Lucy

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@= tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this draft, and like Shane= , I remain unconvinced of its utility. I still don't think it has any utili= ty at all for core backbone networks - just use native MPLS, or if you must= tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I guess I could be con= vinced, but I would like to see a clear justification in the form of requir= ements from nvo3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.= net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlepoint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent p= ast, in requesting a core router vendor to support changes to the input-key= s used in hash calculations in _existing_ hardware, already deployed (exten= sively) throughout my network.  Further, I suspect that most large network operators are savvy folks and understand= the internal architecture of their HW fairly well.  As a result, thos= e same operators know what is and is not technically possible in this regar= d.  Thus, it may be a question of "methods" necessary to convince their HW supplier(s) to make appropriate changes in = their equipment to achieve their business goals.  :-)  However, t= his may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulate the t= raffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org;
>>>>>> mpls= -chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.= andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46= 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org=
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44864DEDdfweml505mbx_-- From agmalis@gmail.com Fri Dec 21 11:53:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F111D21F850E for ; Fri, 21 Dec 2012 11:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmhQg+smbJyv for ; Fri, 21 Dec 2012 11:53:23 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94821F8583 for ; Fri, 21 Dec 2012 11:53:20 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id 13so6730274iea.21 for ; Fri, 21 Dec 2012 11:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2/PCVffzvHKUL88fFJEaMalrtCsMwm7FHd2qG3iL/uY=; b=qTN0hcQNUn1NqB/6Ouv3jkKFTNMa4S4byoZds3GMh4kE+QTCz2DWMTlwxQHOY2afpb dxS2FR0p5HSTGErMM54YvvTymVZAYm6B2jtfzoFz5Q0yf6a5uSkQ93Bs8llt3yBrSDas 00iF+RAVntu8fGHf05/CW+NdiZiRRXPmgjFKv2D1XFF4rz8O2zFzioBxdvOB0sDAvRt6 eix7rmWSfnIsAfc5utTbKtpOnCqEEFMPLXULbVGHzqrlHTHXLTuilX1K3ESADfLrQ7GN Jc83ezrp2i//izJXmf0P9XYzcbyyTWE9kcnyGS9N5K/kBn5l8bKL6gX1nBYPmnOPsvR+ f5Fg== Received: by 10.43.114.4 with SMTP id ey4mr12584816icc.27.1356119599748; Fri, 21 Dec 2012 11:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.51.228 with HTTP; Fri, 21 Dec 2012 11:52:59 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> From: "Andrew G. Malis" Date: Fri, 21 Dec 2012 14:52:59 -0500 Message-ID: To: Lucy yong Content-Type: multipart/alternative; boundary=bcaec5171a4704150b04d16233cc Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:53:26 -0000 --bcaec5171a4704150b04d16233cc Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Lucy, Sure, but it could be satisfied by MPLS over L2TP over UDP, or hashing on the GRE key for MPLS over GRE. Cheers, Andy On Fri, Dec 21, 2012 at 2:27 PM, Lucy yong wrote: > Andy,**** > > ** ** > > Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt**** > > ** ** > > 3.3.2.1. LAG and ECMP **** > > ** ** > > For performance reasons, multipath over LAG and ECMP paths SHOULD > be **** > > supported. **** > > ** ** > > LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal *= * > ** > > Cost Multi Path) are commonly used techniques to perform load-**** > > balancing of microflows over a set of a parallel links either at *= * > ** > > Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware **** > > implementations of LAG and ECMP uses a hash of various fields in > the **** > > encapsulation (outermost) header(s) (e.g. source and destination > MAC **** > > addresses for non-IP traffic, source and destination IP addresses, > **** > > L4 protocol, L4 source and destination port numbers, etc). **** > > Furthermore, hardware deployed for the underlay network(s) will be > **** > > most often unaware of the carried, innermost L2 frames or L3 > packets **** > > transmitted by the TS. Thus, in order to perform fine-grained load= - > **** > > balancing over LAG and ECMP paths in the underlying network, the *= * > ** > > encapsulation MUST result in sufficient entropy to exercise all **= * > * > > paths through several LAG/ECMP hops. The entropy information MAY b= e > **** > > inferred from the NVO3 overlay header or underlay header.**** > > ** ** > > Our draft provides an advanced solution in this space.**** > > ** ** > > Lucy**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Andrew G. Malis > *Sent:* Friday, December 21, 2012 12:32 PM > *To:* Shane Amante > *Cc:* draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > *Subject:* Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an mpls working group document**** > > ** ** > > I've commented earlier on this draft, and like Shane, I remain unconvince= d > of its utility. I still don't think it has any utility at all for core > backbone networks - just use native MPLS, or if you must tunnel MPLS over > IP, the GRE or L2TPv3 encapsulations. Regarding data center applications,= I > guess I could be convinced, but I would like to see a clear justification > in the form of requirements from nvo3 that could only be met by this draf= t. > > Thanks, > Andy**** > > ** ** > > On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante > wrote:**** > > Xiaohu,**** > > > On Dec 18, 2012, at 11:50 PM, Xuxiaohu wrote: > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net] > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58 > >> =CA=D5=BC=FE=C8=CB: Rogers, Josh > >> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.iet= f.org; > >> mpls@ietf.org; mpls-chairs@tools.ietf.org > >> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an > >> mpls working group document > >> > >> > >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" > >> wrote: > >>> I share your SP perspective, and do not see the problem this solution > >>> addresses in practice any longer. > >> > >> +1. Please do not define yet another MPLS-over-IP encapsulation. The > IETF > >> already standardized MPLS over GRE. The IETF has also standardized MP= LS > >> over L2TPv3/UDP/IP, which had seen some deployment in at least one, ve= ry > >> large operator network that I'm aware of to support carriage of L3VPN > over an > >> IP-only network. > > > > Hi Shane, > > > > Thank you for telling us there are actual deployments of MPLS over IP i= n > at least one, very large operator network. This fact must be very valuabl= e > to those people who had believed there is no application of MPLS over IP = in > today's SP networks. > > > >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 > >> [NOTE: the dates the above were published was back in the 2006 > timeframe!] > >> RFC 4665 for requirements related to VPLS that say that VPLS may b= e > >> carried over L2TPv3 > >> And, here's evidence showing that at least one vendor has > implemented > >> IPVPN's over L2TPv3: > >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html > > > > Thanks again for sharing the above information. As mentioned in this > draft AND other drafts, the mechanism of performing hash calculation on t= he > Session ID field in the L2TPv3 header or the Key field in the GRE header = as > defined in [RFC 5640] is not widely supported by existing core routers so > far.**** > > FWIW, I have had success, in the relatively recent past, in requesting a > core router vendor to support changes to the input-keys used in hash > calculations in _existing_ hardware, already deployed (extensively) > throughout my network. Further, I suspect that most large network > operators are savvy folks and understand the internal architecture of the= ir > HW fairly well. As a result, those same operators know what is and is no= t > technically possible in this regard. Thus, it may be a question of > "methods" necessary to convince their HW supplier(s) to make appropriate > changes in their equipment to achieve their business goals. :-) However= , > this may not even be necessary ... see below.**** > > > > > In contrast, most existing core routers are already capable of balancin= g > IP traffic flows based on the hash of the five-tuple of UDP packets. By > using the MPLS-in-UDP encapsulation, the already available load-balancing > capability of most existing core routers can be leveraged without requiri= ng > any change to them. That is the major motivation of this draft.**** > > If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3= , > which uses UDP/IP, in the first place? > > IMHO, a better proposal may be to consider a [minor] (?) change to RFC > 3931, which would allow the connection used for data packets (not control > packets) to use a varying set of source ports (or, source IP addresses), > based on a hash calculation, to achieve better load-balancing over existi= ng > equipment in an IP-only core. L2TP end-system implementations would be > better off just using the "Session ID" (and "Cookie") fields as the > demultiplexor to associate incoming packets with the associated L2TP > Control Channel. In fact, it's not clear to me that existing > implementations may /already/ do this, making any "check" on the incoming > source port unnecessary for L2TP end-system implementations. > > The beauty of the above approach is: > 1) I would think that the above is most likely a change that is limited t= o > the "control channel" (software) of existing L2TP end-system > implementations. Heck, it may even be backwards compatible with existing > L2TPv3 implementations. (L2TPv3 implementors would need to comment on > that). > 2) There is a substantial added security one gets by using "Session ID" > and "Cookie" fields to ensure the received L2TPv3 packet is intended for > the identified session. Quoting from Section 8.2 of RFC 3931: > ---snip--- > L2TPv3 provides traffic separation for its VPNs via a 32-bit Session > ID in the L2TPv3 data header. When present, the L2TPv3 Cookie > (described in Section 4.1), provides an additional check to ensure > that an arriving packet is intended for the identified session. > Thus, use of a Cookie with the Session ID provides an extra guarantee > that the Session ID lookup was performed properly and that the > Session ID itself was not corrupted in transit. > ---snip--- > ... in regard to this question alone, I know the Security Area folks have= , > in the past, had /substantial/ concerns about encapsulation of MPLS over = IP > transport. In fact, this is why you see text in Section 7.6, "Security", > of RFC 4665. (There's likely similar language in other drafts that use > MPLS for transport). While I'm not sure that Security Area folks pay muc= h > attention to daily traffic on the MPLS WG mailing list, I'm fairly > confident this concern will arise if/when this draft goes to the IESG ... > 3) Finally, this approach only affects the end-systems that implement > L2TP, for tunneling of MPLS/IP, and does not require an entire industry t= o > support MPLS/UDP encapsulation in their product lines. > > -shane**** > > > > > > > Best regards, > > Xiaohu > > > >> If there was market demand for MPLS over IP, then clearly it would hav= e > been > >> more widely implemented by equipment vendors, with either MPLS over GR= E > or > >> MPLS over L2TPv3. (Where there's a will, there's a way). I would not= e > that > >> the most likely reasons this did not pan out was there are several, > practical > >> operational benefits one gets from going with native MPLS > >> encapsulation/switching within the data plane, namely: > >> - MPLS Fast Re-Route > >> - MPLS Traffic Engineering > >> ... to name, but a few. Those have tended to be quite compelling > arguments > >> to 'upgrade' network HW to support MPLS encapsulation/switching. > >> > >> -shane > >> > >> > >>> -Josh > >>> > >>> > >>> On 12/18/12 12:31 AM, "Shahram Davari" wrote: > >>> > >>>> For service provider domain, MPLS over IP is legacy and there is no > need > >>>> to improve it. > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> > >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" wrote: > >>>> > >>>>> Shahram, > >>>>> > >>>>> This draft is ONLY intended to provide a MPLS-over-IP encapsulation > >>>>> method with a better load-balancing applicability so far to those > >>>>> operators who happen to require transporting MPLS application traff= ic > >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and VXL= AN > >>>>> each have their own advocators and use cases. If you absolutely > believe > >>>>> it's meaningless of transporting MPLS application traffic across IP > >>>>> networks and therefore those existing RFCs related to MPLS over IP > >>>>> tunneling mechanisms should be moved to Historic status, please say > so. > >>>>> > >>>>> By the way, it seems this > >>>>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) i= s > >>>>> just the right thread suitable for you to make the following argume= nt > >>>>> (i.e., whether or not MPLS-based VPN is applicable to data centers)= . > I > >>>>> had thought you would speak up at that time. Sadly, surprisingly > silent > >>>>> till now. > >>>>> > >>>>> Sigh, I didn't intend to say the above otherwise. > >>>>> > >>>>> Xiaohu > >>>>> > >>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@iet= f.org] =B4=FA=B1=ED > >> S. > >>>>>> Davari > >>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34 > >>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersson > >>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; > >>>>>> mpls-chairs@tools.ietf.org > >>>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make > >>>>>> draft-xu-mpls-in-udp an > >>>>>> mpls working group document > >>>>>> > >>>>>> I don't support this draft since it has no application in today's > >>>>>> modern metro > >>>>>> and core, where MPLS is dominant, and its only practical applicati= on > >>>>>> in in data > >>>>>> center, which already is crowded with other solutions such as NVGR= E > and > >>>>>> VXLAN. > >>>>>> > >>>>>> It seems the authors are trying to bypass the NVO3 solution > selection > >>>>>> process > >>>>>> by advancing the draft in MPLS WG. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>>> > >>>>>> > >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wrote: > >>>>>> > >>>>>>> Working group, > >>>>>>> > >>>>>>> This is to start a "two week" poll on adopting > >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. > >>>>>>> Due to the holiday season this poll has been extended with one > week. > >>>>>>> > >>>>>>> Please send your comments (support/not support) to the mpls worki= ng > >>>>>>> group mailing list (mpls at ietf.org). Please give an technical > >>>>>>> motivation for your support/not support, especially if you think > that > >>>>>>> the document should not be adopted as a working group document. > >>>>>>> > >>>>>>> This poll ends January 07, 2013. > >>>>>>> > >>>>>>> There is one IPR claim against this document - > >>>>>>> https://datatracker.ietf.org/ipr/1941/ . > >>>>>>> > >>>>>>> All the active co-authors has stated on the working group mailing > list > >>>>>>> that they are not aware of any other IPR claims than those alread= y > >>>>>>> disclosed. > >>>>>>> > >>>>>>> However, up to version -03 (the document that we used for the IPR > >>>>>>> poll) > >>>>>>> Marshall Eubanks was listed as one of the authors. Marshall has > >>>>>>> discontinued all interactions with the IETF, including the author > team > >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried to > >>>>>>> contact Marshall by other means, to try get a response on the IPR > >>>>>>> poll. > >>>>>>> We have had no success in this. > >>>>>>> > >>>>>>> From version -04 the authors decided to remove Marshall as a > >>>>>>> co-author. > >>>>>>> > >>>>>>> /Loa > >>>>>>> (mpls wg co-chair) > >>>>>>> -- > >>>>>>> > >>>>>>> > >>>>>>> Loa Andersson email: > >>>>>> loa.andersson@ericsson.com > >>>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>>> +46 767 72 92 13 > >>>>>>> _______________________________________________ > >>>>>>> mpls mailing list > >>>>>>> mpls@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>>> _______________________________________________ > >>>>>> mpls mailing list > >>>>>> mpls@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>>> _______________________________________________ > >>>>> mpls mailing list > >>>>> mpls@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mpls > >>>> _______________________________________________ > >>>> mpls mailing list > >>>> mpls@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mpls > >>> > >>> > >>> This E-mail and any of its attachments may contain Time Warner Cable > >> proprietary information, which is privileged, confidential, or subject > to > >> copyright belonging to Time Warner Cable. This E-mail is intended > solely for the > >> use of the individual or entity to which it is addressed. If you are > not the > >> intended recipient of this E-mail, you are hereby notified that any > dissemination, > >> distribution, copying, or action taken in relation to the contents of > and > >> attachments to this E-mail is strictly prohibited and may be unlawful. > If you > >> have received this E-mail in error, please notify the sender > immediately and > >> permanently delete the original and any copy of this E-mail and any > printout. > >>> _______________________________________________ > >>> mpls mailing list > >>> mpls@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls > >> > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --bcaec5171a4704150b04d16233cc Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Lucy,

Sure, but it could be sa= tisfied by MPLS over L2TP over UDP, or hashing on the GRE key for MPLS over= GRE.

Cheers,
Andy


On Fri, Dec 21, 2012 at 2:27 PM, Lucy yo= ng <lucy.yong@huawei.com> wrote:

Andy,

 

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 

  3.3.2.1. LAG and ECMP=  

 <= /p>

    &nbs= p;  For performance reasons, multipath over LAG and ECMP paths SHOULD = be

    &nbs= p;  supported.

 <= /p>

    &nbs= p;  LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal

    &nbs= p;  Cost Multi Path) are commonly used techniques to perform load= -

    &nbs= p;  balancing of microflows over a set of a parallel links either at

    &nbs= p;  Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware

    &nbs= p;  implementations of LAG and ECMP uses a hash of various fields= in the

    &nbs= p;   encapsulation (outermost) header(s) (e.g. source and de= stination MAC

    &nbs= p;  addresses for non-IP traffic, source and destination IP addre= sses,

    &nbs= p;  L4 protocol, L4 source and destination port numbers, etc).

    &nbs= p;  Furthermore, hardware deployed for the underlay network(s) wi= ll be

    &nbs= p;  most often unaware of the carried, innermost L2 frames or L3 = packets

    &nbs= p;  transmitted by the TS. Thus, in order to perform fine-grained= load-

    &nbs= p;  balancing over LAG and ECMP paths in the underlying network, the

    &nbs= p;  encapsulation MUST result in sufficient entropy to exercise a= ll

    &nbs= p;  paths through several LAG/ECMP hops. The entropy information = MAY be

    &nbs= p;  inferred from the NVO3 overlay header or underlay header.<= /u>

 <= /p>

Our draft provides an advanc= ed solution in this space.

 

Lucy=

 

From: mpls-bounces@ietf.org [mailto:mpls-= bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this draft, and like S= hane, I remain unconvinced of its utility. I still don't think it has a= ny utility at all for core backbone networks - just use native MPLS, or if = you must tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I guess I could be con= vinced, but I would like to see a clear justification in the form of requir= ements from nvo3 that could only be met by this draft.

Thanks,
Andy

 <= /p>

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.= net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlep= oint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.c= om>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encapsulat= ion.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage o= f L3VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one v= endor has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent p= ast, in requesting a core router vendor to support changes to the input-key= s used in hash calculations in _existing_ hardware, already deployed (exten= sively) throughout my network.  Further, I suspect that most large network operators are savvy folks and understand= the internal architecture of their HW fairly well.  As a result, thos= e same operators know what is and is not technically possible in this regar= d.  Thus, it may be a question of "methods" necessary to convince their HW supplier(s) to make appropriate changes in = their equipment to achieve their business goals.  :-)  However, t= his may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulate the t= raffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may = /already/ do this, making any "check" on the incoming source port= unnecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm= not sure that Security Area folks pay much attention to daily traffic on t= he MPLS WG mailing list, I'm fairly confident this concern will arise i= f/when this draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a w= ay).  I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/swit= ching.
>>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com&g= t; wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application = traffic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.<= br> >>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.= org [mailto:= mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
>>>>>> mpls-chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no app= lication in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpl= s@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 


--bcaec5171a4704150b04d16233cc-- From pthaler@broadcom.com Fri Dec 21 12:49:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7392521F85C6 for ; Fri, 21 Dec 2012 12:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-1.423, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Ctn-SEr8JX for ; Fri, 21 Dec 2012 12:49:40 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8B721F85AB for ; Fri, 21 Dec 2012 12:49:40 -0800 (PST) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 21 Dec 2012 12:44:45 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 21 Dec 2012 12:49:29 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 21 Dec 2012 12:49:29 -0800 From: "Pat Thaler" To: "Lucy yong" , "Andrew G. Malis" , "Shane Amante" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN36l+PmqZvlc+g02ta7UdXSm87pgkKTYA//+PeKA= Date: Fri, 21 Dec 2012 20:49:29 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7CCA15B739W15876267-01-01 Content-Type: multipart/alternative; boundary=_000_EB9B93801780FD4CA165E0FBCB3C3E671DF206D1SJEXCHMB09corpa_ Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 20:49:42 -0000 --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF206D1SJEXCHMB09corpa_ Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 THVjeSwNCg0KSWYgeW91ciBkcmFmdCBpcyBpbnRlbmRlZCB0byBhZGRyZXNzIHRoZSBOVk8zIHJl cXVpcmVtZW50cywgdGhlbiBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiBOVk8zIGFsb25nIHdp dGggdGhlIG90aGVyIHByb3Bvc2VkIHNvbHV0aW9ucyByYXRoZXIgdGhhbiBieXBhc3NpbmcgdGhh dCBwcm9jZXNzIGJ5IHN1Ym1pdHRpbmcgaXQgdG8gTVBMUy4NCg0KVGhlIE5WTyBjaGFydGVyIHJl cXVpcmVzIHRoYXQgdGhlIHByZWxpbWluYXJ5IGFuYWx5c2lzIHdvcmsgYmUgY29tcGxldGVkIGJl Zm9yZSBjb21wbGV0aW5nIHNvbHV0aW9uczoNClRoZSBOVk8zIFdHIHdpbGwgd3JpdGUgdGhlIGZv bGxvd2luZyBpbmZvcm1hdGlvbmFsIFJGQ3MsIHdoaWNoDQptdXN0IGhhdmUgY29tcGxldGVkIFdv cmtpbmcgR3JvdXAgTGFzdCBDYWxsIGJlZm9yZSByZWNoYXJ0ZXJpbmcgY2FuIGJlDQpjb25zaWRl cmVkOg0KDQpQcm9ibGVtIFN0YXRlbWVudA0KRnJhbWV3b3JrIGRvY3VtZW50DQpDb250cm9sIHBs YW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KRGF0YSBwbGFuZSByZXF1aXJlbWVudHMgZG9jdW1l bnQNCk9wZXJhdGlvbmFsIFJlcXVpcmVtZW50cw0KR2FwIEFuYWx5c2lzDQoNCkRyaXZlbiBieSB0 aGUgcmVxdWlyZW1lbnRzIGFuZCBjb25zaXN0ZW50IHdpdGggdGhlIGdhcCBhbmFseXNpcywNCnRo ZSBOVk8zIFdHIG1heSByZXF1ZXN0IGJlaW5nIHJlY2hhcnRlcmVkIHRvIGRvY3VtZW50IHNvbHV0 aW9ucw0KY29uc2lzdGluZyBvZiBvbmUgb3IgbW9yZSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb25z IGFuZA0KY29udHJvbCBwbGFuZSBwcm90b2NvbHMgYXMgYXBwbGljYWJsZS4NCg0KQmFzZWQgb24g dGhlIE5WTzMgY2hhcnRlciwgaXQgaXMgcHJlbWF0dXJlIHRvIGNvbnNpZGVyIHNvbHV0aW9ucyBh dCB0aGlzIHBvaW50IGFuZCBzdWdnZXN0aW5nIHRoYXQgc29tZXRoaW5nIHNob3VsZCBnbyBmb3J3 YXJkIGJlY2F1c2UgaXQgc3VwcG9ydHMgb25lIGl0ZW0gaW4gYSBkcmFmdCBOVk8zIHJlcXVpcmVt ZW50cyBkb2N1bWVudCBpcyBub3QganVzdGlmaWVkLg0KDQpSZWdhcmRzLA0KUGF0DQoNCkZyb206 IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMToy NyBBTQ0KVG86IEFuZHJldyBHLiBNYWxpczsgU2hhbmUgQW1hbnRlDQpDYzogZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3Vw cG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2luZyBncm91cCBk b2N1bWVudA0KDQpBbmR5LA0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1udm8z LWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0DQoNCiAgMy4zLjIuMS4gTEFHIGFuZCBFQ01Q DQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVhc29ucywgbXVsdGlwYXRoIG92ZXIgTEFHIGFu ZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAgIHN1cHBvcnRlZC4NCg0KICAgICAgIExBRyAo TGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUgODAyLjFBWC0yMDA4XSBhbmQgRUNNUCAoRXF1 YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFyZSBjb21tb25seSB1c2VkIHRlY2huaXF1ZXMg dG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvZiBtaWNyb2Zsb3dzIG92ZXIgYSBz ZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIgYXQNCiAgICAgICBMYXllci0yIChMQUcpIG9y IExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBsb3llZCBoYXJkd2FyZQ0KICAgICAgIGltcGxl bWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNlcyBhIGhhc2ggb2YgdmFyaW91cyBmaWVsZHMg aW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24gKG91dGVybW9zdCkgaGVhZGVyKHMpIChlLmcu IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQogICAgICAgYWRkcmVzc2VzIGZvciBub24tSVAg dHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMsDQogICAgICAgTDQg cHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBldGMpLg0K ICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBkZXBsb3llZCBmb3IgdGhlIHVuZGVybGF5IG5l dHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qgb2Z0ZW4gdW5hd2FyZSBvZiB0aGUgY2Fycmll ZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBwYWNrZXRzDQogICAgICAgdHJhbnNtaXR0ZWQg YnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBwZXJmb3JtIGZpbmUtZ3JhaW5lZCBsb2FkLQ0K ICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQgRUNNUCBwYXRocyBpbiB0aGUgdW5kZXJseWlu ZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1bGF0aW9uIE1VU1QgcmVzdWx0IGluIHN1ZmZp Y2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwNCiAgICAgICBwYXRocyB0aHJvdWdoIHNldmVy YWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkgaW5mb3JtYXRpb24gTUFZIGJlDQogICAgICAg aW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5IGhlYWRlciBvciB1bmRlcmxheSBoZWFkZXIu DQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZhbmNlZCBzb2x1dGlvbiBpbiB0aGlzIHNwYWNl Lg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0K U2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMjozMiBQTQ0KVG86IFNoYW5lIEFtYW50 ZQ0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14 dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhh dmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2luZyBn cm91cCBkb2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBlYXJsaWVyIG9uIHRoaXMgZHJhZnQsIGFu ZCBsaWtlIFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCBvZiBpdHMgdXRpbGl0eS4gSSBzdGls bCBkb24ndCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkgYXQgYWxsIGZvciBjb3JlIGJhY2tib25l IG5ldHdvcmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMsIG9yIGlmIHlvdSBtdXN0IHR1bm5lbCBN UExTIG92ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVuY2Fwc3VsYXRpb25zLiBSZWdhcmRpbmcg ZGF0YSBjZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNzIEkgY291bGQgYmUgY29udmluY2VkLCBi dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1c3RpZmljYXRpb24gaW4gdGhlIGZvcm0g b2YgcmVxdWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNvdWxkIG9ubHkgYmUgbWV0IGJ5IHRoaXMg ZHJhZnQuDQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2VkLCBEZWMgMTksIDIwMTIgYXQgOTozOCBB TSwgU2hhbmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3Rs ZXBvaW50Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUw IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IFNoYW5lIEFtYW50 ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQu bmV0Pl0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KPj4gytW8/sjLOiBSb2dl cnMsIEpvc2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+ DQo+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBt YWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQNCj4+DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3No IiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29t Pj4NCj4+IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5v dCBzZWUgdGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0KPj4+IGFkZHJlc3NlcyBpbiBwcmFjdGlj ZSBhbnkgbG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFub3Ro ZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBUaGUgSUVURg0KPj4gYWxyZWFkeSBzdGFu ZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvIHN0YW5kYXJkaXplZCBN UExTDQo+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVu dCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJ J20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZiBMM1ZQTiBvdmVyIGFuDQo+PiBJUC1v bmx5IG5ldHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0KPiBUaGFuayB5b3UgZm9yIHRlbGxpbmcg dXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXIgSVAgaW4gYXQgbGVh c3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZl cnkgdmFsdWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8g YXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRvZGF5J3MgU1AgbmV0d29ya3MuDQo+DQo+ PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMN Cj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGlu IHRoZSAyMDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50cyBy ZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBiZQ0KPj4gY2FycmllZCBvdmVy IEwyVFB2Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFz dCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4gSVBWUE4ncyBvdmVyIEwyVFB2MzoNCj4+ IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUv Y3NnbDN2cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGlu Zm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBBTkQgb3RoZXIgZHJhZnRzLCB0 aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgU2Vzc2lv biBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBH UkUgaGVhZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQwXSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRl ZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFyLg0KRldJVywgSSBoYXZlIGhhZCBzdWNj ZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4gcmVxdWVzdGluZyBhIGNvcmUg cm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBp biBoYXNoIGNhbGN1bGF0aW9ucyBpbiBfZXhpc3RpbmdfIGhhcmR3YXJlLCBhbHJlYWR5IGRlcGxv eWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBuZXR3b3JrLiAgRnVydGhlciwgSSBzdXNw ZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3MgYW5k IHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWlybHkg d2VsbC4gIEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5k IGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzIHJlZ2FyZC4gIFRodXMsIGl0IG1h eSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhlaXIg SFcgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlw bWVudCB0byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlz IG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxvdy4NCg0KDQo+IEluIGNvbnRy YXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mIGJh bGFuY2luZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1 cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlv biwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkgb2YgbW9z dCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmlu ZyBhbnkgY2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2YgdGhp cyBkcmFmdC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBub3QgZW5jYXBzdWxhdGUg dGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoIHVzZXMgVURQL0lQLCBpbiB0aGUgZmly c3QgcGxhY2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBh IFttaW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwgd2hpY2ggd291bGQgYWxsb3cgdGhlIGNv bm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbCBwYWNrZXRzKSB0byB1 c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2Vz KSwgYmFzZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2FkLWJh bGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbiBJUC1vbmx5IGNvcmUuICBMMlRQ IGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmYganVzdCB1c2lu ZyB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBs ZXhvciB0byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwy VFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLCBtYWtpbmcgYW55 ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQ IGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBh cHByb2FjaCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtl bHkgYSBjaGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRoZSAiY29udHJvbCBjaGFubmVsIiAoc29m dHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMuICBIZWNr LCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2 MyBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNv bW1lbnQgb24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5 IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBhbmQgIkNvb2tpZSIgZmllbGRzIHRvIGVu c3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50 aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCi0t LXNuaXAtLS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFmZmljIHNlcGFyYXRpb24gZm9yIGl0cyBW UE5zIHZpYSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVy LiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KICAgKGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8gZW5zdXJlDQogICB0aGF0 IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lv bi4NCiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVz IGFuIGV4dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBl cmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAgIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBu b3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlwLS0tDQouLi4gaW4gcmVnYXJkIHRvIHRo aXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYSBmb2xrcyBoYXZlLCBp biB0aGUgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlv biBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNl ZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBSRkMgNDY2NS4gIChUaGVyZSdz IGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZv ciB0cmFuc3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xr cyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBvbiB0aGUgTVBMUyBXRyBtYWls aW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsIGFyaXNlIGlm L3doZW4gdGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KMykgRmluYWxseSwgdGhpcyBh cHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1wbGVtZW50IEwyVFAs IGZvciB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJl IGluZHVzdHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9k dWN0IGxpbmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+ DQo+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVuIGNs ZWFybHkgaXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3JlIHdpZGVseSBpbXBsZW1lbnRlZCBieSBl cXVpcG1lbnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBMUyBvdmVyIEdSRSBvcg0KPj4gTVBMUyBv dmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUncyBhIHdheSkuICBJIHdv dWxkIG5vdGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBh biBvdXQgd2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4+IG9wZXJhdGlvbmFsIGJl bmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBuYXRpdmUgTVBMUw0KPj4gZW5jYXBzdWxh dGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+PiAtIE1QTFMg RmFzdCBSZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+IC4uLiB0byBu YW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5n IGFyZ3VtZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVu Y2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1zaGFuZQ0KPj4NCj4+DQo+Pj4gLUpvc2gN Cj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRh dmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+PiB3cm90ZToNCj4+ Pg0KPj4+PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdh Y3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4+Pj4NCj4+Pj4g UmVnYXJkcywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBEZWMgMTcsIDIwMTIs IGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlh b2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFNoYWhyYW0sDQo+Pj4+Pg0KPj4+ Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAg ZW5jYXBzdWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcg YXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVu IHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPj4+Pj4g YWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZH UkUgYW5kIFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVz ZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj4+Pj4gaXQncyBtZWFuaW5nbGVz cyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUA0KPj4+ Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8g TVBMUyBvdmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQg dG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNvLg0KPj4+Pj4NCj4+Pj4+IEJ5IHRoZSB3 YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+Pj4+PiBqdXN0IHRoZSByaWdo dCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgYXJndW1lbnQN Cj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxl IHRvIGRhdGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1 cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2lsZW50DQo+Pj4+PiB0aWxsIG5v dy4NCj4+Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBv dGhlcndpc2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0t08q8/tSt vP4tLS0tLQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBTLg0KPj4+Pj4+IERhdmFyaQ0KPj4+Pj4+ ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVy c3Nvbg0KPj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+Pj4+PiDW98ziOiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+Pj4+Pj4gZHJhZnQt eHUtbXBscy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+ Pj4+Pg0KPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBh cHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+Pj4+Pj4gYW5kIGNv cmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGlj YXRpb24NCj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5IGlz IGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBOVkdSRSBhbmQNCj4+Pj4+PiBW WExBTi4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8g YnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPj4+Pj4+IHByb2Nlc3MNCj4+Pj4+ PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDE0LCAy MDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+ Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KPj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVl biBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+ Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5v cmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPj4+ Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywg MjAxMy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRo aXMgZG9jdW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8x OTQxLyAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0 YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gdGhhdCB0aGV5 IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5 DQo+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVy c2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFINCj4+Pj4+Pj4g cG9sbCkNCj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUg YXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJhY3Rp b25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0NCj4+Pj4+Pj4gb2Yg ZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJp ZWQgdG8NCj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdl dCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbC4NCj4+Pj4+Pj4gV2UgaGF2ZSBo YWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcm9tIHZlcnNpb24gLTA0 IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxsIGFzIGENCj4+Pj4+Pj4gY28t YXV0aG9yLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWly KQ0KPj4+Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nz b24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj4gU3IgU3Ry YXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzps b2FAcGkubnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAg cGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2JTIwMTAlMjA3MTclMjA1MiUyMDEzPg0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3Njcg NzIgOTIgMTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5MiUyMDEzPg0KPj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBtcGxzIG1h aWxpbmcgbGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+IGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+PiBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtl biBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kDQo+PiBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdQ0KPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4gcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1w bHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMg bWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_EB9B93801780FD4CA165E0FBCB3C3E671DF206D1SJEXCHMB09corpa_ Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable

Lucy,

 <= /p>

If your draft is intended= to address the NVO3 requirements, then it should be considered in NVO3 alo= ng with the other proposed solutions rather than bypassing that process by submitting it to MPLS.

 <= /p>

The NVO charter requires = that the preliminary analysis work be completed before completing solutions= :

The NVO3 WG will write the following info= rmational RFCs, which
must have completed Working Group Last Call before rechartering can be
considered:

Problem Statement
Framework document
Control plane requirements document
Data plane requirements document
Operational Requirements
Gap Analysis

Driven by the requirements and consistent with the gap analysis,
the NVO3 WG may request being rechartered to document solutions
consisting of one or more data plane encapsulations and
control plane protocols as applicable.

 <= /p>

Based on the NVO3 charter= , it is premature to consider solutions at this point and suggesting that s= omething should go forward because it supports one item in a draft NVO3 requirements document is not justified.<= /p>

 <= /p>

Regards,

Pat

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Friday, December 21, 2012 11:27 AM
To: Andrew G. Malis; Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@= tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

Andy,

 <= /p>

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 <= /p>

  3.3.2.1. LAG and ECMP=  

 

    &nbs= p;  For performance reasons, multipath over LAG and ECMP paths SHOULD = be

    &nbs= p;  supported.

 

    &nbs= p;  LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal

    &nbs= p;  Cost Multi Path) are commonly used techniques to perform load= -

    &nbs= p;  balancing of microflows over a set of a parallel links either at

    &nbs= p;  Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware

    &nbs= p;  implementations of LAG and ECMP uses a hash of various fields= in the

    &nbs= p;   encapsulation (outermost) header(s) (e.g. source and de= stination MAC

    &nbs= p;  addresses for non-IP traffic, source and destination IP addre= sses,

    &nbs= p;  L4 protocol, L4 source and destination port numbers, etc).

    &nbs= p;  Furthermore, hardware deployed for the underlay network(s) wi= ll be

    &nbs= p;  most often unaware of the carried, innermost L2 frames or L3 = packets

    &nbs= p;  transmitted by the TS. Thus, in order to perform fine-grained= load-

    &nbs= p;  balancing over LAG and ECMP paths in the underlying network, the

    &nbs= p;  encapsulation MUST result in sufficient entropy to exercise a= ll

    &nbs= p;  paths through several LAG/ECMP hops. The entropy information = MAY be

    &nbs= p;  inferred from the NVO3 overlay header or underlay header.

 

Our draft provides an advanc= ed solution in this space.

 <= /p>

Lucy

 <= /p>

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-= mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this draft, and like Shane= , I remain unconvinced of its utility. I still don't think it has any utili= ty at all for core backbone networks - just use native MPLS, or if you must= tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I guess I could be con= vinced, but I would like to see a clear justification in the form of requir= ements from nvo3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.= net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlepoint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent p= ast, in requesting a core router vendor to support changes to the input-key= s used in hash calculations in _existing_ hardware, already deployed (exten= sively) throughout my network.  Further, I suspect that most large network operators are savvy folks and understand= the internal architecture of their HW fairly well.  As a result, thos= e same operators know what is and is not technically possible in this regar= d.  Thus, it may be a question of "methods" necessary to convince their HW supplier(s) to make appropriate changes in = their equipment to achieve their business goals.  :-)  However, t= his may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulate the t= raffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org;
>>>>>> mpls= -chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.= andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46= 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org=
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_EB9B93801780FD4CA165E0FBCB3C3E671DF206D1SJEXCHMB09corpa_-- From lucy.yong@huawei.com Fri Dec 21 13:38:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6D21F85AB for ; Fri, 21 Dec 2012 13:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.684 X-Spam-Level: X-Spam-Status: No, score=-3.684 tagged_above=-999 required=5 tests=[AWL=-2.228, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdvDiWc7Btyv for ; Fri, 21 Dec 2012 13:38:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 753D121F87C6 for ; Fri, 21 Dec 2012 13:38:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOB32299; Fri, 21 Dec 2012 21:38:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 21:37:53 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 21:38:10 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 13:38:06 -0800 From: Lucy yong To: "Andrew G. Malis" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3baG6lNZW4xfyUOAvM96G0N/cZggt7EAgANl+4D//4fyUIAAjp+A//+WK3A= Date: Fri, 21 Dec 2012 21:38:05 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864E57@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.159] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44864E57dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:38:18 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44864E57dfweml505mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WWVzLCBidXQgcmVxdWlyZSBlaXRoZXIgaW1wbGVtZW50IEwyVFAgb3ZlcmxheSBvciB0byB1cGRh dGUgYWxsIHRoZSBuZXR3b3JrIGRldmljZXMuDQoNCkx1Y3kNCg0KRnJvbTogQW5kcmV3IEcuIE1h bGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDIx LCAyMDEyIDE6NTMgUE0NClRvOiBMdWN5IHlvbmcNCkNjOiBTaGFuZSBBbWFudGU7IGRyYWZ0LXh1 LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZl IHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbiBtcGxzIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQNCg0KTHVjeSwNClN1cmUsIGJ1dCBpdCBjb3VsZCBiZSBzYXRpc2ZpZWQgYnkg TVBMUyBvdmVyIEwyVFAgb3ZlciBVRFAsIG9yIGhhc2hpbmcgb24gdGhlIEdSRSBrZXkgZm9yIE1Q TFMgb3ZlciBHUkUuDQpDaGVlcnMsDQpBbmR5DQoNCk9uIEZyaSwgRGVjIDIxLCAyMDEyIGF0IDI6 MjcgUE0sIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0Bo dWF3ZWkuY29tPj4gd3JvdGU6DQpBbmR5LA0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gZHJhZnQt aWV0Zi1udm8zLWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0DQoNCiAgMy4zLjIuMS4gTEFH IGFuZCBFQ01QDQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVhc29ucywgbXVsdGlwYXRoIG92 ZXIgTEFHIGFuZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAgIHN1cHBvcnRlZC4NCg0KICAg ICAgIExBRyAoTGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUgODAyLjFBWC0yMDA4XSBhbmQg RUNNUCAoRXF1YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFyZSBjb21tb25seSB1c2VkIHRl Y2huaXF1ZXMgdG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvZiBtaWNyb2Zsb3dz IG92ZXIgYSBzZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIgYXQNCiAgICAgICBMYXllci0y IChMQUcpIG9yIExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBsb3llZCBoYXJkd2FyZQ0KICAg ICAgIGltcGxlbWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNlcyBhIGhhc2ggb2YgdmFyaW91 cyBmaWVsZHMgaW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24gKG91dGVybW9zdCkgaGVhZGVy KHMpIChlLmcuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQogICAgICAgYWRkcmVzc2VzIGZv ciBub24tSVAgdHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMsDQog ICAgICAgTDQgcHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCBudW1iZXJz LCBldGMpLg0KICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBkZXBsb3llZCBmb3IgdGhlIHVu ZGVybGF5IG5ldHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qgb2Z0ZW4gdW5hd2FyZSBvZiB0 aGUgY2FycmllZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBwYWNrZXRzDQogICAgICAgdHJh bnNtaXR0ZWQgYnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBwZXJmb3JtIGZpbmUtZ3JhaW5l ZCBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQgRUNNUCBwYXRocyBpbiB0aGUg dW5kZXJseWluZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1bGF0aW9uIE1VU1QgcmVzdWx0 IGluIHN1ZmZpY2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwNCiAgICAgICBwYXRocyB0aHJv dWdoIHNldmVyYWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkgaW5mb3JtYXRpb24gTUFZIGJl DQogICAgICAgaW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5IGhlYWRlciBvciB1bmRlcmxh eSBoZWFkZXIuDQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZhbmNlZCBzb2x1dGlvbiBpbiB0 aGlzIHNwYWNlLg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0K U2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMjozMiBQTQ0KVG86IFNoYW5lIEFtYW50 ZQ0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14 dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhh dmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2luZyBn cm91cCBkb2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBlYXJsaWVyIG9uIHRoaXMgZHJhZnQsIGFu ZCBsaWtlIFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCBvZiBpdHMgdXRpbGl0eS4gSSBzdGls bCBkb24ndCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkgYXQgYWxsIGZvciBjb3JlIGJhY2tib25l IG5ldHdvcmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMsIG9yIGlmIHlvdSBtdXN0IHR1bm5lbCBN UExTIG92ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVuY2Fwc3VsYXRpb25zLiBSZWdhcmRpbmcg ZGF0YSBjZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNzIEkgY291bGQgYmUgY29udmluY2VkLCBi dXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1c3RpZmljYXRpb24gaW4gdGhlIGZvcm0g b2YgcmVxdWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNvdWxkIG9ubHkgYmUgbWV0IGJ5IHRoaXMg ZHJhZnQuDQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2VkLCBEZWMgMTksIDIwMTIgYXQgOTozOCBB TSwgU2hhbmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3Rs ZXBvaW50Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUw IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IFNoYW5lIEFtYW50 ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQu bmV0Pl0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KPj4gytW8/sjLOiBSb2dl cnMsIEpvc2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+ DQo+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBt YWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1l bnQNCj4+DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3No IiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29t Pj4NCj4+IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5v dCBzZWUgdGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0KPj4+IGFkZHJlc3NlcyBpbiBwcmFjdGlj ZSBhbnkgbG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFub3Ro ZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBUaGUgSUVURg0KPj4gYWxyZWFkeSBzdGFu ZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvIHN0YW5kYXJkaXplZCBN UExTDQo+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVu dCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJ J20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZiBMM1ZQTiBvdmVyIGFuDQo+PiBJUC1v bmx5IG5ldHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0KPiBUaGFuayB5b3UgZm9yIHRlbGxpbmcg dXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXIgSVAgaW4gYXQgbGVh c3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZl cnkgdmFsdWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8g YXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRvZGF5J3MgU1AgbmV0d29ya3MuDQo+DQo+ PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMN Cj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGlu IHRoZSAyMDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50cyBy ZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBiZQ0KPj4gY2FycmllZCBvdmVy IEwyVFB2Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFz dCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4gSVBWUE4ncyBvdmVyIEwyVFB2MzoNCj4+ IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUv Y3NnbDN2cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGlu Zm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBBTkQgb3RoZXIgZHJhZnRzLCB0 aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgU2Vzc2lv biBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBH UkUgaGVhZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQwXSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRl ZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFyLg0KRldJVywgSSBoYXZlIGhhZCBzdWNj ZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4gcmVxdWVzdGluZyBhIGNvcmUg cm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBp biBoYXNoIGNhbGN1bGF0aW9ucyBpbiBfZXhpc3RpbmdfIGhhcmR3YXJlLCBhbHJlYWR5IGRlcGxv eWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBuZXR3b3JrLiAgRnVydGhlciwgSSBzdXNw ZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3MgYW5k IHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWlybHkg d2VsbC4gIEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5k IGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzIHJlZ2FyZC4gIFRodXMsIGl0IG1h eSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhlaXIg SFcgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlw bWVudCB0byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlz IG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxvdy4NCg0KDQo+IEluIGNvbnRy YXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mIGJh bGFuY2luZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1 cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlv biwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkgb2YgbW9z dCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmlu ZyBhbnkgY2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2YgdGhp cyBkcmFmdC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBub3QgZW5jYXBzdWxhdGUg dGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoIHVzZXMgVURQL0lQLCBpbiB0aGUgZmly c3QgcGxhY2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBh IFttaW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwgd2hpY2ggd291bGQgYWxsb3cgdGhlIGNv bm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbCBwYWNrZXRzKSB0byB1 c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2Vz KSwgYmFzZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2FkLWJh bGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbiBJUC1vbmx5IGNvcmUuICBMMlRQ IGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmYganVzdCB1c2lu ZyB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBs ZXhvciB0byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwy VFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLCBtYWtpbmcgYW55 ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQ IGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBh cHByb2FjaCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtl bHkgYSBjaGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRoZSAiY29udHJvbCBjaGFubmVsIiAoc29m dHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMuICBIZWNr LCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2 MyBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNv bW1lbnQgb24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5 IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBhbmQgIkNvb2tpZSIgZmllbGRzIHRvIGVu c3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50 aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCi0t LXNuaXAtLS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFmZmljIHNlcGFyYXRpb24gZm9yIGl0cyBW UE5zIHZpYSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVy LiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KICAgKGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8gZW5zdXJlDQogICB0aGF0 IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lv bi4NCiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVz IGFuIGV4dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBl cmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAgIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBu b3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlwLS0tDQouLi4gaW4gcmVnYXJkIHRvIHRo aXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYSBmb2xrcyBoYXZlLCBp biB0aGUgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlv biBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNl ZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBSRkMgNDY2NS4gIChUaGVyZSdz IGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZv ciB0cmFuc3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xr cyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBvbiB0aGUgTVBMUyBXRyBtYWls aW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsIGFyaXNlIGlm L3doZW4gdGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KMykgRmluYWxseSwgdGhpcyBh cHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1wbGVtZW50IEwyVFAs IGZvciB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJl IGluZHVzdHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9k dWN0IGxpbmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+ DQo+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVuIGNs ZWFybHkgaXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3JlIHdpZGVseSBpbXBsZW1lbnRlZCBieSBl cXVpcG1lbnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBMUyBvdmVyIEdSRSBvcg0KPj4gTVBMUyBv dmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUncyBhIHdheSkuICBJIHdv dWxkIG5vdGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBh biBvdXQgd2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4+IG9wZXJhdGlvbmFsIGJl bmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBuYXRpdmUgTVBMUw0KPj4gZW5jYXBzdWxh dGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+PiAtIE1QTFMg RmFzdCBSZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+IC4uLiB0byBu YW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5n IGFyZ3VtZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVu Y2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1zaGFuZQ0KPj4NCj4+DQo+Pj4gLUpvc2gN Cj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRh dmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+PiB3cm90ZToNCj4+ Pg0KPj4+PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdh Y3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4+Pj4NCj4+Pj4g UmVnYXJkcywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBEZWMgMTcsIDIwMTIs IGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlh b2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFNoYWhyYW0sDQo+Pj4+Pg0KPj4+ Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAg ZW5jYXBzdWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcg YXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVu IHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPj4+Pj4g YWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZH UkUgYW5kIFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVz ZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj4+Pj4gaXQncyBtZWFuaW5nbGVz cyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUA0KPj4+ Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8g TVBMUyBvdmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQg dG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNvLg0KPj4+Pj4NCj4+Pj4+IEJ5IHRoZSB3 YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+Pj4+PiBqdXN0IHRoZSByaWdo dCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgYXJndW1lbnQN Cj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxl IHRvIGRhdGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1 cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2lsZW50DQo+Pj4+PiB0aWxsIG5v dy4NCj4+Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBv dGhlcndpc2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0t08q8/tSt vP4tLS0tLQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBTLg0KPj4+Pj4+IERhdmFyaQ0KPj4+Pj4+ ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVy c3Nvbg0KPj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+Pj4+PiDW98ziOiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+Pj4+Pj4gZHJhZnQt eHUtbXBscy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+ Pj4+Pg0KPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBh cHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+Pj4+Pj4gYW5kIGNv cmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGlj YXRpb24NCj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5IGlz IGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBOVkdSRSBhbmQNCj4+Pj4+PiBW WExBTi4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8g YnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPj4+Pj4+IHByb2Nlc3MNCj4+Pj4+ PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDE0LCAy MDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+ Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KPj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVl biBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+ Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5v cmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPj4+ Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywg MjAxMy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRo aXMgZG9jdW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8x OTQxLyAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0 YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gdGhhdCB0aGV5 IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5 DQo+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVy c2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFINCj4+Pj4+Pj4g cG9sbCkNCj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUg YXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJhY3Rp b25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0NCj4+Pj4+Pj4gb2Yg ZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJp ZWQgdG8NCj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdl dCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbC4NCj4+Pj4+Pj4gV2UgaGF2ZSBo YWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcm9tIHZlcnNpb24gLTA0 IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxsIGFzIGENCj4+Pj4+Pj4gY28t YXV0aG9yLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWly KQ0KPj4+Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nz b24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj4gU3IgU3Ry YXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzps b2FAcGkubnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAg cGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2JTIwMTAlMjA3MTclMjA1MiUyMDEzPg0K Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3Njcg NzIgOTIgMTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5MiUyMDEzPg0KPj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBtcGxzIG1h aWxpbmcgbGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0K Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+IGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+PiBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtl biBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kDQo+PiBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdQ0KPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4gcGVybWFuZW50bHkgZGVsZXRlIHRoZSBv cmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1w bHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Cj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+DQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMg bWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --_000_2691CE0099834E4A9C5044EEC662BB9D44864E57dfweml505mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yes, but require either i= mplement L2TP overlay or to update all the network devices.

 <= /p>

Lucy

 <= /p>

From: Andrew G= . Malis [mailto:agmalis@gmail.com]
Sent: Friday, December 21, 2012 1:53 PM
To: Lucy yong
Cc: Shane Amante; draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org= ; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

Lucy,

Sure, but it could be= satisfied by MPLS over L2TP over UDP, or hashing on the GRE key for MPLS o= ver GRE.

Cheers,

Andy

 

On Fri, Dec 21, 2012 at 2:27 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Andy,

 

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 

 = 3.3.2.1. LAG and ECMP 

 =

 =       For performance reasons, multipath over LAG = and ECMP paths SHOULD be

 =       supported.

 =

 =       LAG (Link Aggregation Group) [IEEE 802.1AX-2= 008] and ECMP (Equal

 =       Cost Multi Path) are commonly used tech= niques to perform load-

 =       balancing of microflows over a set of a para= llel links either at

 =       Layer-2 (LAG) or Layer-3 (ECMP). Existi= ng deployed hardware

 =       implementations of LAG and ECMP uses a = hash of various fields in the

 =        encapsulation (outermost) header(= s) (e.g. source and destination MAC

 =       addresses for non-IP traffic, source an= d destination IP addresses,

 =       L4 protocol, L4 source and destination = port numbers, etc).

 =       Furthermore, hardware deployed for the = underlay network(s) will be

 =       most often unaware of the carried, inne= rmost L2 frames or L3 packets

 =       transmitted by the TS. Thus, in order t= o perform fine-grained load-

 =       balancing over LAG and ECMP paths in the und= erlying network, the

 =       encapsulation MUST result in sufficient= entropy to exercise all

 =       paths through several LAG/ECMP hops. Th= e entropy information MAY be

 =       inferred from the NVO3 overlay header o= r underlay header.

 =

Our dr= aft provides an advanced solution in this space.

 

Lucy

 

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this draft, and like Shane, I remain unc= onvinced of its utility. I still don't think it has any utility at all for = core backbone networks - just use native MPLS, or if you must tunnel MPLS over IP, the GRE or L2TPv3 encapsulations= . Regarding data center applications, I guess I could be convinced, but I w= ould like to see a clear justification in the form of requirements from nvo= 3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.net> wr= ote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlep= oint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.c= om>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent past, in reques= ting a core router vendor to support changes to the input-keys used in hash= calculations in _existing_ hardware, already deployed (extensively) throughout my network.  Further, I sus= pect that most large network operators are savvy folks and understand the i= nternal architecture of their HW fairly well.  As a result, those same= operators know what is and is not technically possible in this regard.  Thus, it may be a question of "methods= " necessary to convince their HW supplier(s) to make appropriate chang= es in their equipment to achieve their business goals.  :-)  Howe= ver, this may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulate the traffic in MPLS= /L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com&g= t; wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
>>>>>> mpls-chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpl= s@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44864E57dfweml505mbx_-- From lucy.yong@huawei.com Fri Dec 21 13:55:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2DB21F8583 for ; Fri, 21 Dec 2012 13:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h66oTalIWfjp for ; Fri, 21 Dec 2012 13:55:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD121F8514 for ; Fri, 21 Dec 2012 13:55:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOB32926; Fri, 21 Dec 2012 21:55:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 21:55:03 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 21:55:20 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 13:55:12 -0800 From: Lucy yong To: "S. Davari" , Xuxiaohu , Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiaAqA//99ORCAAJLQgIAAjTqAgABoZ4CAAF2yAA== Date: Fri, 21 Dec 2012 21:55:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> In-Reply-To: <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.86.159] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44864E6Bdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 21:55:31 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44864E6Bdfweml505mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2hhaHJhbSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IFMuIERhdmFyaSBbbWFpbHRv OmRhdmFyaXNoQHlhaG9vLmNvbV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjEsIDIwMTIgMjox MCBBTQ0KVG86IFh1eGlhb2h1OyBTaGFocmFtIERhdmFyaTsgTHVjeSB5b25nDQpDYzogZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92 ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KDQpIaSwNCg0KSSB0aGluayB3ZSBhcmUgaW4g YSB2aWNpb3VzIGN5Y2xlLiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggbmV0d29yayBv cGVyYXRvciBpcyBhc2tpbmcgZm9yIE1QTFMgb3ZlciBVRFAgYW5kIHdoYXQgaXMgdGhlIGFwcGxp Y2F0aW9uLg0KW0x1Y3ldIGl0IGlzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuDQpBbHNvIGhvdyBk byB5b3UgcGxhbiB0byBhZGRyZXNzIHRoZSBNUExTIE11bHRpY2FzdCAod2hpY2ggaXMgcHJvYmFi bHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBpbXByb3ZpbmcgdGhlIGxvYWQgYmFsYW5jaW5nKSwgZ2l2 ZW4gdGhhdCBSRkM0MDIzIGRvZXMgbm90IHN1cHBvcnQgTXVsdGljYXN0Lg0KW0x1Y3ldIE1QTFMg Q2xpZW50IExheWVyIGlzIHJlc3BvbnNpYmxlIHRvIG1hcCBtdWx0aWNhc3QgdHJhZmZpYyB0byB1 bmRlcmx5aW5nIHRyYW5zcG9ydCwgd2hpY2ggaXMgc3BlY2lmaWVkIGluIEVWUE4gYW5kIElQIFZQ Ti4gVGhpcyBwcm9wb3NhbCBqdXN0IHJlcXVlc3RzIGluZ3Jlc3MgUEUgdG8gZmlsbCB0aGUgZmxv dyBlbnRyb3B5IGludG8gVURQIHNvdXJjZSBwb3J0LCBpbiB3aGljaCB0aGUgZmxvdyBjYW4gYmUg dW5pY2FzdCBvciBtdWx0aWNhc3QuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpUaGFua3MsDQpT aGFocmFtDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KVG86IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJv YWRjb20uY29tPjsgTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4NCkNjOiAiZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC14dS1tcGxzLWluLXVkcEB0b29s cy5pZXRmLm9yZz47ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz47ICJtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZyIgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU2VudDogVGh1 cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDU6NTY6MjMgUE0NClN1YmplY3Q6IFJlOiBbbXBsc10g TVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQoNCg0KDQo+ IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBtcGxzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dIOS7o+ihqA0KPiBTaGFocmFtIERh dmFyaQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMuaciDIx5pelIDE6MzENCj4g5pS25Lu25Lq6 OiBMdWN5IHlvbmcNCj4g5oqE6YCBOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9y ZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiDkuLvpopg6IFJlOiBbbXBsc10g TVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQo+DQo+IFBs ZWFzZSBkb24ndCBtaXggdXAgdGhpbmdzLiBUaGUgTVBMUyBwcm90b2NvbCBkZXNpZ24gSSBhZ3Jl ZSBtdXN0IGJlIGRvbmUgYnkNCj4gTVBMUyBXRy4gQnV0IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVy IHlvdXIgcHJvcG9zYWwgbWVldHMgdGhlIG5ldHdvcmsNCj4gdmlydHVhbGl6YXRpb24gcmVxdWly ZW1lbnRzLg0KDQpDYW4geW91IHRlbGwgdXMgd2hlcmUgTVBMUy1pbi1HUkUvSVAgW1JGQzQwMjNd IGFuZCBvdGhlciBNUExTIG92ZXIgSVAgZW5jYXBzdWxhdGlvbiBtZWNoYW5pc21zIGhhdmUgYmVl biBkaXNjdXNzZWQgYmVmb3JlPw0KDQpTaW5jZSBNUExTLWluLVVEUCBpcyBqdXN0IGludGVuZGVk IHRvIGJlIHVzZWQgaW4gdGhlIHNjZW5hcmlvcyB3aGVyZSBNUExTLWluLUdSRS9JUCBoYXMgYmVl biB1c2VkIGFuZCBpcyB0byBiZSB1c2VkLCBNUExTLWluLVVEUCBzaG91bGQgYmUgZGlzY3Vzc2Vk IGluIHRoZSBzYW1lIFdHIHdoZXJlIE1QTFMtaW4tR1JFL0lQIGhhcyBiZWVuIGRpc2N1c3NlZC4N Cg0KWGlhb2h1DQoNCj4gVGhlIE5WTzMgdGFzayBpcyB0byBkb2N1bWVudCB0aGUgaXNzdWVzLCBy ZXF1aXJlbWVudHMgYW5kIGZyYW1ld29yayBmb3INCj4gTnZPMy4gVGhlbiBpZiBNUExTIG92ZXIg SVAgbG9va3MgbGlrZSBhIHN1aXRhYmxlIHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlDQo+IHJlcXVp cmVtZW50cyBzdWNoIGFzIHRoZSBzY2FsZSwgbW9iaWxpdHksIGV0YywgdGhlbiB0aGV5IHdpbGwg YXNrIE1QTFMgV0cgZm9yDQo+IHByb3RvY29sIGRlc2lnbi4NCj4NCj4gU28gYmVmb3JlIHByb2Nl ZWRpbmcgdGhpcyBkcmFmdCwgSSB0aGluayB5b3Ugc2hvdWxkIHRha2UgaXQgdG8gTlZPMyBXRyBh bmQNCj4gY29udmluY2UgdGhlbSB0aGlzIHNvbHV0aW9uIG1lZXRzIHRoZWlyIHJlcXVpcmVtZW50 cyBhbmQgZnJhbWV3b3JrLg0KPg0KPiBXZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVt YmVyIG9mIHNvbHV0aW9ucyBmb3IgdGhlIHNhbWUgcHJvYmxlbSwgZG8NCj4gd2U/DQo+DQo+IC1T aGFocmFtDQo+DQo+DQo+DQo+IFJlZ2FyZHMsDQo+IFNoYWhyYW0NCj4NCj4NCj4gT24gRGVjIDIw LCAyMDEyLCBhdCA4OjU2IEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFp bHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+ID4gTmV0d29yayB2aXJ0dWFs aXphdGlvbiBvdmVybGF5IGlzIGRpc2N1c3NlZCB1bmRlciBudm8zIFdHLiBUaGlzIGRvZXMgbm90 DQo+IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEg dW5kZXJseWluZyBuZXR3b3JrIG9yIGENCj4gbmV3IHByb3RvY29sIGZvciBhIG92ZXJsYXkgbmV0 d29yay4gSW4gZmFjdCwgcGVvcGxlIHRoZXJlIGFpbSBvbiBsZXZlcmFnZQ0KPiBzdGFuZGFyZCBu ZXR3b3JrIHByb3RvY29scyB0byBhY2NvbXBsaXNoIHRoZW0uIElNTzogdGhlc2UgZXhwYW5zaW9u cyBvbiBhbg0KPiBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBv dXQgaW4gdGhlIHByb3RvY29sIFdHIGdyb3VwLCBpdA0KPiBzaG91bGQgbm90IGdpdmUgbnZvMyBX RyBmcmVlIHJpZ2h0IHRvIGVuaGFuY2UgdGhlc2UgcHJvdG9jb2xzLiBGb3IgYSBicmFuZA0KPiBu ZXcgcHJvdG9jb2wgZm9yIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSwgbnZvMyBXRyBt YXkgYmUgdGhlIHBsYWNlIHRvDQo+IHN0YXJ0Lg0KPiA+DQo+ID4gTHVjeQ0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWls dG86ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT5dDQo+ID4+ IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiAxMDozNCBBTQ0KPiA+PiBUbzogTHVj eSB5b25nDQo+ID4+IENjOiBTaGFuZSBBbWFudGU7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPiA+PiBtcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+IFN1Ympl Y3Q6IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBu ZXR3b3JrDQo+ID4+DQo+ID4+IE5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBtdXN0IGJl IGRpc2N1c3NlZCBhbmQgY29uc2VudGVkICBpbiBOVk8zDQo+ID4+IFdHLg0KPiA+Pg0KPiA+PiBS ZWdhcmRzLA0KPiA+PiBTaGFocmFtDQo+ID4+DQo+ID4+DQo+ID4+IE9uIERlYyAyMCwgMjAxMiwg YXQgNzozOSBBTSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5 LnlvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSGkgU2hhbmUsDQo+ID4+Pg0K PiA+Pj4gSSB1bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBzdWxhdGlv biB0byBhbiBleGlzdGluZw0KPiA+PiBuZXR3b3JrLg0KPiA+Pj4NCj4gPj4+IEhvd2V2ZXIsIE1Q TFMtaW4tVURQIGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9NUExTDQo+ ID4+IG5ldHdvcmsgYXQgYWxsLg0KPiA+Pj4gTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMg Y2xpZW50IGxheWVyIHRvIGJlIGRlY291cGxlZCBmcm9tIE1QTFMNCj4gPj4gc2VydmVyIGxheWVy IGFuZCB1c2UgTVBMUyBjbGllbnQgbGF5ZXIgYXMgb3ZlcmxheSBuZXR3b3JrIGFuZCBhbiBJR1Ag YXMNCj4gPj4gYSB1bmRlcmx5aW5nIG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNh dGlvbiBpcyBmb3IgREMuIFlvdSBtYXkNCj4gPj4gYXJndWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3 aGljaCBpcyBmb3IgTVBMUyBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcNCj4gPj4gbmV0d29y ay4gV2UgaGF2ZSBwb2ludGVkIG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJvdXRlcnMg aW4gREMNCj4gPj4gYmFyZWx5IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCBN UExTLWluLUdSRSBhcmUgYmFyZWx5IHVzZWQNCj4gPj4gaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0 IG9mIHJvdXRlcnMgaW4gREMgcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkDQo+ID4+IGJhbGFu Y2luZyBub3cuDQo+ID4+Pg0KPiA+Pj4gRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZl LCB0aGUgVURQIGVuY2Fwc3VsYXRpb24gaGFzDQo+ID4+IGFkdmFudGFnZSBvdmVyIEdSRSBlbmNh cHN1bGF0aW9uIHRvby4gSW4gVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZQ0KPiA+PiBoZWFk ZXIgZGVjb3VwbGVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwg aS5lLiBvdXRlcg0KPiA+PiBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0 byBvdXRlciBoZWFkZXIsIHdoaWNoDQo+ID4+IHVuZGVybHlpbmcgbmV0d29yayB1c2VzIG9ubHku IEhvd2V2ZXIsIEdSRSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9yDQo+ID4+IHRoZSBvdmVybGF5 IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3IgbG9h ZA0KPiA+PiBiYWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNl cyBHUkUgaGVhZGVyIHRvby4gSW4NCj4gPj4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5IGFu ZCB1bmRlcmx5aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5jZSBpdA0KPiA+PiBoYXMgbm90IHVz ZWQgYSBsb3QsIHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3Vj aA0KPiA+PiBjb3VwbGluZy4NCj4gPj4+DQo+ID4+PiBBcyB0aGUgaW5kdXN0cnkgbW92ZXMgdG93 YXJkIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBhbmQNCj4gPj4gZGVjb3VwbGVzIG92 ZXJsYXkgbmV0d29ya3MgZnJvbSB0aGUgdW5kZXJseWluZyBuZXR3b3JrLiBBIGNsZWFyDQo+ID4+ IHNlcGFyYXRpb24gb2Ygb3ZlcmxheSBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlzIGEg Ik1VU1QiIGluIG15DQo+ID4+IG9waW5pb24uIElmIHdlIGNvdW50IEdSRSBhcyB0aGUgb3Zlcmxh eSBoZWFkZXIsIHRoZW4gZm9yIElQdjQNCj4gPj4gdW5kZXJseWluZyBuZXR3b3JrLCB0aGVyZSBp cyBubyBmaWVsZCBmb3IgdGhlIGZsb3cgZW50cm9weS4gVGhpcyBpcyB0aGUNCj4gPj4gcmVhc29u IHdlIHByb3Bvc2UgdGhlIFVEUCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVy bHlpbmcNCj4gPj4gbmV0d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkg bmV0d29yayBiZXNpZGUgTVBMUyBjbGllbnQNCj4gPj4gbGF5ZXIgKGUuZy4gVlhMQU4sIEwyVFAt aW4tVURQLCBldGMpLg0KPiA+Pj4NCj4gPj4+IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1M MlRQLWluLVVEUCBpbnN0ZWFkLiBZZXMsIE1QTFMtaW4tTDJUUC0NCj4gPj4gaW4tVURQIHNjaGVt YSBhbHNvIHByb3ZpZGVzIGEgb3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKQ0KPiA+ PiBuZXR3b3JrIGRlY291cGxpbmcuIEwyVFAgcHJvdG9jb2wgKHJmYzM5MzEpIHByb3ZpZGVzIGdv b2Qgc2VjdXJpdHkNCj4gPj4gbWVjaGFuaXNtIGFuZCBoYXMgdGhlIGVtYmVkZGVkIGNvbnRyb2wg ZnVuY3Rpb24gdG9vLiBUaGVyZWZvcmUsDQo+IHNvbWVvbmUNCj4gPj4gY2FuIHVzZSBpdCBmb3Ig TVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudA0KPiA+ PiBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWluLUwyVFAt aW4tVURQIGlzIGENCj4gPj4gb3ZlcmtpbGwgYW5kIHRvbyBjb21wbGV4LiBIZXJlIHdlIG5lZWQg YSBzY2hlbWEgdG8gc3VwcG9ydCBJR1ANCj4gPj4gdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0aG91 dCB0b3VjaGluZyBhIG92ZXJsYXkgaGVhZGVyLiBVRFANCj4gPj4gZW5jYXBzdWxhdGlvbiBpcyB0 aGUgYmVzdCBjaG9pY2UgdG8gYWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGUNCj4gPj4g Y2hhbmdlcyBvbiBleGlzdGluZyByb3V0ZXJzLCBlLmcuIGNoYW5nZSBhdCBlZGdlIHJvdXRlcnMs IG5vIGNoYW5nZSBvbg0KPiA+PiB0cmFuc2l0IHJvdXRlcnMuDQo+ID4+Pg0KPiA+Pj4gUmVnYXJk cywNCj4gPj4+IEx1Y3kNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT5dDQo+ID4+Pj4gU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDIwLCAyMDEyIDQ6MTQgQU0NCj4gPj4+PiBUbzogU2hhbmUgQW1hbnRlDQo+ ID4+Pj4gQ2M6IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4t DQo+ID4+IHVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnPjsNCj4g Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+IFN1 YmplY3Q6IERpc2N1c3Npb24gb24gaG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIgVURQIHR1bm5l bHMNCj4gPj4+Pg0KPiA+Pj4+IEhpIFNoYW5lLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB5 b3VyIGZ1cnRoZXIgY29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0K PiA+Pj4+DQo+ID4+Pj4gTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5n IHRvIExvYSdzIHN1Z2dlc3Rpb24uDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiA+Pj4+PiDlj5Hku7bkuro6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3Rs ZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4gPj4+Pj4g5Y+R6YCB 5pe26Ze0OiAyMDEy5bm0MTLmnIgxOeaXpSAyMjozOA0KPiA+Pj4+PiDmlLbku7bkuro6IFh1eGlh b2h1DQo+ID4+Pj4+IOaKhOmAgTogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQt eHUtbXBscy1pbi0NCj4gPj4+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnVkcEB0b29scy5p ZXRmLm9yZz47DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc+DQo+ID4+Pj4+IOS4u+mimDogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1 cHBvcnQgdG8gbWFrZSBkcmFmdC14dS0NCj4gPj4+PiBtcGxzLWluLXVkcCBhbg0KPiA+Pj4+PiBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4NCj4gPj4+Pj4gWGlhb2h1LA0KPiA+ Pj4+Pg0KPiA+Pj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4 aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQo+IHdyb3RlOg0K PiA+Pj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+Pj4+Pj4g5Y+R5Lu25Lq6OiBTaGFu ZSBBbWFudGUgW21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3Rs ZXBvaW50Lm5ldD5dDQo+ID4+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MTLmnIgxOeaXpSAx MTo1OA0KPiA+Pj4+Pj4+IOaUtuS7tuS6ujogUm9nZXJzLCBKb3NoDQo+ID4+Pj4+Pj4g5oqE6YCB OiBTaGFocmFtIERhdmFyaTsgWHV4aWFvaHU7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4+Pj4gdWRw QHRvb2xzLmlldGYub3JnPG1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4g5Li76aKY OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0 LXh1LQ0KPiA+Pj4+IG1wbHMtaW4tdWRwDQo+ID4+Pj4+IGFuDQo+ID4+Pj4+Pj4gbXBscyB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIERl YyAxOCwgMjAxMiwgYXQgODo1MCBBTSwgIlJvZ2VycywgSm9zaCINCj4gPj4+PiA8am9zaC5yb2dl cnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCj4gPj4+Pj4+ PiB3cm90ZToNCj4gPj4+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8g bm90IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+Pj4gc29sdXRpb24NCj4gPj4+Pj4+Pj4gYWRk cmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiArMS4g IFBsZWFzZSBkbyBub3QgZGVmaW5lIHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0 aW9uLg0KPiA+Pj4+IFRoZQ0KPiA+Pj4+PiBJRVRGDQo+ID4+Pj4+Pj4gYWxyZWFkeSBzdGFuZGFy ZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvDQo+ID4+Pj4gc3RhbmRhcmRp emVkDQo+ID4+Pj4+IE1QTFMNCj4gPj4+Pj4+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhh ZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdA0KPiA+PiBvbmUsDQo+ID4+Pj4gdmVy eQ0KPiA+Pj4+Pj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8g c3VwcG9ydCBjYXJyaWFnZSBvZg0KPiA+Pj4+IEwzVlBOIG92ZXINCj4gPj4+Pj4gYW4NCj4gPj4+ Pj4+PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU2hhbmUsDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmsgeW91IGZvciB0ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwg ZGVwbG95bWVudHMgb2YgTVBMUyBvdmVyDQo+ID4+Pj4gSVAgaW4gYXQNCj4gPj4+Pj4gbGVhc3Qg b25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkN Cj4gPj4+PiB2YWx1YWJsZSB0byB0aG9zZQ0KPiA+Pj4+PiBwZW9wbGUgd2hvIGhhZCBiZWxpZXZl ZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlvbiBvZiBNUExTIG92ZXIgSVAgaW4NCj4gPj4+PiB0b2Rh eSdzIFNQDQo+ID4+Pj4+IG5ldHdvcmtzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBTZWU6IFJGQydz IDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4+PiBb Tk9URTogdGhlIGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUg MjAwNg0KPiA+Pj4+PiB0aW1lZnJhbWUhXQ0KPiA+Pj4+Pj4+ICBSRkMgNDY2NSBmb3IgcmVxdWly ZW1lbnRzIHJlbGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4gPj4+PiBtYXkgYmUN Cj4gPj4+Pj4+PiBjYXJyaWVkIG92ZXIgTDJUUHYzDQo+ID4+Pj4+Pj4gIEFuZCwgaGVyZSdzIGV2 aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcw0KPiA+Pj4+PiBpbXBs ZW1lbnRlZA0KPiA+Pj4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+ID4+IGh0dHA6Ly93d3cu Y2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRt bA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmluZyB0aGUgYWJvdmUg aW5mb3JtYXRpb24uIEFzIG1lbnRpb25lZCBpbg0KPiA+Pj4+IHRoaXMgZHJhZnQNCj4gPj4+Pj4g QU5EIG90aGVyIGRyYWZ0cywgdGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3Vs YXRpb24gb24NCj4gPj4gdGhlDQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiBJRCBmaWVsZCBpbiB0 aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzDQo+ ID4+Pj4gZGVmaW5lZCBpbg0KPiA+Pj4+PiBbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9y dGVkIGJ5IGV4aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEZX SVcsIEkgaGF2ZSBoYWQgc3VjY2VzcywgaW4gdGhlIHJlbGF0aXZlbHkgcmVjZW50IHBhc3QsIGlu DQo+ID4+Pj4gcmVxdWVzdGluZyBhIGNvcmUNCj4gPj4+Pj4gcm91dGVyIHZlbmRvciB0byBzdXBw b3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4+Pj4gY2FsY3Vs YXRpb25zIGluDQo+ID4+Pj4+IF9leGlzdGluZ18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQg KGV4dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15DQo+ID4+Pj4gbmV0d29yay4NCj4gPj4+Pj4gRnVy dGhlciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2 dnkNCj4gPj4gZm9sa3MNCj4gPj4+PiBhbmQNCj4gPj4+Pj4gdW5kZXJzdGFuZCB0aGUgaW50ZXJu YWwgYXJjaGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPiA+Pj4+IHJl c3VsdCwgdGhvc2UNCj4gPj4+Pj4gc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBu b3QgdGVjaG5pY2FsbHkgcG9zc2libGUgaW4gdGhpcw0KPiA+Pj4+IHJlZ2FyZC4NCj4gPj4+Pj4g VGh1cywgaXQgbWF5IGJlIGEgcXVlc3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252 aW5jZSB0aGVpcg0KPiA+Pj4+IEhXDQo+ID4+Pj4+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9w cmlhdGUgY2hhbmdlcyBpbiB0aGVpciBlcXVpcG1lbnQgdG8NCj4gPj4gYWNoaWV2ZQ0KPiA+Pj4+ IHRoZWlyDQo+ID4+Pj4+IGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBu b3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uDQo+ID4+IHNlZQ0KPiA+Pj4+IGJlbG93Lg0KPiA+Pj4+ DQo+ID4+Pj4gQ291bGQgeW91IHBsZWFzZSBicmllZmx5IGV4cGxhaW4gaG93IHRvIG1ha2UgdGhl IGFib3ZlIGNoYW5nZSBpbg0KPiA+Pj4+IEVYSVNUSU5HIGhhcmR3YXJlIG9mIGFscmVhZHkgZGVw bG95ZWQgY29yZSByb3V0ZXJzPw0KPiA+Pj4+DQo+ID4+Pj4+PiBJbiBjb250cmFzdCwgbW9zdCBl eGlzdGluZyBjb3JlIHJvdXRlcnMgYXJlIGFscmVhZHkgY2FwYWJsZSBvZg0KPiA+Pj4+IGJhbGFu Y2luZyBJUA0KPiA+Pj4+PiB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBm aXZlLXR1cGxlIG9mIFVEUCBwYWNrZXRzLg0KPiA+PiBCeQ0KPiA+Pj4+IHVzaW5nIHRoZQ0KPiA+ Pj4+PiBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9h ZC1iYWxhbmNpbmcNCj4gPj4+PiBjYXBhYmlsaXR5IG9mDQo+ID4+Pj4+IG1vc3QgZXhpc3Rpbmcg Y29yZSByb3V0ZXJzIGNhbiBiZSBsZXZlcmFnZWQgd2l0aG91dCByZXF1aXJpbmcgYW55DQo+ID4+ Pj4gY2hhbmdlIHRvDQo+ID4+Pj4+IHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24g b2YgdGhpcyBkcmFmdC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRo ZW4gd2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbg0KPiA+Pj4+IE1QTFMvTDJUUHYz LCB3aGljaA0KPiA+Pj4+PiB1c2VzIFVEUC9JUCwgaW4gdGhlIGZpcnN0IHBsYWNlPw0KPiA+Pj4+ DQo+ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgeW91IHByZWZlciB0byB1c2Ug TVBMUy1pbi1MMlRQdjMtaW4tDQo+ID4+IFVEUA0KPiA+Pj4+IGluc3RlYWQgb2YgTVBMUy1pbi1V RFAsIHJpZ2h0Pw0KPiA+Pj4+DQo+ID4+Pj4+IElNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBi ZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0KPiA+Pj4+IFJGQyAzOTMxLA0K PiA+Pj4+PiB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1c2VkIGZvciBkYXRhIHBh Y2tldHMgKG5vdCBjb250cm9sDQo+ID4+Pj4gcGFja2V0cykNCj4gPj4+Pj4gdG8gdXNlIGEgdmFy eWluZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksDQo+ID4+ IGJhc2VkDQo+ID4+Pj4gb24gYSBoYXNoDQo+ID4+Pj4+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZl IGJldHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nDQo+ID4+IGVxdWlwbWVudA0KPiA+ Pj4+IGluIGFuDQo+ID4+Pj4+IElQLW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1l bnRhdGlvbnMgd291bGQgYmUgYmV0dGVyIG9mZg0KPiA+Pj4+IGp1c3QgdXNpbmcNCj4gPj4+Pj4g dGhlICJTZXNzaW9uIElEIiAoYW5kICJDb29raWUiKSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlwbGV4 b3IgdG8NCj4gPj4+PiBhc3NvY2lhdGUNCj4gPj4+Pj4gaW5jb21pbmcgcGFja2V0cyB3aXRoIHRo ZSBhc3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwNCj4gPj4+PiBpdCdz IG5vdA0KPiA+Pj4+PiBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBt YXkgL2FscmVhZHkvIGRvIHRoaXMsDQo+ID4+Pj4gbWFraW5nIGFueQ0KPiA+Pj4+PiAiY2hlY2si IG9uIHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lz dGVtDQo+ID4+Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIGJlYXV0 eSBvZiB0aGUgYWJvdmUgYXBwcm9hY2ggaXM6DQo+ID4+Pj4+IDEpIEkgd291bGQgdGhpbmsgdGhh dCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcw0KPiA+Pj4+IGxpbWl0 ZWQgdG8gdGhlDQo+ID4+Pj4+ICJjb250cm9sIGNoYW5uZWwiIChzb2Z0d2FyZSkgb2YgZXhpc3Rp bmcgTDJUUCBlbmQtc3lzdGVtDQo+ID4+Pj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4+PiBIZWNr LCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2 Mw0KPiA+Pj4+PiBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBu ZWVkIHRvIGNvbW1lbnQgb24NCj4gPj4gdGhhdCkuDQo+ID4+Pj4NCj4gPj4+PiBJTUhPLCBubyBt YXR0ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCAgdGhlIGhhcmR3YXJl DQo+ID4+IG9mDQo+ID4+Pj4gUEUgcm91dGVycyBuZWVkcyB0byBiZSB1cGdyYWRlZCwgZS5nLiwg aW5ncmVzcyBQRSByb3V0ZXJzIG5lZWQgdG8NCj4gPj4gZmlsbA0KPiA+Pj4+IGluIGFuIGVudHJv cHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiA+Pj4+ DQo+ID4+Pj4+IDIpIFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdl dHMgYnkgdXNpbmcgIlNlc3Npb24NCj4gPj4+PiBJRCIgYW5kDQo+ID4+Pj4+ICJDb29raWUiIGZp ZWxkcyB0byBlbnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQNCj4g Pj4gZm9yDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+IGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3Rpbmcg ZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gPj4+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4+ PiAgTDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEg MzItYml0DQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhl YWRlci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWUNCj4gPj4+Pj4gIChkZXNjcmli ZWQgaW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGNoZWNrIHRvDQo+ID4+ IGVuc3VyZQ0KPiA+Pj4+PiAgdGhhdCBhbiBhcnJpdmluZyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9y IHRoZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+ID4+Pj4+ICBUaHVzLCB1c2Ugb2YgYSBDb29raWUg d2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0KPiA+Pj4+IGd1YXJhbnRlZQ0K PiA+Pj4+PiAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZvcm1lZCBwcm9wZXJs eSBhbmQgdGhhdCB0aGUNCj4gPj4+Pj4gIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3QgY29ycnVw dGVkIGluIHRyYW5zaXQuDQo+ID4+Pj4+IC0tLXNuaXAtLS0NCj4gPj4+Pj4gLi4uIGluIHJlZ2Fy ZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWENCj4gPj4g Zm9sa3MNCj4gPj4+PiBoYXZlLCBpbiB0aGUNCj4gPj4+Pj4gcGFzdCwgaGFkIC9zdWJzdGFudGlh bC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXINCj4gPj4gSVANCj4g Pj4+PiB0cmFuc3BvcnQuDQo+ID4+Pj4+IEluIGZhY3QsIHRoaXMgaXMgd2h5IHlvdSBzZWUgdGV4 dCBpbiBTZWN0aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YNCj4gPj4gUkZDDQo+ID4+Pj4gNDY2NS4N Cj4gPj4+Pj4gKFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRz IHRoYXQgdXNlIE1QTFMgZm9yDQo+ID4+Pj4gdHJhbnNwb3J0KS4NCj4gPj4+Pj4gV2hpbGUgSSdt IG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8N Cj4gPj4+PiBkYWlseSB0cmFmZmljIG9uDQo+ID4+Pj4+IHRoZSBNUExTIFdHIG1haWxpbmcgbGlz dCwgSSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGwNCj4gPj4+PiBhcmlzZSBp Zi93aGVuIHRoaXMNCj4gPj4+Pj4gZHJhZnQgZ29lcyB0byB0aGUgSUVTRyAuLi4NCj4gPj4+Pg0K PiA+Pj4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIg cHJlZmVyZW5jZSBvZg0KPiA+PiBNUExTLQ0KPiA+Pj4+IGluLUwyVFB2My1pbi1VRFAgaXMgdGhh dCBpdCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdA0KPiA+PiBpcw0KPiA+ Pj4+IHNvIGNvbmNlcm5lZCwgY2FuIHlvdSBleHBsYWluIHdoeSBNUExTLWluLUdSRSBpcyBmYXIg bW9yZSBwb3B1bGFyDQo+ID4+IHRoYW4NCj4gPj4+PiBNUExTLWluLUwyVFAgaW4gcHJhY3RpY2U/ DQo+ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4gWGlhb2h1DQo+ID4+Pj4NCj4g Pj4+Pj4gMykgRmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0 ZW1zIHRoYXQNCj4gPj4gaW1wbGVtZW50DQo+ID4+Pj4gTDJUUCwgZm9yDQo+ID4+Pj4+IHR1bm5l bGluZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkg dG8NCj4gPj4+PiBzdXBwb3J0DQo+ID4+Pj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4gdGhl aXIgcHJvZHVjdCBsaW5lcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gLXNoYW5lDQo+ID4+Pj4+DQo+ID4+ Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+Pj4gWGlhb2h1DQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4+IElmIHRoZXJlIHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92 ZXIgSVAsIHRoZW4gY2xlYXJseSBpdA0KPiA+PiB3b3VsZA0KPiA+Pj4+IGhhdmUNCj4gPj4+Pj4g YmVlbg0KPiA+Pj4+Pj4+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5k b3JzLCB3aXRoIGVpdGhlciBNUExTDQo+ID4+Pj4gb3Zlcg0KPiA+Pj4+PiBHUkUgb3INCj4gPj4+ Pj4+PiBNUExTIG92ZXIgTDJUUHYzLiAgKFdoZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEg d2F5KS4gIEkNCj4gPj4gd291bGQNCj4gPj4+PiBub3RlDQo+ID4+Pj4+IHRoYXQNCj4gPj4+Pj4+ PiB0aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBub3QgcGFuIG91dCB3YXMgdGhlcmUg YXJlDQo+ID4+IHNldmVyYWwsDQo+ID4+Pj4gcHJhY3RpY2FsDQo+ID4+Pj4+Pj4gb3BlcmF0aW9u YWwgYmVuZWZpdHMgb25lIGdldHMgZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+ID4+Pj4+ Pj4gZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6 DQo+ID4+Pj4+Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4gPj4+Pj4+PiAtIE1QTFMgVHJhZmZp YyBFbmdpbmVlcmluZw0KPiA+Pj4+Pj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBo YXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nDQo+ID4+Pj4+IGFyZ3VtZW50cw0KPiA+ Pj4+Pj4+IHRvICd1cGdyYWRlJyBuZXR3b3JrIEhXIHRvIHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0 aW9uL3N3aXRjaGluZy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IC1zaGFuZQ0KPiA+Pj4+Pj4+DQo+ ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gLUpvc2gNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9h ZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KPiA+Pj4+PiB3cm90ZToNCj4g Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBv dmVyIElQIGlzIGxlZ2FjeSBhbmQgdGhlcmUNCj4gPj4gaXMNCj4gPj4+PiBubyBuZWVkDQo+ID4+ Pj4+Pj4+PiB0byBpbXByb3ZlIGl0Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFJlZ2FyZHMs DQo+ID4+Pj4+Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IE9uIERlYyAxNywgMjAxMiwgYXQgODowMiBQTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAN Cj4gPj4+PiBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIg bG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gPj4+PiB0aG9zZQ0KPiA+ Pj4+Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1Q TFMgYXBwbGljYXRpb24NCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+Pj4+Pj4gYWNyb3NzIElQIG5l dHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4gPj4gYW5k DQo+ID4+Pj4+IFZYTEFODQo+ID4+Pj4+Pj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBhZHZvY2F0 b3JzIGFuZCB1c2UgY2FzZXMuIElmIHlvdQ0KPiA+PiBhYnNvbHV0ZWx5DQo+ID4+Pj4gYmVsaWV2 ZQ0KPiA+Pj4+Pj4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBw bGljYXRpb24gdHJhZmZpYw0KPiA+Pj4+IGFjcm9zcyBJUA0KPiA+Pj4+Pj4+Pj4+IG5ldHdvcmtz IGFuZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMNCj4gPj4g b3Zlcg0KPiA+Pj4+IElQDQo+ID4+Pj4+Pj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMgc2hvdWxk IGJlIG1vdmVkIHRvIEhpc3RvcmljIHN0YXR1cywNCj4gPj4gcGxlYXNlDQo+ID4+Pj4gc2F5DQo+ ID4+Pj4+IHNvLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQnkgdGhlIHdheSwgaXQgc2Vl bXMgdGhpcw0KPiA+Pj4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ID4+Pj4g YXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+Pj4+Pj4+Pj4g anVzdCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9sbG93 aW5nDQo+ID4+Pj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3Qg TVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+ID4+Pj4gY2VudGVycykuIEkN Cj4gPj4+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhhdCB0aW1l LiBTYWRseSwNCj4gPj4+PiBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+Pj4+Pj4+Pj4gdGlsbCBu b3cuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8g c2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBYaWFv aHUNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ ID4+Pj4+Pj4+Pj4+IOWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxz LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+XQ0KPiA+PiDku6MNCj4gPj4+PiDooagNCj4gPj4+Pj4+PiBT Lg0KPiA+Pj4+Pj4+Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDEy 5bm0MTLmnIgxNeaXpSAxMzozNA0KPiA+Pj4+Pj4+Pj4+PiDmlLbku7bkuro6IExvYSBBbmRlcnNz b24NCj4gPj4+Pj4+Pj4+Pj4g5oqE6YCBOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsNCj4gPj4+Pj4+Pj4+Pj4gbXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+ Pj4+Pj4+PiDkuLvpopg6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0 IHRvIG1ha2UNCj4gPj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPj4+Pj4+ Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNh dGlvbiBpbg0KPiA+Pj4+IHRvZGF5J3MNCj4gPj4+Pj4+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+ID4+ Pj4+Pj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQgaXRzIG9ubHkg cHJhY3RpY2FsDQo+ID4+Pj4gYXBwbGljYXRpb24NCj4gPj4+Pj4+Pj4+Pj4gaW4gaW4gZGF0YQ0K PiA+Pj4+Pj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVy IHNvbHV0aW9ucyBzdWNoIGFzDQo+ID4+Pj4gTlZHUkUNCj4gPj4+Pj4gYW5kDQo+ID4+Pj4+Pj4+ Pj4+IFZYTEFOLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBJdCBzZWVtcyB0aGUgYXV0 aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbg0KPiA+Pj4+IHNlbGVj dGlvbg0KPiA+Pj4+Pj4+Pj4+PiBwcm9jZXNzDQo+ID4+Pj4+Pj4+Pj4+IGJ5IGFkdmFuY2luZyB0 aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gUmVnYXJk cywNCj4gPj4+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24g PGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4+PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+Pj4+ Pj4+Pj4+IGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBk b2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBw b2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdpdGgNCj4gPj4+PiBvbmUgd2Vlay4NCj4gPj4+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25v dCBzdXBwb3J0KSB0byB0aGUgbXBscw0KPiA+Pj4+PiB3b3JraW5nDQo+ID4+Pj4+Pj4+Pj4+PiBn cm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhbg0KPiA+ Pj4+IHRlY2huaWNhbA0KPiA+Pj4+Pj4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0 L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiA+Pj4+IHRoaW5rIHRoYXQNCj4gPj4+ Pj4+Pj4+Pj4+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5n IGdyb3VwDQo+ID4+Pj4gZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4g VGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+PiBUaGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQo+ ID4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+ ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28tYXV0aG9ycyBo YXMgc3RhdGVkIG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+Pj4gbWFpbGluZyBsaXN0DQo+ID4+ Pj4+Pj4+Pj4+PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWlt cyB0aGFuIHRob3NlDQo+ID4+Pj4gYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4+Pj4gZGlzY2xvc2VkLg0K PiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAz ICh0aGUgZG9jdW1lbnQgdGhhdCB3ZSB1c2VkIGZvcg0KPiA+PiB0aGUNCj4gPj4+PiBJUFINCj4g Pj4+Pj4+Pj4+Pj4+IHBvbGwpDQo+ID4+Pj4+Pj4+Pj4+PiBNYXJzaGFsbCBFdWJhbmtzIHdhcyBs aXN0ZWQgYXMgb25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbA0KPiA+Pj4+IGhhcw0KPiA+Pj4+ Pj4+Pj4+Pj4gZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5j bHVkaW5nIHRoZQ0KPiA+Pj4+IGF1dGhvciB0ZWFtDQo+ID4+Pj4+Pj4+Pj4+PiBvZiBkcmFmdC14 dS1tcGxzLWluLXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcw0KPiA+Pj4+IHRy aWVkIHRvDQo+ID4+Pj4+Pj4+Pj4+PiBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0 byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb24NCj4gPj4gdGhlDQo+ID4+Pj4gSVBSDQo+ID4+Pj4+Pj4+ Pj4+PiBwb2xsLg0KPiA+Pj4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlz Lg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1 dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPiA+Pj4+Pj4+Pj4+Pj4gY28t YXV0aG9yLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IC9Mb2ENCj4gPj4+Pj4+Pj4+ Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPiA+Pj4+Pj4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAg ICAgICAgICAgICAgIGVtYWlsOg0KPiA+Pj4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29u LmNvbTxtYWlsdG86bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DQo+ID4+Pj4+Pj4+Pj4+PiBT ciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnU8bWFp bHRvOmxvYUBwaS5udT4NCj4gPj4+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAg ICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcNCj4gNTINCj4gPj4gMTMNCj4gPj4+Pj4+Pj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIN Cj4gMTMNCj4gPj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+ Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+ Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxt YWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBU aGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdh cm5lcg0KPiA+Pj4+IENhYmxlDQo+ID4+Pj4+Pj4gcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4gPj4+PiBzdWJqZWN0IHRvDQo+ ID4+Pj4+Pj4gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBF LW1haWwgaXMgaW50ZW5kZWQNCj4gPj4+PiBzb2xlbHkgZm9yDQo+ID4+Pj4+IHRoZQ0KPiA+Pj4+ Pj4+IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLiBJZiB5b3UNCj4gPj4+PiBhcmUgbm90IHRoZQ0KPiA+Pj4+Pj4+IGludGVuZGVkIHJlY2lw aWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdA0KPiA+Pj4+ IGFueQ0KPiA+Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPiA+Pj4+Pj4+IGRpc3RyaWJ1dGlvbiwgY29w eWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZQ0KPiA+PiBjb250ZW50cw0K PiA+Pj4+IG9mIGFuZA0KPiA+Pj4+Pj4+IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZQ0KPiA+Pj4+IHVubGF3ZnVsLiBJZiB5b3UNCj4g Pj4+Pj4+PiBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXINCj4gPj4+PiBpbW1lZGlhdGVseSBhbmQNCj4gPj4+Pj4+PiBwZXJtYW5lbnRs eSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQNCj4g Pj4+PiBhbnkgcHJpbnRvdXQuDQo+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+ Pj4+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4NCj4gPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxz IG1haWxpbmcgbGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Cj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxp bmcgbGlzdA0KPiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D44864E6Bdfweml505mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoYWhyYW0sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2Vl IGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUy4g RGF2YXJpIFttYWlsdG86ZGF2YXJpc2hAeWFob28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgRGVjZW1iZXIgMjEsIDIwMTIgMjoxMCBBTTxicj4NCjxiPlRvOjwvYj4gWHV4aWFvaHU7 IFNoYWhyYW0gRGF2YXJpOyBMdWN5IHlvbmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXh1LW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVy IG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSw8YnI+DQo8YnI+DQpJIHRoaW5rIHdlIGFyZSBpbiBh IHZpY2lvdXMgY3ljbGUuIENvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGljaCBuZXR3b3JrIG9w ZXJhdG9yIGlzIGFza2luZyBmb3IgTVBMUyBvdmVyIFVEUCBhbmQgd2hhdCBpcyB0aGUgYXBwbGlj YXRpb24uJm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0x1 Y3ldIGl0IGlzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BbHNvIGhvdyBkbyB5b3UgcGxhbiB0byBhZGRyZXNzIHRo ZSBNUExTIE11bHRpY2FzdCAod2hpY2ggaXMgcHJvYmFibHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBp bXByb3ZpbmcgdGhlIGxvYWQgYmFsYW5jaW5nKSwgZ2l2ZW4gdGhhdCBSRkM0MDIzIGRvZXMgbm90 IHN1cHBvcnQgTXVsdGljYXN0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5bTHVjeV0gTVBMUyBDbGllbnQgTGF5ZXIgaXMgcmVzcG9uc2libGUgdG8gbWFwIG11bHRpY2Fz dCB0cmFmZmljIHRvIHVuZGVybHlpbmcgdHJhbnNwb3J0LCB3aGljaCBpcyBzcGVjaWZpZWQgaW4g RVZQTiBhbmQgSVAgVlBOLg0KIFRoaXMgcHJvcG9zYWwganVzdCByZXF1ZXN0cyBpbmdyZXNzIFBF IHRvIGZpbGwgdGhlIGZsb3cgZW50cm9weSBpbnRvIFVEUCBzb3VyY2UgcG9ydCwgaW4gd2hpY2gg dGhlIGZsb3cgY2FuIGJlIHVuaWNhc3Qgb3IgbXVsdGljYXN0Lg0KPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NClNoYWhyYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGln bj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IFh1eGlhb2h1ICZsdDt4dXhpYW9odUBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlRvOjwvYj4gU2hh aHJhbSBEYXZhcmkgJmx0O2RhdmFyaUBicm9hZGNvbS5jb20mZ3Q7OyBMdWN5IHlvbmcgJmx0O2x1 Y3kueW9uZ0BodWF3ZWkuY29tJmd0Ow0KPGJyPg0KPGI+Q2M6PC9iPiAmcXVvdDtkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQteHUtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmcmZ3Q7OyAmcXVvdDttcGxzQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzQGll dGYub3JnJmd0OzsgJnF1b3Q7bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O21w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBEZWNlbWJlciAyMCwgMjAxMiA1OjU2OjIzIFBNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb bXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+ DQomZ3Q7IC0tLS0tPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6 U2ltU3VuO2NvbG9yOmJsYWNrIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4tLS0tLTxicj4NCiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3Jn Ij5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Luj 6KGoPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KJmd0OyBTaGFocmFtIERh dmFyaTxicj4NCiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj46IDIwMTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjEyPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yMTwvc3Bh bj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFj ayI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQogMTozMTxicj4NCiZndDsg PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9y OmJsYWNrIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IEx1Y3kg eW9uZzxicj4NCiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj46DQo8YSBocmVmPSJtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5v cmciPmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8L2E+Ozxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuS4u+mimDwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRl cmx5aW5nIG5ldHdvcms8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIGRvbid0IG1peCB1cCB0 aGluZ3MuIFRoZSBNUExTIHByb3RvY29sIGRlc2lnbiBJIGFncmVlIG11c3QgYmUgZG9uZSBieTxi cj4NCiZndDsgTVBMUyBXRy4gQnV0IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdXIgcHJvcG9z YWwgbWVldHMgdGhlIG5ldHdvcms8YnI+DQomZ3Q7IHZpcnR1YWxpemF0aW9uIHJlcXVpcmVtZW50 cy48YnI+DQo8YnI+DQpDYW4geW91IHRlbGwgdXMgd2hlcmUgTVBMUy1pbi1HUkUvSVAgW1JGQzQw MjNdIGFuZCBvdGhlciBNUExTIG92ZXIgSVAgZW5jYXBzdWxhdGlvbiBtZWNoYW5pc21zIGhhdmUg YmVlbiBkaXNjdXNzZWQgYmVmb3JlPzxicj4NCjxicj4NClNpbmNlIE1QTFMtaW4tVURQIGlzIGp1 c3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiB0aGUgc2NlbmFyaW9zIHdoZXJlIE1QTFMtaW4tR1JF L0lQIGhhcyBiZWVuIHVzZWQgYW5kIGlzIHRvIGJlIHVzZWQsIE1QTFMtaW4tVURQIHNob3VsZCBi ZSBkaXNjdXNzZWQgaW4gdGhlIHNhbWUgV0cgd2hlcmUgTVBMUy1pbi1HUkUvSVAgaGFzIGJlZW4g ZGlzY3Vzc2VkLjxicj4NCjxicj4NClhpYW9odTxicj4NCjxicj4NCiZndDsgVGhlIE5WTzMgdGFz ayBpcyB0byBkb2N1bWVudCB0aGUgaXNzdWVzLCByZXF1aXJlbWVudHMgYW5kIGZyYW1ld29yayBm b3I8YnI+DQomZ3Q7IE52TzMuIFRoZW4gaWYgTVBMUyBvdmVyIElQIGxvb2tzIGxpa2UgYSBzdWl0 YWJsZSBzb2x1dGlvbiB0aGF0IG1lZXRzIHRoZTxicj4NCiZndDsgcmVxdWlyZW1lbnRzIHN1Y2gg YXMgdGhlIHNjYWxlLCBtb2JpbGl0eSwgZXRjLCB0aGVuIHRoZXkgd2lsbCBhc2sgTVBMUyBXRyBm b3I8YnI+DQomZ3Q7IHByb3RvY29sIGRlc2lnbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgU28gYmVm b3JlIHByb2NlZWRpbmcgdGhpcyBkcmFmdCwgSSB0aGluayB5b3Ugc2hvdWxkIHRha2UgaXQgdG8g TlZPMyBXRyBhbmQ8YnI+DQomZ3Q7IGNvbnZpbmNlIHRoZW0gdGhpcyBzb2x1dGlvbiBtZWV0cyB0 aGVpciByZXF1aXJlbWVudHMgYW5kIGZyYW1ld29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2Ug ZG9uJ3Qgd2FudCBJRVRGIGRvIGRlc2lnbiBOIG51bWJlciBvZiBzb2x1dGlvbnMgZm9yIHRoZSBz YW1lIHByb2JsZW0sIGRvPGJyPg0KJmd0OyB3ZT88YnI+DQomZ3Q7IDxicj4NCiZndDsgLVNoYWhy YW08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJy Pg0KJmd0OyBTaGFocmFtPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gRGVjIDIw LCAyMDEyLCBhdCA4OjU2IEFNLCAmcXVvdDtMdWN5IHlvbmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBOZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92 ZXJsYXkgaXMgZGlzY3Vzc2VkIHVuZGVyIG52bzMgV0cuIFRoaXMgZG9lcyBub3Q8YnI+DQomZ3Q7 IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEgdW5k ZXJseWluZyBuZXR3b3JrIG9yIGE8YnI+DQomZ3Q7IG5ldyBwcm90b2NvbCBmb3IgYSBvdmVybGF5 IG5ldHdvcmsuIEluIGZhY3QsIHBlb3BsZSB0aGVyZSBhaW0gb24gbGV2ZXJhZ2U8YnI+DQomZ3Q7 IHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29tcGxpc2ggdGhlbS4gSU1POiB0aGVz ZSBleHBhbnNpb25zIG9uIGFuPGJyPg0KJmd0OyBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBo YXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhlIHByb3RvY29sIFdHIGdyb3VwLCBpdDxicj4NCiZn dDsgc2hvdWxkIG5vdCBnaXZlIG52bzMgV0cgZnJlZSByaWdodCB0byBlbmhhbmNlIHRoZXNlIHBy b3RvY29scy4gRm9yIGEgYnJhbmQ8YnI+DQomZ3Q7IG5ldyBwcm90b2NvbCBmb3IgbmV0d29yayB2 aXJ0dWFsaXphdGlvbiBvdmVybGF5LCBudm8zIFdHIG1heSBiZSB0aGUgcGxhY2UgdG88YnI+DQom Z3Q7IHN0YXJ0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBMdWN5PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJmd0OyZndDsgRnJvbTogU2hhaHJhbSBEYXZhcmkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 ZGF2YXJpQGJyb2FkY29tLmNvbSI+ZGF2YXJpQGJyb2FkY29tLmNvbTwvYT5dPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgMTA6MzQgQU08YnI+DQom Z3Q7ICZndDsmZ3Q7IFRvOiBMdWN5IHlvbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IENjOiBTaGFuZSBB bWFudGU7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9y ZyI+ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFp bHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIj5tcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbbXBsc10g TVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrPGJyPg0KJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVy bGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBjb25zZW50ZWQmbmJzcDsgaW4gTlZPMzxicj4NCiZn dDsgJmd0OyZndDsgV0cuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgUmVn YXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNoYWhyYW08YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgT24gRGVjIDIwLCAyMDEyLCBhdCA3OjM5 IEFNLCAmcXVvdDtMdWN5IHlvbmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWN5LnlvbmdA aHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSGkgU2hhbmUsPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJIHVuZGVyc3RhbmQgb3BlcmF0b3IgY29u Y2VybiBvbiBhIG5ldyBlbmNhcHN1bGF0aW9uIHRvIGFuIGV4aXN0aW5nPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBuZXR3b3JrLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgSG93ZXZlciwgTVBMUy1pbi1VRFAgZG9lcyBub3QgYWltIG9uIGNoYW5naW5nIGV4aXN0aW5n IFNQIElQL01QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG5ldHdvcmsgYXQgYWxsLjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IE1QTFMtaW4tVURQIGlzIHRvIGVuYWJsZSBNUExTIGNsaWVudCBsYXllciB0 byBiZSBkZWNvdXBsZWQgZnJvbSBNUExTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzZXJ2ZXIgbGF5ZXIg YW5kIHVzZSBNUExTIGNsaWVudCBsYXllciBhcyBvdmVybGF5IG5ldHdvcmsgYW5kIGFuIElHUCBh czxicj4NCiZndDsgJmd0OyZndDsgYSB1bmRlcmx5aW5nIG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4g U3VjaCBhcHBsaWNhdGlvbiBpcyBmb3IgREMuIFlvdSBtYXk8YnI+DQomZ3Q7ICZndDsmZ3Q7IGFy Z3VlIHdoeSBub3QgdXNlIHRoZSBHUkUgd2hpY2ggaXMgZm9yIE1QTFMgbGF5ZXIgb3ZlciBhbiBJ R1AgdW5kZXJsaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBuZXR3b3JrLiBXZSBoYXZlIHBvaW50ZWQg b3V0IGluIHRoZSBkcmFmdCB0aGF0IGN1cnJlbnQgcm91dGVycyBpbiBEQzxicj4NCiZndDsgJmd0 OyZndDsgYmFyZWx5IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCBNUExTLWlu LUdSRSBhcmUgYmFyZWx5IHVzZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGluIFNQIG5ldHdvcmtzIHRv by4gTW9zdCBvZiByb3V0ZXJzIGluIERDIHBlcmZvcm0gdXBkIHBvcnQgYmFzZWQgbG9hZDxicj4N CiZndDsgJmd0OyZndDsgYmFsYW5jaW5nIG5vdy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgdGhl IFVEUCBlbmNhcHN1bGF0aW9uIGhhczxicj4NCiZndDsgJmd0OyZndDsgYWR2YW50YWdlIG92ZXIg R1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5jYXBzdWxhdGlvbiwgdGhlIGZyYW1lPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBoZWFkZXIgZGVjb3VwbGVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5 aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRlcjxicj4NCiZndDsgJmd0OyZndDsgaGVhZGVy IGFuZCBvdmVybGF5IGhlYWRlci4gVURQIGJlbG9uZ3MgdG8gb3V0ZXIgaGVhZGVyLCB3aGljaDxi cj4NCiZndDsgJmd0OyZndDsgdW5kZXJseWluZyBuZXR3b3JrIHVzZXMgb25seS4gSG93ZXZlciwg R1JFIGhlYWRlciBoYXMgdGhlIGZpZWxkcyBmb3I8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZSBvdmVy bGF5IG5ldHdvcmsgYW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3Ig bG9hZDxicj4NCiZndDsgJmd0OyZndDsgYmFsYW5jaW5nLCBpdCByZXF1aXJlcyB0aGUgdW5kZXJs eWluZyBuZXR3b3JrIHVzZXMgR1JFIGhlYWRlciB0b28uIEluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBz aG9ydCwgR1JFIHRpZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29ya3MgdG9nZXRo ZXIuIFNpbmNlIGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoYXMgbm90IHVzZWQgYSBsb3QsIHBlb3Bs ZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaDxicj4NCiZndDsgJmd0 OyZndDsgY291cGxpbmcuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBBcyB0aGUgaW5kdXN0cnkgbW92ZXMgdG93YXJkIG5ldHdvcmsgdmlydHVhbGl6YXRpb24g b3ZlcmxheSBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRlY291cGxlcyBvdmVybGF5IG5ldHdvcmtz IGZyb20gdGhlIHVuZGVybHlpbmcgbmV0d29yay4gQSBjbGVhcjxicj4NCiZndDsgJmd0OyZndDsg c2VwYXJhdGlvbiBvZiBvdmVybGF5IGhlYWRlciBhbmQgdW5kZXJseWluZyBoZWFkZXIgaXMgYSAm cXVvdDtNVVNUJnF1b3Q7IGluIG15PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvcGluaW9uLiBJZiB3ZSBj b3VudCBHUkUgYXMgdGhlIG92ZXJsYXkgaGVhZGVyLCB0aGVuIGZvciBJUHY0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUgZmxv dyBlbnRyb3B5LiBUaGlzIGlzIHRoZTxicj4NCiZndDsgJmd0OyZndDsgcmVhc29uIHdlIHByb3Bv c2UgdGhlIFVEUCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVybHlpbmc8YnI+ DQomZ3Q7ICZndDsmZ3Q7IG5ldHdvcmsuIEluIGZhY3QsIGl0IGNhbiBzdXBwb3J0IGFueSBvdmVy bGF5IG5ldHdvcmsgYmVzaWRlIE1QTFMgY2xpZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBsYXllciAo ZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAsIGV0YykuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBZb3UgcG9pbnQgb3V0IHVzaW5nIE1QTFMtaW4tTDJUUC1pbi1V RFAgaW5zdGVhZC4gWWVzLCBNUExTLWluLUwyVFAtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbi1VRFAg c2NoZW1hIGFsc28gcHJvdmlkZXMgYSBvdmVybGF5IChMMlRQKSBhbmQgdW5kZXJseWluZyAoSVAp PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBuZXR3b3JrIGRlY291cGxpbmcuIEwyVFAgcHJvdG9jb2wgKHJm YzM5MzEpIHByb3ZpZGVzIGdvb2Qgc2VjdXJpdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7IG1lY2hhbmlz bSBhbmQgaGFzIHRoZSBlbWJlZGRlZCBjb250cm9sIGZ1bmN0aW9uIHRvby4gVGhlcmVmb3JlLDxi cj4NCiZndDsgc29tZW9uZTxicj4NCiZndDsgJmd0OyZndDsgY2FuIHVzZSBpdCBmb3IgTVBMUyBj bGllbnQgbGF5ZXIgb3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudDxicj4NCiZndDsg Jmd0OyZndDsgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJsaW5nIG5ldHdvcmssIElNTzogTVBMUy1p bi1MMlRQLWluLVVEUCBpcyBhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvdmVya2lsbCBhbmQgdG9vIGNv bXBsZXguIEhlcmUgd2UgbmVlZCBhIHNjaGVtYSB0byBzdXBwb3J0IElHUDxicj4NCiZndDsgJmd0 OyZndDsgdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0aG91dCB0b3VjaGluZyBhIG92ZXJsYXkgaGVh ZGVyLiBVRFA8YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gaXMgdGhlIGJlc3QgY2hv aWNlIHRvIGFjY29tcGxpc2ggdGhhdCBhbmQgbWluaW1pemUgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBjaGFuZ2VzIG9uIGV4aXN0aW5nIHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVy cywgbm8gY2hhbmdlIG9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0cmFuc2l0IHJvdXRlcnMuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7IEx1Y3k8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg RnJvbTogWHV4aWFvaHUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNv bSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA0OjE0IEFNPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFRvOiBTaGFuZSBBbWFudGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgQ2M6 IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnIj51ZHBAdG9vbHMu aWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZyI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cgdG8gdHJh bnNwb3J0IE1QTFMgb3ZlciBVRFAgdHVubmVsczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIg Y29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBOb3RlOiBJIGNoYW5nZWQg dGhlIHN1YmplY3QgbGluZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tPC9z cGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJs YWNrIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tLS0tLTxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBz dHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5Hku7bkuro8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFNoYW5lIEFtYW50ZSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQiPnNoYW5lQGNhc3RsZXBvaW50Lm5ldDwvYT5dPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjE5PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCiAy MjozODxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mlLbku7bkuro8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFh1eGlhb2h1PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWls eTpTaW1TdW47Y29sb3I6YmxhY2siPuaKhOmAgTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi08YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnVkcEB0b29scy5pZXRmLm9y ZyI+dWRwQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIj4NCm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7kuLvp opg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFJlOiBbbXBsc10gcG9sbCB0byBz ZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IG1wbHMtaW4tdWRwIGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBYaWFvaHUsPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gRGVjIDE4LCAy MDEyLCBhdCAxMTo1MCBQTSwgWHV4aWFvaHUgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tIj54dXhpYW9odUBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQomZ3Q7IHdyb3RlOjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS08L3NwYW4+PHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPumCruS7tuWOn+S7tjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+OiBTaGFuZSBBbWFudGUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c2hhbmVA Y2FzdGxlcG9pbnQubmV0Ij5zaGFuZUBjYXN0bGVwb2ludC5uZXQ8L2E+XTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxl PSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjE5PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu O2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCiAxMTo1 ODxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFu Zz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaUtuS7tuS6 ujwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogUm9nZXJzLCBKb3NoPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5oqE6YCBPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+OiBTaGFocmFtIERhdmFyaTsgWHV4aWFvaHU7IGRyYWZ0LXh1 LW1wbHMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp1ZHBA dG9vbHMuaWV0Zi5vcmciPnVkcEB0b29scy5pZXRmLm9yZzwvYT47PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxz QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn Ij4NCm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZh bWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuS4u+mimDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFr ZSBkcmFmdC14dS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbXBscy1pbi11ZHA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTgsIDIwMTIs IGF0IDg6NTAgQU0sICZxdW90O1JvZ2VycywgSm9zaCZxdW90Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tIj5qb3No LnJvZ2Vyc0B0d2NhYmxlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0aGUgcHJvYmxl bSB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbHV0aW9uPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxv bmdlci48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJiM0MzsxLiZuYnNwOyBQbGVhc2UgZG8gbm90IGRl ZmluZSB5ZXQgYW5vdGhlciBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbi48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgVGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJRVRGPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFscmVhZHkgc3RhbmRhcmRpemVk IE1QTFMgb3ZlciBHUkUuJm5ic3A7IFRoZSBJRVRGIGhhcyBhbHNvPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHN0YW5kYXJkaXplZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTVBM Uzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvdmVyIEwyVFB2My9VRFAv SVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdDxicj4NCiZndDsg Jmd0OyZndDsgb25lLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB2ZXJ5PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJ J20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBMM1ZQTiBvdmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJUC1vbmx5IG5ldHdvcmsuPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rIHlvdSBmb3IgdGVsbGluZyB1cyB0aGVy ZSBhcmUgYWN0dWFsIGRlcGxveW1lbnRzIG9mIE1QTFMgb3Zlcjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBJUCBpbiBhdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGVhc3Qgb25l LCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnk8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdmFsdWFibGUgdG8gdGhvc2U8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHBlb3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxp Y2F0aW9uIG9mIE1QTFMgb3ZlciBJUCBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0b2Rh eSdzIFNQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3Jrcy48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBM MlRQdjM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW05PVEU6IHRoZSBk YXRlcyB0aGUgYWJvdmUgd2VyZSBwdWJsaXNoZWQgd2FzIGJhY2sgaW4gdGhlIDIwMDY8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRpbWVmcmFtZSFdPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IFJGQyA0NjY1IGZvciByZXF1aXJlbWVudHMgcmVsYXRl ZCB0byBWUExTIHRoYXQgc2F5IHRoYXQgVlBMUzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBt YXkgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FycmllZCBvdmVy IEwyVFB2Mzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBBbmQs IGhlcmUncyBldmlkZW5jZSBzaG93aW5nIHRoYXQgYXQgbGVhc3Qgb25lIHZlbmRvciBoYXM8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGltcGxlbWVudGVkPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IElQVlBOJ3Mgb3ZlciBMMlRQdjM6PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9m ZWF0dXJlL2d1aWRlL2NzZ2wzdnBuLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cu Y2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRt bCA8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGlu Zm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhp cyBkcmFmdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQU5EIG90aGVyIGRyYWZ0cywg dGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb24gb248YnI+DQomZ3Q7 ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTZXNzaW9uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0 aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGRlZmluZWQgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtSRkMgNTY0MF0g aXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNvIGZhci48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBGV0lXLCBJIGhhdmUgaGFkIHN1Y2Nlc3MsIGluIHRoZSByZWxhdGl2ZWx5IHJlY2VudCBw YXN0LCBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXF1ZXN0aW5nIGEgY29yZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5n ZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGNhbGN1bGF0aW9ucyBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgX2V4aXN0 aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQg bXk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbmV0d29yay48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEZ1cnRoZXIsIEkgc3VzcGVjdCB0aGF0IG1vc3QgbGFyZ2UgbmV0d29yayBv cGVyYXRvcnMgYXJlIHNhdnZ5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmb2xrczxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVuZGVyc3Rh bmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWlybHkgd2VsbC4mbmJz cDsgQXMgYTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXN1bHQsIHRob3NlPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlz IG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IHJlZ2FyZC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRodXMsIGl0IG1heSBi ZSBhIHF1ZXN0aW9uIG9mICZxdW90O21ldGhvZHMmcXVvdDsgbmVjZXNzYXJ5IHRvIGNvbnZpbmNl IHRoZWlyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhXPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBzdXBwbGllcihzKSB0byBtYWtlIGFwcHJvcHJpYXRlIGNoYW5nZXMgaW4gdGhl aXIgZXF1aXBtZW50IHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhY2hpZXZlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZWlyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXNpbmVz cyBnb2Fscy4mbmJzcDsgOi0pJm5ic3A7IEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJlIG5l Y2Vzc2FyeSAuLi48YnI+DQomZ3Q7ICZndDsmZ3Q7IHNlZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBiZWxvdy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgQ291bGQgeW91IHBsZWFzZSBicmllZmx5IGV4cGxhaW4gaG93IHRvIG1ha2UgdGhl IGFib3ZlIGNoYW5nZSBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBFWElTVElORyBoYXJk d2FyZSBvZiBhbHJlYWR5IGRlcGxveWVkIGNvcmUgcm91dGVycz88YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBjb250cmFzdCwg bW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgYXJlIGFscmVhZHkgY2FwYWJsZSBvZjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBiYWxhbmNpbmcgSVA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRyYWZmaWMgZmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUtdHVwbGUg b2YgVURQIHBhY2tldHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCeTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyB1c2luZyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1QTFMtaW4t VURQIGVuY2Fwc3VsYXRpb24sIHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJhbGFuY2luZzxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjYXBhYmlsaXR5IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBjYW4gYmUgbGV2ZXJhZ2Vk IHdpdGhvdXQgcmVxdWlyaW5nIGFueTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2Ug dG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW0uIFRoYXQgaXMgdGhlIG1ham9y IG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGlzIGlzIGEgY29uY2VybiwgdGhl biB3aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFmZmljIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IE1QTFMvTDJUUHYzLCB3aGljaDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dXNlcyBVRFAvSVAsIGluIHRoZSBmaXJzdCBwbGFjZT88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3Rs eSwgeW91IHByZWZlciB0byB1c2UgTVBMUy1pbi1MMlRQdjMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBVRFA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaW5zdGVhZCBvZiBNUExTLWluLVVEUCwg cmlnaHQ/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBJTUhPLCBhIGJldHRlciBwcm9wb3NhbCBtYXkgYmUgdG8gY29uc2lkZXIgYSBbbWlu b3JdICg/KSBjaGFuZ2UgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUkZDIDM5MzEsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVj dGlvbiB1c2VkIGZvciBkYXRhIHBhY2tldHMgKG5vdCBjb250cm9sPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHBhY2tldHMpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byB1c2Ug YSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSw8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGJhc2VkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG9uIGEg aGFzaDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2FsY3VsYXRpb24sIHRvIGFjaGll dmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92ZXIgZXhpc3Rpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7 IGVxdWlwbWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbiBhbjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSVAtb25seSBjb3JlLiZuYnNwOyBMMlRQIGVuZC1zeXN0ZW0gaW1w bGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmY8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsganVzdCB1c2luZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlICZxdW90O1Nl c3Npb24gSUQmcXVvdDsgKGFuZCAmcXVvdDtDb29raWUmcXVvdDspIGZpZWxkcyBhcyB0aGUgZGVt dWx0aXBsZXhvciB0bzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGU8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluY29taW5nIHBhY2tldHMgd2l0aCB0aGUgYXNzb2Np YXRlZCBMMlRQIENvbnRyb2wgQ2hhbm5lbC4mbmJzcDsgSW4gZmFjdCw8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgaXQncyBub3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNsZWFy IHRvIG1lIHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG1heSAvYWxyZWFkeS8gZG8gdGhp cyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbWFraW5nIGFueTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7Y2hlY2smcXVvdDsgb24gdGhlIGluY29taW5nIHNvdXJjZSBw b3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9ucy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBh cHByb2FjaCBpczo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEpIEkgd291bGQgdGhp bmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpczxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBsaW1pdGVkIHRvIHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJnF1b3Q7Y29udHJvbCBjaGFubmVsJnF1b3Q7IChzb2Z0d2FyZSkgb2YgZXhpc3Rp bmcgTDJUUCBlbmQtc3lzdGVtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0 aW9ucy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhlY2ssIGl0IG1heSBldmVuIGJl IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgTDJUUHYzPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IChMMlRQdjMgaW1wbGVtZW50 b3JzIHdvdWxkIG5lZWQgdG8gY29tbWVudCBvbjxicj4NCiZndDsgJmd0OyZndDsgdGhhdCkuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElNSE8s IG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3IgTVBMUy1pbi1VRFAsJm5ic3A7IHRo ZSBoYXJkd2FyZTxicj4NCiZndDsgJmd0OyZndDsgb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgUEUgcm91dGVycyBuZWVkcyB0byBiZSB1cGdyYWRlZCwgZS5nLiwgaW5ncmVzcyBQRSByb3V0 ZXJzIG5lZWQgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IGZpbGw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgaW4gYW4gZW50cm9weSB2YWx1ZSBpbiB0aGUgc291cmNlIHBvcnQgZmllbGQgb2YgVURQ IGhlYWRlcnMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBn ZXRzIGJ5IHVzaW5nICZxdW90O1Nlc3Npb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSUQm cXVvdDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtDb29raWUmcXVv dDsgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRl ZDxicj4NCiZndDsgJmd0OyZndDsgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaWRlbnRpZmllZCBzZXNzaW9uLiZuYnNwOyBR dW90aW5nIGZyb20gU2VjdGlvbiA4LjIgb2YgUkZDIDM5MzE6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAtLS1zbmlwLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyBMMlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAz Mi1iaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2Vzc2lvbjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRlci4mbmJzcDsg V2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0 aW9uYWwgY2hlY2sgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IGVuc3VyZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgdGhhdCBhbiBhcnJpdmluZyBwYWNrZXQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBpZGVudGlmaWVkIHNlc3Npb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyBUaHVzLCB1c2Ugb2YgYSBDb29raWUgd2l0aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRl cyBhbiBleHRyYTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBndWFyYW50ZWU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IHRoYXQgdGhlIFNlc3Npb24gSUQgbG9va3VwIHdh cyBwZXJmb3JtZWQgcHJvcGVybHkgYW5kIHRoYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyBTZXNzaW9uIElEIGl0c2VsZiB3YXMgbm90IGNvcnJ1cHRlZCBpbiB0cmFu c2l0Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tc25pcC0tLTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLi4uIGluIHJlZ2FyZCB0byB0aGlzIHF1ZXN0aW9uIGFsb25l LCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWE8YnI+DQomZ3Q7ICZndDsmZ3Q7IGZvbGtzPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGhhdmUsIGluIHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxh dGlvbiBvZiBNUExTIG92ZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7IElQPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IHRyYW5zcG9ydC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIGZh Y3QsIHRoaXMgaXMgd2h5IHlvdSBzZWUgdGV4dCBpbiBTZWN0aW9uIDcuNiwgJnF1b3Q7U2VjdXJp dHkmcXVvdDssIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBSRkM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgNDY2NS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChUaGVyZSdzIGxpa2Vs eSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZvcjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQpLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkg bXVjaCBhdHRlbnRpb24gdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZGFpbHkgdHJhZmZp YyBvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIE1QTFMgV0cgbWFpbGluZyBs aXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0aGlzIGNvbmNlcm4gd2lsbDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBhcmlzZSBpZi93aGVuIHRoaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGRyYWZ0IGdvZXMgdG8gdGhlIElFU0cgLi4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0 bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5jZSBvZjxicj4NCiZndDsgJmd0OyZndDsg TVBMUy08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0 IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0eSBmZWF0dXJlLiBJZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzbyBjb25jZXJuZWQsIGNhbiB5b3Ug ZXhwbGFpbiB3aHkgTVBMUy1pbi1HUkUgaXMgZmFyIG1vcmUgcG9wdWxhcjxicj4NCiZndDsgJmd0 OyZndDsgdGhhbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBNUExTLWluLUwyVFAgaW4gcHJh Y3RpY2U/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgWGlhb2h1PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAzKSBG aW5hbGx5LCB0aGlzIGFwcHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5c3RlbXMgdGhhdDxi cj4NCiZndDsgJmd0OyZndDsgaW1wbGVtZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEwy VFAsIGZvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHVubmVsaW5nIG9mIE1QTFMv SVAsIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFuIGVudGlyZSBpbmR1c3RyeSB0bzxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBN UExTL1VEUCBlbmNhcHN1bGF0aW9uIGluIHRoZWlyIHByb2R1Y3QgbGluZXMuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLXNoYW5l PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlc3QgcmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBYaWFvaHU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGVyZSB3YXMgbWFya2V0IGRl bWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVuIGNsZWFybHkgaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGhhdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGJlZW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bW9yZSB3aWRlbHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMsIHdpdGggZWl0aGVy IE1QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb3Zlcjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgR1JFIG9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE1QTFMgb3ZlciBMMlRQdjMuJm5ic3A7IChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUncyBh IHdheSkuJm5ic3A7IEk8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IG5vdGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQ8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMg dGhpcyBkaWQgbm90IHBhbiBvdXQgd2FzIHRoZXJlIGFyZTxicj4NCiZndDsgJmd0OyZndDsgc2V2 ZXJhbCw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcHJhY3RpY2FsPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdGlvbmFsIGJlbmVmaXRzIG9uZSBnZXRzIGZy b20gZ29pbmcgd2l0aCBuYXRpdmUgTVBMUzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRoaW4gdGhlIGRhdGEgcGxhbmUsIG5h bWVseTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLSBNUExTIEZhc3Qg UmUtUm91dGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLSBNUExTIFRy YWZmaWMgRW5naW5lZXJpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Li4uIHRvIG5hbWUsIGJ1dCBhIGZldy4mbmJzcDsgVGhvc2UgaGF2ZSB0ZW5kZWQgdG8gYmUgcXVp dGUgY29tcGVsbGluZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXJndW1lbnRzPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvICd1cGdyYWRlJyBuZXR3b3Jr IEhXIHRvIHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZy48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgLXNoYW5lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtSm9zaDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAxMi8xOC8xMiAx MjozMSBBTSwgJnF1b3Q7U2hhaHJhbSBEYXZhcmkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk YXZhcmlAYnJvYWRjb20uY29tIj5kYXZhcmlAYnJvYWRjb20uY29tPC9hPiZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdhY3kg YW5kIHRoZXJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBubyBuZWVkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg dG8gaW1wcm92ZSBpdC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2hhaHJh bTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIgUE0s ICZxdW90O1h1eGlhb2h1JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBT aGFocmFtLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlz IGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBlbmNhcHN1bGF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1ldGhvZCB3aXRoIGEgYmV0dGVyIGxvYWQtYmFs YW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IHRob3NlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGlj YXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdHJhZmZpYzxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhY3Jvc3MgSVAgbmV0d29ya3MuIEkg YmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQLCBOVkdSRTxicj4NCiZndDsgJmd0OyZndDsg YW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBWWExBTjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlYWNoIGhhdmUgdGhlaXIgb3duIGFk dm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhYnNvbHV0 ZWx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGJlbGlldmU8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFu c3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGFjcm9zcyBJUDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBuZXR3b3JrcyBhbmQgdGhlcmVmb3JlIHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRl ZCB0byBNUExTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvdmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IElQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBiZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMs PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBwbGVhc2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2F5 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzby48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnkgdGhlIHdheSwgaXQgc2VlbXMgdGhpczxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC0NCjwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXJjaGl2ZS93ZWIvbnZv My9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGp1c3QgdGhlIHJpZ2h0IHRocmVhZCBzdWl0YWJsZSBmb3Ig eW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmd1 bWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAo aS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRh PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNlbnRlcnMpLiBJPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBz cGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBz dXJwcmlzaW5nbHkgc2lsZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRpbGwgbm93Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndp c2UuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFhpYW9odTxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS08L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tLS0tPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjoNCjxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4g W21haWx0bzo8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnIj5tcGxzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XTxicj4NCiZndDsgJmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7ku6M8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFu PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7ooag8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERhdmFyaTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IDIwMTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjEyPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4xNTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1 bjtjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQogMTM6 MzQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pS25Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiBMb2Eg QW5kZXJzc29uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1T dW47Y29sb3I6YmxhY2siPuaKhOmAgTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjoN CjxhIGhyZWY9Im1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyI+ZHJh ZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1w bHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnIj5tcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Li7 6aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiBSZTogW21wbHNdIHBvbGwgdG8g c2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC14dS1tcGxzLWluLXVkcCBhbjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXBscyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBzdXBwb3J0IHRoaXMgZHJhZnQgc2luY2UgaXQgaGFz IG5vIGFwcGxpY2F0aW9uIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRvZGF5J3M8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vZGVy biBtZXRybzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFj dGljYWw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXBwbGljYXRpb248YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGluIGRhdGE8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNlbnRl ciwgd2hpY2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1Y2ggYXM8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTlZHUkU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFuZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVlhMQU4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSXQgc2VlbXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBieXBhc3MgdGhl IE5WTzMgc29sdXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2VsZWN0aW9uPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9jZXNz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBi eSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNoYWhyYW08YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gRGVjIDE0LCAyMDEyLCBh dCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5s b2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV29ya2luZyBncm91cCw8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaXMgdG8gc3Rh cnQgYSAmcXVvdDt0d28gd2VlayZxdW90OyBwb2xsIG9uIGFkb3B0aW5nPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQteHUtbXBs cy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IER1ZSB0byB0 aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdpdGg8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb25lIHdlZWsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBsczxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgd29ya2luZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9y ZykuIFBsZWFzZSBnaXZlIGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRlY2huaWNhbDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5 b3U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhpbmsgdGhhdDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBkb2N1bWVudCBz aG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC08YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvPC9hPiAuPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbGwg dGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXA8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB0aGV5IGFyZSBub3Qg YXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBhbHJlYWR5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzY2xvc2VkLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgdXAgdG8gdmVyc2lv biAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0 aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSVBSPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcG9sbCk8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJzaGFsbCBFdWJh bmtzIHdhcyBsaXN0ZWQgYXMgb25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBoYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaXNjb250aW51ZWQgYWxsIGludGVyYWN0aW9ucyB3aXRo IHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGF1dGhv ciB0ZWFtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNo YWlycyBoYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdHJpZWQgdG88YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb250YWN0IE1h cnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb248YnI+DQomZ3Q7 ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJUFI8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwb2xsLjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdl IGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1 dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvLWF1dGhvci48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC9M b2E8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAobXBscyB3ZyBjby1jaGFpcik8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMb2EgQW5kZXJzc29uJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bG9hLmFuZGVyc3NvbkBlcmlj c3Nvbi5jb20iPmxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPC9hPjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNyIFN0cmF0ZWd5IGFu ZCBTdGFuZGFyZHMgTWFuYWdlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPg0KbG9hQHBpLm51PC9hPjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEVyaWNzc29u IEluYyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBwaG9uZTogJiM0Mzs0NiAxMCA3 MTc8YnI+DQomZ3Q7IDUyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAxMzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOzQ2IDc2NyA3MiA5Mjxicj4NCiZndDsgMTM8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIDwvYT48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDYWJsZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvcjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBzdWJqZWN0IHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbGVseSBmb3I8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlz IGFkZHJlc3NlZC4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSBub3QgdGhl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZGVkIHJlY2lwaWVu dCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3Nl bWluYXRpb24sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3RyaWJ1 dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZTxicj4NCiZn dDsgJmd0OyZndDsgY29udGVudHM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb2YgYW5kPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF0dGFjaG1lbnRzIHRvIHRoaXMg RS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyB1bmxhd2Z1bC4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbW1lZGlhdGVseSBhbmQ8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGVybWFuZW50bHkgZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IGFueSBwcmludG91dC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtcGxzIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCjwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgbXBscyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBs c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCjwvYT48YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBtcGxz IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1w bHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCjwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2691CE0099834E4A9C5044EEC662BB9D44864E6Bdfweml505mbx_-- From davarish@yahoo.com Fri Dec 21 14:40:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C394721F88CF for ; Fri, 21 Dec 2012 14:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, REPTO_QUOTE_YAHOO=2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0M13-ULD5jH for ; Fri, 21 Dec 2012 14:40:23 -0800 (PST) Received: from nm7-vm0.bullet.mail.bf1.yahoo.com (nm7-vm0.bullet.mail.bf1.yahoo.com [98.139.213.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4338F21F88CC for ; Fri, 21 Dec 2012 14:40:23 -0800 (PST) Received: from [98.139.214.32] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 22:40:22 -0000 Received: from [98.139.212.226] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 22:40:22 -0000 Received: from [127.0.0.1] by omp1035.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 22:40:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 553632.74053.bm@omp1035.mail.bf1.yahoo.com Received: (qmail 73576 invoked by uid 60001); 21 Dec 2012 22:40:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356129622; bh=OOkuZxvKTgTbXqU4uvYiNgQqOeWeojdSvq+uqun7FHM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nQt/wERyFWYfFw11vbANn1MT84/qT5t5h752J36gvcB6v0JFcUymh7sw/DfcgfccfLkBkK4XghL/DCwr75TK6kHlsY/UWw6aUWzNxmFPdj15V+d/+MckvJYaNlSf5XNqRHiaI4Me+wWDo000J4zYNDXWF6AOc4xFTrLHhpCZeFI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AhTVdD2yDmm/RC6FmPeJH/40lwePA61UmIgqbhsw3ScW4hmmo/HePAxh6ZwpvvucJb8RW3JkeNqevRCmriIyPLlYh00UAsNjhbZjRQZTvWfTnR/uiMRW4MiP+vE4PQcik2/jgJvTEYoE14h4SjbqEY1J8K/dG5ELYd0YuuN/XnI=; X-YMail-OSG: X4YRdNgVM1nLyk0mNhEz5yYPAuGpsc.wn1mp149v.vXNp1B A1pKtuQjH2Jve8SVHbRMgH5oVaKDpvyYMNQgl1T1.4MXPBwy1Nyy7.Nt7IEi VMbwKDL0IXEjC26fnt41hrVe8Jf3FGPC6c2A6tjOoLy.jB6oSOEYDYv0PY1c SEi5.14iytJUpeZKwiCi_VaFSFj7PiE_qLH7die8KA01MKr2XjZ4aRcrS3FR UVooaX_Gzhi6RrcvyiLYk4CkCJWqPnczO4jnhiEAuSFre8D7dXSB_yzFaGw3 clVpCazszATkc791aZqqfWARM.7bslYakMxXRmLIVj8FL8o2EEYHISXVOmj0 DJIflcdStlXg_.ySqd8JwGD6kgyYPH4jXklmtrFaRSrx_ilNPSE9MEZH5JYJ UijoSxatChmZvEF84RuFqHAvC9YqKfxXmWGvJgXojUwDGZvXYC9fb.JbTItG _fGFObxzarNiecxY9rzHCu3NvU4G5EPdNJa3YXu8ihqBxbQ.jNf21PQwZsMb DB1zvzhYl2anp9bmLbAZTpvsCAwoA_VqX9SSfDn5aS2ZCQx9Y3r6k8TpwwCl 4g4VUAsSIIi6VjMAA.PGE5Woav.UhSYUg6XZ8wiZcikE_zWbM.hKxnMyKxLM lBOwD1akcDgtDyD4DBA-- Received: from [98.248.36.11] by web162504.mail.bf1.yahoo.com via HTTP; Fri, 21 Dec 2012 14:40:21 PST X-Rocket-MIMEInfo: 001.001, THVjeSwKCkkgY2FuIG9ubHkgc2VlIENoaW5hIFRlbGVjb20gYXMgY28tYXV0aG9yLCBhbmQgdGhlIEFwcGxpY2FiaWxpdHkgc2VjdGlvbiBzYXlzIEwyVlBOIGFuZCBMM1ZQTi4gU28gaXMgQ2hpbmEgVGVsZWNvbSB1c2luZyBpdCBmb3IgdGhlaXIgRW50ZXJwcmlzZSBWUE4gc2VydmljZT8gYnV0IHlvdXIgZWFybGllciBlbWFpbHMgc3VnZ2VzdHMgdGhhdCB0aGlzIGlzIG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgcmF0aGVyIGl0IGlzIGZvciBEYXRhIENlbnRlci4gU28gd2hpY2ggb25lIGlzIGl0PyBXaHkgaXMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.129.483 References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> Message-ID: <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com> Date: Fri, 21 Dec 2012 14:40:21 -0800 (PST) From: "S. Davari" To: Lucy yong , Xuxiaohu , Shahram Davari In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="275539708-1985452995-1356129621=:73091" Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "S. Davari" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:40:26 -0000 --275539708-1985452995-1356129621=:73091 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lucy,=0A=0AI can only see China Telecom as co-author, and the Applicability= section says L2VPN and L3VPN. So is China Telecom using it for their Enter= prise VPN service? but your earlier emails suggests that this is not the in= tended usage rather it is for Data Center. So which one is it? Why isn't Ch= ina Telecom speaking on the list and explaining their usage model?=0A=0AAls= o regarding Multicast, this means you need to map Multicast traffic to P2P = PW, which is inferior to other methods such as NVGRE and VXLAN since they n= atively support efficient Multicast.=0A=0AThanks,=0AShahram=0A=0A=0A=0A=0A= =0A=0A________________________________=0A From: Lucy yong =0ATo: S. Davari ; Xuxiaohu ;= Shahram Davari =0ACc: "draft-xu-mpls-in-udp@tools.ie= tf.org" ; "mpls@ietf.org" ; "mpls-chairs@tools.ietf.org" =0ASent: Fri= day, December 21, 2012 1:55:10 PM=0ASubject: RE: [mpls] MPLS client layer o= ver an IGP underlying network=0A =0A=0A =0AShahram,=0A=C2=A0=0APlease see i= nline.=0A=C2=A0=0AFrom:S. Davari [mailto:davarish@yahoo.com] =0ASent: Frida= y, December 21, 2012 2:10 AM=0ATo: Xuxiaohu; Shahram Davari; Lucy yong=0ACc= : draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.iet= f.org=0ASubject: Re: [mpls] MPLS client layer over an IGP underlying networ= k=0A=C2=A0=0AHi,=0A=0AI think we are in a vicious cycle. Could you please c= larify which network operator is asking for MPLS over UDP and what is the a= pplication.=C2=A0 =0A[Lucy] it is indicated in the draft.=0AAlso how do you= plan to address the MPLS Multicast (which is probably more important than = improving the load balancing), given that RFC4023 does not support Multicas= t.=0A[Lucy] MPLS Client Layer is responsible to map multicast traffic to un= derlying transport, which is specified in EVPN and IP VPN. This proposal ju= st requests ingress PE to fill the flow entropy into UDP source port, in wh= ich the flow can be unicast or multicast. =0A=C2=A0=0ARegards,=0ALucy=0A=C2= =A0=0A=0A=0AThanks,=0AShahram=0A=C2=A0=0A=C2=A0=0A=0A______________________= __________=0A =0AFrom:Xuxiaohu =0ATo: Shahram Davari <= davari@broadcom.com>; Lucy yong =0ACc: "draft-xu-mpl= s-in-udp@tools.ietf.org" ; "mpls@ietf.= org" ; "mpls-chairs@tools.ietf.org" =0ASent: Thursday, December 20, 2012 5:56:23 PM=0ASubject: Re: [mpls] = MPLS client layer over an IGP underlying network=0A=0A=0A=0A> -----=E9=82= =AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> =E5=8F=91=E4=BB=B6=E4=BA=BA: mpls-b= ounces@ietf.org [mailto:mpls-bounces@ietf.org] =E4=BB=A3=E8=A1=A8=0A> Shahr= am Davari=0A> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C= =8821=E6=97=A51:31=0A> =E6=94=B6=E4=BB=B6=E4=BA=BA: Lucy yong=0A> =E6=8A=84= =E9=80=81: draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org;= =0A> mpls@ietf.org=0A> =E4=B8=BB=E9=A2=98: Re: [mpls] MPLS client layer ove= r an IGP underlying network=0A> =0A> Please don't mix up things. The MPLS p= rotocol design I agree must be done by=0A> MPLS WG. But the question is whe= ther your proposal meets the network=0A> virtualization requirements.=0A=0A= Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over IP encap= sulation mechanisms have been discussed before?=0A=0ASince MPLS-in-UDP is j= ust intended to be used in the scenarios where MPLS-in-GRE/IP has been used= and is to be used, MPLS-in-UDP should be discussed in the same WG where MP= LS-in-GRE/IP has been discussed.=0A=0AXiaohu=0A=0A> The NVO3 task is to doc= ument the issues, requirements and framework for=0A> NvO3. Then if MPLS ove= r IP looks like a suitable solution that meets the=0A> requirements such as= the scale, mobility, etc, then they will ask MPLS WG for=0A> protocol desi= gn.=0A> =0A> So before proceeding this draft, I think you should take it to= NVO3 WG and=0A> convince them this solution meets their requirements and f= ramework.=0A> =0A> We don't want IETF do design N number of solutions for t= he same problem, do=0A> we?=0A> =0A> -Shahram=0A> =0A> =0A> =0A> Regards,= =0A> Shahram=0A> =0A> =0A> On Dec 20, 2012, at 8:56 AM, "Lucy yong" wrote:=0A> =0A> > Network virtualization overlay is discuss= ed under nvo3 WG. This does not=0A> mean that nvo3 WG has to design a new p= rotocol for a underlying network or a=0A> new protocol for a overlay networ= k. In fact, people there aim on leverage=0A> standard network protocols to = accomplish them. IMO: these expansions on an=0A> existing standard protocol= have to be worked out in the protocol WG group, it=0A> should not give nvo= 3 WG free right to enhance these protocols. For a brand=0A> new protocol fo= r network virtualization overlay, nvo3 WG may be the place to=0A> start.=0A= > >=0A> > Lucy=0A> >=0A> >> -----Original Message-----=0A> >> From: Shahram= Davari [mailto:davari@broadcom.com]=0A> >> Sent: Thursday, December 20, 20= 12 10:34 AM=0A> >> To: Lucy yong=0A> >> Cc: Shane Amante; draft-xu-mpls-in-= udp@tools.ietf.org; mpls@ietf.org;=0A> >> mpls-chairs@tools.ietf.org=0A> >>= Subject: Re: [mpls] MPLS client layer over an IGP underlying network=0A> >= >=0A> >> Network virtualization overlay must be discussed and consented=C2= =A0 in NVO3=0A> >> WG.=0A> >>=0A> >> Regards,=0A> >> Shahram=0A> >>=0A> >>= =0A> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" wro= te:=0A> >>=0A> >>> Hi Shane,=0A> >>>=0A> >>> I understand operator concern = on a new encapsulation to an existing=0A> >> network.=0A> >>>=0A> >>> Howev= er, MPLS-in-UDP does not aim on changing existing SP IP/MPLS=0A> >> network= at all.=0A> >>> MPLS-in-UDP is to enable MPLS client layer to be decoupled= from MPLS=0A> >> server layer and use MPLS client layer as overlay network= and an IGP as=0A> >> a underlying network for transport. Such application = is for DC. You may=0A> >> argue why not use the GRE which is for MPLS layer= over an IGP underling=0A> >> network. We have pointed out in the draft tha= t current routers in DC=0A> >> barely support GRE based load balancing and = MPLS-in-GRE are barely used=0A> >> in SP networks too. Most of routers in D= C perform upd port based load=0A> >> balancing now.=0A> >>>=0A> >>> From th= e architecture perspective, the UDP encapsulation has=0A> >> advantage over= GRE encapsulation too. In UDP encapsulation, the frame=0A> >> header decou= ples the overlay and underlying network clearly, i.e. outer=0A> >> header a= nd overlay header. UDP belongs to outer header, which=0A> >> underlying net= work uses only. However, GRE header has the fields for=0A> >> the overlay n= etwork and uses the key field for flow entropy. For load=0A> >> balancing, = it requires the underlying network uses GRE header too. In=0A> >> short, GR= E ties the overlay and underlying networks together. Since it=0A> >> has no= t used a lot, people are not aware of the disadvantage of such=0A> >> coupl= ing.=0A> >>>=0A> >>> As the industry moves toward network virtualization ov= erlay and=0A> >> decouples overlay networks from the underlying network. A = clear=0A> >> separation of overlay header and underlying header is a "MUST"= in my=0A> >> opinion. If we count GRE as the overlay header, then for IPv4= =0A> >> underlying network, there is no field for the flow entropy. This is= the=0A> >> reason we propose the UDP encapsulation: for an IGP based under= lying=0A> >> network. In fact, it can support any overlay network beside MP= LS client=0A> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).=0A> >>>=0A> >>> You = point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-in-L2TP-=0A> >> in-U= DP schema also provides a overlay (L2TP) and underlying (IP)=0A> >> network= decoupling. L2TP protocol (rfc3931) provides good security=0A> >> mechanis= m and has the embedded control function too. Therefore,=0A> someone=0A> >> = can use it for MPLS client layer over Internet. To have MPLS client=0A> >> = layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP is a=0A> >> o= verkill and too complex. Here we need a schema to support IGP=0A> >> underl= ying transport without touching a overlay header. UDP=0A> >> encapsulation = is the best choice to accomplish that and minimize the=0A> >> changes on ex= isting routers, e.g. change at edge routers, no change on=0A> >> transit ro= uters.=0A> >>>=0A> >>> Regards,=0A> >>> Lucy=0A> >>>=0A> >>>=0A> >>>=0A> >>= >> -----Original Message-----=0A> >>>> From: Xuxiaohu [mailto:xuxiaohu@huaw= ei.com]=0A> >>>> Sent: Thursday, December 20, 2012 4:14 AM=0A> >>>> To: Sha= ne Amante=0A> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-=0A> = >> udp@tools.ietf.org;=0A> >>>> mpls@ietf.org; mpls-chairs@tools.ietf.org= =0A> >>>> Subject: Discussion on how to transport MPLS over UDP tunnels=0A>= >>>>=0A> >>>> Hi Shane,=0A> >>>>=0A> >>>> Thanks for your further comments= and please see my response inline.=0A> >>>>=0A> >>>> Note: I changed the s= ubject line according to Loa's suggestion.=0A> >>>>=0A> >>>>> -----=E9=82= =AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: = Shane Amante [mailto:shane@castlepoint.net]=0A> >>>>> =E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8819=E6=97=A522:38=0A> >>>>> =E6=94= =B6=E4=BB=B6=E4=BA=BA: Xuxiaohu=0A> >>>>> =E6=8A=84=E9=80=81: Rogers, Josh;= Shahram Davari; draft-xu-mpls-in-=0A> >>>> udp@tools.ietf.org;=0A> >>>>> m= pls@ietf.org; mpls-chairs@tools.ietf.org=0A> >>>>> =E4=B8=BB=E9=A2=98: Re: = [mpls] poll to see if we have support to make draft-xu-=0A> >>>> mpls-in-ud= p an=0A> >>>>> mpls working group document=0A> >>>>>=0A> >>>>> Xiaohu,=0A> = >>>>>=0A> >>>>> On Dec 18, 2012, at 11:50 PM, Xuxiaohu =0A> wrote:=0A> >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> >= >>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Shane Amante [mailto:shane@castlepoint.= net]=0A> >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6= =9C=8819=E6=97=A511:58=0A> >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Rogers, Jos= h=0A> >>>>>>> =E6=8A=84=E9=80=81: Shahram Davari; Xuxiaohu; draft-xu-mpls-i= n-=0A> >>>> udp@tools.ietf.org;=0A> >>>>>>> mpls@ietf.org; mpls-chairs@tool= s.ietf.org=0A> >>>>>>> =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see if we hav= e support to make draft-xu-=0A> >>>> mpls-in-udp=0A> >>>>> an=0A> >>>>>>> m= pls working group document=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>> On Dec 18, 2= 012, at 8:50 AM, "Rogers, Josh"=0A> >>>> =0A> >>>>= >>> wrote:=0A> >>>>>>>> I share your SP perspective, and do not see the pro= blem this=0A> >>>> solution=0A> >>>>>>>> addresses in practice any longer.= =0A> >>>>>>>=0A> >>>>>>> +1.=C2=A0 Please do not define yet another MPLS-ov= er-IP encapsulation.=0A> >>>> The=0A> >>>>> IETF=0A> >>>>>>> already standa= rdized MPLS over GRE.=C2=A0 The IETF has also=0A> >>>> standardized=0A> >>>= >> MPLS=0A> >>>>>>> over L2TPv3/UDP/IP, which had seen some deployment in a= t least=0A> >> one,=0A> >>>> very=0A> >>>>>>> large operator network that I= 'm aware of to support carriage of=0A> >>>> L3VPN over=0A> >>>>> an=0A> >>>= >>>> IP-only network.=0A> >>>>>>=0A> >>>>>> Hi Shane,=0A> >>>>>>=0A> >>>>>>= Thank you for telling us there are actual deployments of MPLS over=0A> >>>= > IP in at=0A> >>>>> least one, very large operator network. This fact must= be very=0A> >>>> valuable to those=0A> >>>>> people who had believed there= is no application of MPLS over IP in=0A> >>>> today's SP=0A> >>>>> network= s.=0A> >>>>>>=0A> >>>>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L= 2TPv3=0A> >>>>>>> [NOTE: the dates the above were published was back in the= 2006=0A> >>>>> timeframe!]=0A> >>>>>>>=C2=A0 RFC 4665 for requirements rel= ated to VPLS that say that VPLS=0A> >>>> may be=0A> >>>>>>> carried over L2= TPv3=0A> >>>>>>>=C2=A0 And, here's evidence showing that at least one vendo= r has=0A> >>>>> implemented=0A> >>>>>>> IPVPN's over L2TPv3:=0A> >> http://= www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html =0A> >>>>>>= =0A> >>>>>> Thanks again for sharing the above information. As mentioned in= =0A> >>>> this draft=0A> >>>>> AND other drafts, the mechanism of performin= g hash calculation on=0A> >> the=0A> >>>> Session=0A> >>>>> ID field in the= L2TPv3 header or the Key field in the GRE header as=0A> >>>> defined in=0A= > >>>>> [RFC 5640] is not widely supported by existing core routers so far.= =0A> >>>>>=0A> >>>>> FWIW, I have had success, in the relatively recent pas= t, in=0A> >>>> requesting a core=0A> >>>>> router vendor to support changes= to the input-keys used in hash=0A> >>>> calculations in=0A> >>>>> _existin= g_ hardware, already deployed (extensively) throughout my=0A> >>>> network.= =0A> >>>>> Further, I suspect that most large network operators are savvy= =0A> >> folks=0A> >>>> and=0A> >>>>> understand the internal architecture o= f their HW fairly well.=C2=A0 As a=0A> >>>> result, those=0A> >>>>> same op= erators know what is and is not technically possible in this=0A> >>>> regar= d.=0A> >>>>> Thus, it may be a question of "methods" necessary to convince = their=0A> >>>> HW=0A> >>>>> supplier(s) to make appropriate changes in thei= r equipment to=0A> >> achieve=0A> >>>> their=0A> >>>>> business goals.=C2= =A0 :-)=C2=A0 However, this may not even be necessary ...=0A> >> see=0A> >>= >> below.=0A> >>>>=0A> >>>> Could you please briefly explain how to make th= e above change in=0A> >>>> EXISTING hardware of already deployed core route= rs?=0A> >>>>=0A> >>>>>> In contrast, most existing core routers are already= capable of=0A> >>>> balancing IP=0A> >>>>> traffic flows based on the hash= of the five-tuple of UDP packets.=0A> >> By=0A> >>>> using the=0A> >>>>> M= PLS-in-UDP encapsulation, the already available load-balancing=0A> >>>> cap= ability of=0A> >>>>> most existing core routers can be leveraged without re= quiring any=0A> >>>> change to=0A> >>>>> them. That is the major motivation= of this draft.=0A> >>>>>=0A> >>>>> If this is a concern, then why not enca= psulate the traffic in=0A> >>>> MPLS/L2TPv3, which=0A> >>>>> uses UDP/IP, i= n the first place?=0A> >>>>=0A> >>>> If I understand it correctly, you pref= er to use MPLS-in-L2TPv3-in-=0A> >> UDP=0A> >>>> instead of MPLS-in-UDP, ri= ght?=0A> >>>>=0A> >>>>> IMHO, a better proposal may be to consider a [minor= ] (?) change to=0A> >>>> RFC 3931,=0A> >>>>> which would allow the connecti= on used for data packets (not control=0A> >>>> packets)=0A> >>>>> to use a = varying set of source ports (or, source IP addresses),=0A> >> based=0A> >>>= > on a hash=0A> >>>>> calculation, to achieve better load-balancing over ex= isting=0A> >> equipment=0A> >>>> in an=0A> >>>>> IP-only core.=C2=A0 L2TP e= nd-system implementations would be better off=0A> >>>> just using=0A> >>>>>= the "Session ID" (and "Cookie") fields as the demultiplexor to=0A> >>>> as= sociate=0A> >>>>> incoming packets with the associated L2TP Control Channel= .=C2=A0 In fact,=0A> >>>> it's not=0A> >>>>> clear to me that existing impl= ementations may /already/ do this,=0A> >>>> making any=0A> >>>>> "check" on= the incoming source port unnecessary for L2TP end-system=0A> >>>>> impleme= ntations.=0A> >>>>>=0A> >>>>> The beauty of the above approach is:=0A> >>>>= > 1) I would think that the above is most likely a change that is=0A> >>>> = limited to the=0A> >>>>> "control channel" (software) of existing L2TP end-= system=0A> >>>> implementations.=0A> >>>>> Heck, it may even be backwards c= ompatible with existing L2TPv3=0A> >>>>> implementations.=C2=A0 (L2TPv3 imp= lementors would need to comment on=0A> >> that).=0A> >>>>=0A> >>>> IMHO, no= matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,=C2=A0 the hardware=0A> >> of= =0A> >>>> PE routers needs to be upgraded, e.g., ingress PE routers need to= =0A> >> fill=0A> >>>> in an entropy value in the source port field of UDP h= eaders.=0A> >>>>=0A> >>>>> 2) There is a substantial added security one get= s by using "Session=0A> >>>> ID" and=0A> >>>>> "Cookie" fields to ensure th= e received L2TPv3 packet is intended=0A> >> for=0A> >>>> the=0A> >>>>> iden= tified session.=C2=A0 Quoting from Section 8.2 of RFC 3931:=0A> >>>>> ---sn= ip---=0A> >>>>>=C2=A0 L2TPv3 provides traffic separation for its VPNs via a= 32-bit=0A> >>>> Session=0A> >>>>>=C2=A0 ID in the L2TPv3 data header.=C2= =A0 When present, the L2TPv3 Cookie=0A> >>>>>=C2=A0 (described in Section 4= .1), provides an additional check to=0A> >> ensure=0A> >>>>>=C2=A0 that an = arriving packet is intended for the identified session.=0A> >>>>>=C2=A0 Thu= s, use of a Cookie with the Session ID provides an extra=0A> >>>> guarantee= =0A> >>>>>=C2=A0 that the Session ID lookup was performed properly and that= the=0A> >>>>>=C2=A0 Session ID itself was not corrupted in transit.=0A> >>= >>> ---snip---=0A> >>>>> ... in regard to this question alone, I know the S= ecurity Area=0A> >> folks=0A> >>>> have, in the=0A> >>>>> past, had /substa= ntial/ concerns about encapsulation of MPLS over=0A> >> IP=0A> >>>> transpo= rt.=0A> >>>>> In fact, this is why you see text in Section 7.6, "Security",= of=0A> >> RFC=0A> >>>> 4665.=0A> >>>>> (There's likely similar language in= other drafts that use MPLS for=0A> >>>> transport).=0A> >>>>> While I'm no= t sure that Security Area folks pay much attention to=0A> >>>> daily traffi= c on=0A> >>>>> the MPLS WG mailing list, I'm fairly confident this concern = will=0A> >>>> arise if/when this=0A> >>>>> draft goes to the IESG ...=0A> >= >>>=0A> >>>> If I understand it correctly, the reason for your preference o= f=0A> >> MPLS-=0A> >>>> in-L2TPv3-in-UDP is that it has an added security f= eature. If that=0A> >> is=0A> >>>> so concerned, can you explain why MPLS-i= n-GRE is far more popular=0A> >> than=0A> >>>> MPLS-in-L2TP in practice?=0A= > >>>>=0A> >>>> Best regards,=0A> >>>> Xiaohu=0A> >>>>=0A> >>>>> 3) Finally= , this approach only affects the end-systems that=0A> >> implement=0A> >>>>= L2TP, for=0A> >>>>> tunneling of MPLS/IP, and does not require an entire i= ndustry to=0A> >>>> support=0A> >>>>> MPLS/UDP encapsulation in their produ= ct lines.=0A> >>>>>=0A> >>>>> -shane=0A> >>>>>=0A> >>>>>=0A> >>>>>>=0A> >>>= >>> Best regards,=0A> >>>>>> Xiaohu=0A> >>>>>>=0A> >>>>>>> If there was mar= ket demand for MPLS over IP, then clearly it=0A> >> would=0A> >>>> have=0A>= >>>>> been=0A> >>>>>>> more widely implemented by equipment vendors, with = either MPLS=0A> >>>> over=0A> >>>>> GRE or=0A> >>>>>>> MPLS over L2TPv3.=C2= =A0 (Where there's a will, there's a way).=C2=A0 I=0A> >> would=0A> >>>> no= te=0A> >>>>> that=0A> >>>>>>> the most likely reasons this did not pan out = was there are=0A> >> several,=0A> >>>> practical=0A> >>>>>>> operational be= nefits one gets from going with native MPLS=0A> >>>>>>> encapsulation/switc= hing within the data plane, namely:=0A> >>>>>>> - MPLS Fast Re-Route=0A> >>= >>>>> - MPLS Traffic Engineering=0A> >>>>>>> ... to name, but a few.=C2=A0 = Those have tended to be quite compelling=0A> >>>>> arguments=0A> >>>>>>> to= 'upgrade' network HW to support MPLS encapsulation/switching.=0A> >>>>>>>= =0A> >>>>>>> -shane=0A> >>>>>>>=0A> >>>>>>>=0A> >>>>>>>> -Josh=0A> >>>>>>>>= =0A> >>>>>>>>=0A> >>>>>>>> On 12/18/12 12:31 AM, "Shahram Davari" =0A> >>>>> wrote:=0A> >>>>>>>>=0A> >>>>>>>>> For service provid= er domain, MPLS over IP is legacy and there=0A> >> is=0A> >>>> no need=0A> = >>>>>>>>> to improve it.=0A> >>>>>>>>>=0A> >>>>>>>>> Regards,=0A> >>>>>>>>>= Shahram=0A> >>>>>>>>>=0A> >>>>>>>>>=0A> >>>>>>>>> On Dec 17, 2012, at 8:02= PM, "Xuxiaohu" =0A> >>>>> wrote:=0A> >>>>>>>>>=0A> >>= >>>>>>>> Shahram,=0A> >>>>>>>>>>=0A> >>>>>>>>>> This draft is ONLY intended= to provide a MPLS-over-IP=0A> >>>> encapsulation=0A> >>>>>>>>>> method wit= h a better load-balancing applicability so far to=0A> >>>> those=0A> >>>>>>= >>>> operators who happen to require transporting MPLS application=0A> >>>>= traffic=0A> >>>>>>>>>> across IP networks. I believe MPLS-based VPN over I= P, NVGRE=0A> >> and=0A> >>>>> VXLAN=0A> >>>>>>>>>> each have their own advo= cators and use cases. If you=0A> >> absolutely=0A> >>>> believe=0A> >>>>>>>= >>> it's meaningless of transporting MPLS application traffic=0A> >>>> acro= ss IP=0A> >>>>>>>>>> networks and therefore those existing RFCs related to = MPLS=0A> >> over=0A> >>>> IP=0A> >>>>>>>>>> tunneling mechanisms should be = moved to Historic status,=0A> >> please=0A> >>>> say=0A> >>>>> so.=0A> >>>>= >>>>>>=0A> >>>>>>>>>> By the way, it seems this=0A> >>>>>>>>>> (http://www.= ietf.org/mail- =0A> >>>> archive/web/nvo3/current/msg01864.html) is=0A> >>>= >>>>>>> just the right thread suitable for you to make the following=0A> >>= >> argument=0A> >>>>>>>>>> (i.e., whether or not MPLS-based VPN is applicab= le to data=0A> >>>> centers). I=0A> >>>>>>>>>> had thought you would speak = up at that time. Sadly,=0A> >>>> surprisingly silent=0A> >>>>>>>>>> till no= w.=0A> >>>>>>>>>>=0A> >>>>>>>>>> Sigh, I didn't intend to say the above oth= erwise.=0A> >>>>>>>>>>=0A> >>>>>>>>>> Xiaohu=0A> >>>>>>>>>>=0A> >>>>>>>>>>>= -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=0A> >>>>>>>>>>> =E5=8F=91= =E4=BB=B6=E4=BA=BA: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]=0A= > >> =E4=BB=A3=0A> >>>> =E8=A1=A8=0A> >>>>>>> S.=0A> >>>>>>>>>>> Davari=0A>= >>>>>>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=88= 15=E6=97=A513:34=0A> >>>>>>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Loa Andersson= =0A> >>>>>>>>>>> =E6=8A=84=E9=80=81: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org;=0A> >>>>>>>>>>> mpls-chairs@tools.ietf.org=0A> >>>>>>>>>>> = =E4=B8=BB=E9=A2=98: Re: [mpls] poll to see if we have support to make=0A> >= >>>>>>>>>> draft-xu-mpls-in-udp an=0A> >>>>>>>>>>> mpls working group docum= ent=0A> >>>>>>>>>>>=0A> >>>>>>>>>>> I don't support this draft since it has= no application in=0A> >>>> today's=0A> >>>>>>>>>>> modern metro=0A> >>>>>>= >>>>> and core, where MPLS is dominant, and its only practical=0A> >>>> app= lication=0A> >>>>>>>>>>> in in data=0A> >>>>>>>>>>> center, which already i= s crowded with other solutions such as=0A> >>>> NVGRE=0A> >>>>> and=0A> >>>= >>>>>>>> VXLAN.=0A> >>>>>>>>>>>=0A> >>>>>>>>>>> It seems the authors are tr= ying to bypass the NVO3 solution=0A> >>>> selection=0A> >>>>>>>>>>> process= =0A> >>>>>>>>>>> by advancing the draft in MPLS WG.=0A> >>>>>>>>>>>=0A> >>>= >>>>>>>> Regards,=0A> >>>>>>>>>>> Shahram=0A> >>>>>>>>>>>=0A> >>>>>>>>>>>= =0A> >>>>>>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson wro= te:=0A> >>>>>>>>>>>=0A> >>>>>>>>>>>> Working group,=0A> >>>>>>>>>>>>=0A> >>= >>>>>>>>>> This is to start a "two week" poll on adopting=0A> >>>>>>>>>>>> = draft-xu-mpls-in-udp-06 as an MPLS working group document.=0A> >>>>>>>>>>>>= Due to the holiday season this poll has been extended with=0A> >>>> one we= ek.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> Please send your comments (support/no= t support) to the mpls=0A> >>>>> working=0A> >>>>>>>>>>>> group mailing lis= t (mpls at ietf.org). Please give an=0A> >>>> technical=0A> >>>>>>>>>>>> mo= tivation for your support/not support, especially if you=0A> >>>> think tha= t=0A> >>>>>>>>>>>> the document should not be adopted as a working group=0A= > >>>> document.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> This poll ends January 0= 7, 2013.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> There is one IPR claim against t= his document -=0A> >>>>>>>>>>>> https://datatracker.ietf.org/ipr/1941/ .=0A= > >>>>>>>>>>>>=0A> >>>>>>>>>>>> All the active co-authors has stated on the= working group=0A> >>>> mailing list=0A> >>>>>>>>>>>> that they are not awa= re of any other IPR claims than those=0A> >>>> already=0A> >>>>>>>>>>>> dis= closed.=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> However, up to version -03 (the d= ocument that we used for=0A> >> the=0A> >>>> IPR=0A> >>>>>>>>>>>> poll)=0A>= >>>>>>>>>>>> Marshall Eubanks was listed as one of the authors. Marshall= =0A> >>>> has=0A> >>>>>>>>>>>> discontinued all interactions with the IETF,= including the=0A> >>>> author team=0A> >>>>>>>>>>>> of draft-xu-mpls-in-ud= p-06. The working group chairs has=0A> >>>> tried to=0A> >>>>>>>>>>>> conta= ct Marshall by other means, to try get a response on=0A> >> the=0A> >>>> IP= R=0A> >>>>>>>>>>>> poll.=0A> >>>>>>>>>>>> We have had no success in this.= =0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> From version -04 the authors decided to = remove Marshall as a=0A> >>>>>>>>>>>> co-author.=0A> >>>>>>>>>>>>=0A> >>>>>= >>>>>>> /Loa=0A> >>>>>>>>>>>> (mpls wg co-chair)=0A> >>>>>>>>>>>> --=0A> >>= >>>>>>>>>>=0A> >>>>>>>>>>>>=0A> >>>>>>>>>>>> Loa Andersson=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email:= =0A> >>>>>>>>>>> loa.andersson@ericsson.com=0A> >>>>>>>>>>>> Sr Strategy an= d Standards Manager=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu=0A> = >>>>>>>>>>>> Ericsson Inc=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 phone: +46 10 717=0A> 52=0A> >> 1= 3=0A> >>>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +46 767 72 92=0A> 13=0A> >>>>>>>>>>>> __________________________= _____________________=0A> >>>>>>>>>>>> mpls mailing list=0A> >>>>>>>>>>>> m= pls@ietf.org=0A> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls = =0A> >>>>>>>>>>> _______________________________________________=0A> >>>>>>= >>>>> mpls mailing list=0A> >>>>>>>>>>> mpls@ietf.org=0A> >>>>>>>>>>> https= ://www.ietf.org/mailman/listinfo/mpls =0A> >>>>>>>>>> _____________________= __________________________=0A> >>>>>>>>>> mpls mailing list=0A> >>>>>>>>>> = mpls@ietf.org=0A> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls =0A= > >>>>>>>>> _______________________________________________=0A> >>>>>>>>> m= pls mailing list=0A> >>>>>>>>> mpls@ietf.org=0A> >>>>>>>>> https://www.ietf= .org/mailman/listinfo/mpls =0A> >>>>>>>>=0A> >>>>>>>>=0A> >>>>>>>> This E-m= ail and any of its attachments may contain Time Warner=0A> >>>> Cable=0A> >= >>>>>> proprietary information, which is privileged, confidential, or=0A> >= >>> subject to=0A> >>>>>>> copyright belonging to Time Warner Cable. This E= -mail is intended=0A> >>>> solely for=0A> >>>>> the=0A> >>>>>>> use of the = individual or entity to which it is addressed. If you=0A> >>>> are not the= =0A> >>>>>>> intended recipient of this E-mail, you are hereby notified tha= t=0A> >>>> any=0A> >>>>> dissemination,=0A> >>>>>>> distribution, copying, = or action taken in relation to the=0A> >> contents=0A> >>>> of and=0A> >>>>= >>> attachments to this E-mail is strictly prohibited and may be=0A> >>>> u= nlawful. If you=0A> >>>>>>> have received this E-mail in error, please noti= fy the sender=0A> >>>> immediately and=0A> >>>>>>> permanently delete the o= riginal and any copy of this E-mail and=0A> >>>> any printout.=0A> >>>>>>>>= _______________________________________________=0A> >>>>>>>> mpls mailing = list=0A> >>>>>>>> mpls@ietf.org=0A> >>>>>>>> https://www.ietf.org/mailman/l= istinfo/mpls =0A> >>>=0A> >>> _____________________________________________= __=0A> >>> mpls mailing list=0A> >>> mpls@ietf.org=0A> >>> https://www.ietf= .org/mailman/listinfo/mpls =0A> ___________________________________________= ____=0A> mpls mailing list=0A> mpls@ietf.org=0A> https://www.ietf.org/mailm= an/listinfo/mpls =0A_______________________________________________=0Ampls = mailing list=0Ampls@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/mpls --275539708-1985452995-1356129621=:73091 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lucy,

I can on= ly see China Telecom as co-author, and the Applicability section says L2VPN= and L3VPN. So is China Telecom using it for their Enterprise VPN service? = but your earlier emails suggests that this is not the intended usage rather= it is for Data Center. So which one is it? Why isn't China Telecom speakin= g on the list and explaining their usage model?

Also regarding Multi= cast, this means you need to map Multicast traffic to P2P PW, which is infe= rior to other methods such as NVGRE and VXLAN since they natively support e= fficient Multicast.

Thanks,
Shahram




From: Lucy yong <lucy.yong@huawei.com>
To: S. Davari <davarish@yahoo.c= om>; Xuxiaohu <xuxiaohu@huawei.com>; Shahram Davari <davari@bro= adcom.com>
Cc: "dra= ft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org&g= t;; "mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ietf.org" <= ;mpls-chairs@tools.ietf.org>
= Sent: Friday, December 21, 2012 1:55:10 PM
Subject: RE: [mpls] MPLS client layer over = an IGP underlying network

=0A=0A =0A =0A<= style>=0A=0A
=0A=0A
Shahram,
= =0A
 
=0A
Please see inline.<= /div> =0A
 
=0A
=0A
=0A
= =0A
From: S. Davari [mailto:dav= arish@yahoo.com]=0A
=0ASent: Friday, December 21, 2012 2:10 AM=0ATo: Xuxiaohu; Shahram Davari; Lucy yong
=0ACc: draft-x= u-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
= =0ASubject: Re: [mpls] MPLS client layer over an IGP underlying netw= ork
=0A
=0A
=0A
 
=0A
=0A
Hi,
=0A
=0AI think we a= re in a vicious cycle. Could you please clarify which network operator is a= sking for MPLS over UDP and what is the application. =0A
=0A
[Lucy] it is indicated in the draft.
=0AAlso how do you plan to address the MPLS Multicast (which= is probably more important than improving the load balancing), given that = RFC4023 does not support Multicast.
=0A
[Lucy] MPLS Cli= ent Layer is responsible to map multicast traffic to underlying transport, = which is specified in EVPN and IP VPN.=0A This proposal just requests ingre= ss PE to fill the flow entropy into UDP source port, in which the flow can = be unicast or multicast.=0A
=0A
 
=0A
Regards,
=0A
Lucy
=0A
 
=0A

=0A
=0AThanks,
=0AShahram
=0A
=0A
 
=0A
=0A
=0A
&nb= sp;
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
From: = Xuxiaohu <xuxiaohu@huawei.com>
=0ATo: Shahram Davari <da= vari@broadcom.com>; Lucy yong <lucy.yong@huawei.com>=0A
=0AC= c: "draft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools= .ietf.org>; "mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ie= tf.org" <mpls-chairs@tools.ietf.org>=0A
=0ASent: Thursday, = December 20, 2012 5:56:23 PM
=0ASubject: Re: [mpls] MPLS client l= ayer over an IGP underlying network
=0A
=0A

=0A
= =0A
=0A> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=0A> =E5=8F=91=E4=BB=B6=E4=BA=BA:=0Ampls-bounces@ietf= .org [mailto:mpls-bounces@iet= f.org]=0A=E4=BB=A3=E8=A1=A8
=0A> S= hahram Davari
=0A> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8821=E6=97=A5= =0A 1:31
=0A> =E6=94=B6=E4=BB=B6=E4=BA=BA: Lucy yong
=0A> =E6=8A=84=E9=80=81= :=0Ad= raft-xu-mpls-in-udp@tools.ietf.org;=0Ampls-chairs@tools.ietf.org;
=0A> mpls@ietf.org
=0A> =E4=B8=BB=E9=A2=98: Re: [mpls] MPLS client layer over an IGP underlying net= work
=0A>
=0A> Please don't mix up things. The MPLS protocol d= esign I agree must be done by
=0A> MPLS WG. But the question is wheth= er your proposal meets the network
=0A> virtualization requirements.<= br>=0A
=0ACan you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS = over IP encapsulation mechanisms have been discussed before?
=0A
=0AS= ince MPLS-in-UDP is just intended to be used in the scenarios where MPLS-in= -GRE/IP has been used and is to be used, MPLS-in-UDP should be discussed in= the same WG where MPLS-in-GRE/IP has been discussed.
=0A
=0AXiaohu=0A
=0A> The NVO3 task is to document the issues, requirements and = framework for
=0A> NvO3. Then if MPLS over IP looks like a suitable s= olution that meets the
=0A> requirements such as the scale, mobility,= etc, then they will ask MPLS WG for
=0A> protocol design.
=0A>=
=0A> So before proceeding this draft, I think you should take it to= NVO3 WG and
=0A> convince them this solution meets their requirement= s and framework.
=0A>
=0A> We don't want IETF do design N numb= er of solutions for the same problem, do
=0A> we?
=0A>
=0A&= gt; -Shahram
=0A>
=0A>
=0A>
=0A> Regards,
=0A= > Shahram
=0A>
=0A>
=0A> On Dec 20, 2012, at 8:56 AM= , "Lucy yong" <lucy.yong@huawei.= com> wrote:
=0A>
=0A> > Network virtualization overl= ay is discussed under nvo3 WG. This does not
=0A> mean that nvo3 WG h= as to design a new protocol for a underlying network or a
=0A> new pr= otocol for a overlay network. In fact, people there aim on leverage
=0A&= gt; standard network protocols to accomplish them. IMO: these expansions on= an
=0A> existing standard protocol have to be worked out in the prot= ocol WG group, it
=0A> should not give nvo3 WG free right to enhance = these protocols. For a brand
=0A> new protocol for network virtualiza= tion overlay, nvo3 WG may be the place to
=0A> start.
=0A> >=
=0A> > Lucy
=0A> >
=0A> >> -----Original Mes= sage-----
=0A> >> From: Shahram Davari [mailto:davari@broadcom.com]
=0A> >> Sent: Th= ursday, December 20, 2012 10:34 AM
=0A> >> To: Lucy yong
=0A= > >> Cc: Shane Amante; draft-xu-mpls-in-udp@tools.ietf.org;=0Ampls@ietf.org;
=0A> >> mpls-chairs@tools.ietf.org
= =0A> >> Subject: Re: [mpls] MPLS client layer over an IGP underlyi= ng network
=0A> >>
=0A> >> Network virtualization o= verlay must be discussed and consented  in NVO3
=0A> >> WG= .
=0A> >>
=0A> >> Regards,
=0A> >> Shah= ram
=0A> >>
=0A> >>
=0A> >> On Dec 20, = 2012, at 7:39 AM, "Lucy yong" <l= ucy.yong@huawei.com> wrote:
=0A> >>
=0A> >>&= gt; Hi Shane,
=0A> >>>
=0A> >>> I understand = operator concern on a new encapsulation to an existing
=0A> >> = network.
=0A> >>>
=0A> >>> However, MPLS-in-U= DP does not aim on changing existing SP IP/MPLS
=0A> >> network= at all.
=0A> >>> MPLS-in-UDP is to enable MPLS client layer= to be decoupled from MPLS
=0A> >> server layer and use MPLS cl= ient layer as overlay network and an IGP as
=0A> >> a underlyin= g network for transport. Such application is for DC. You may
=0A> >= ;> argue why not use the GRE which is for MPLS layer over an IGP underli= ng
=0A> >> network. We have pointed out in the draft that curre= nt routers in DC
=0A> >> barely support GRE based load balancin= g and MPLS-in-GRE are barely used
=0A> >> in SP networks too. M= ost of routers in DC perform upd port based load
=0A> >> balanc= ing now.
=0A> >>>
=0A> >>> From the architect= ure perspective, the UDP encapsulation has
=0A> >> advantage ov= er GRE encapsulation too. In UDP encapsulation, the frame
=0A> >&g= t; header decouples the overlay and underlying network clearly, i.e. outer<= br>=0A> >> header and overlay header. UDP belongs to outer header,= which
=0A> >> underlying network uses only. However, GRE heade= r has the fields for
=0A> >> the overlay network and uses the k= ey field for flow entropy. For load
=0A> >> balancing, it requi= res the underlying network uses GRE header too. In
=0A> >> shor= t, GRE ties the overlay and underlying networks together. Since it
=0A&g= t; >> has not used a lot, people are not aware of the disadvantage of= such
=0A> >> coupling.
=0A> >>>
=0A> >= >> As the industry moves toward network virtualization overlay and=0A> >> decouples overlay networks from the underlying network. A= clear
=0A> >> separation of overlay header and underlying head= er is a "MUST" in my
=0A> >> opinion. If we count GRE as the ov= erlay header, then for IPv4
=0A> >> underlying network, there i= s no field for the flow entropy. This is the
=0A> >> reason we = propose the UDP encapsulation: for an IGP based underlying
=0A> >&= gt; network. In fact, it can support any overlay network beside MPLS client=
=0A> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).
=0A> >&= gt;>
=0A> >>> You point out using MPLS-in-L2TP-in-UDP ins= tead. Yes, MPLS-in-L2TP-
=0A> >> in-UDP schema also provides a = overlay (L2TP) and underlying (IP)
=0A> >> network decoupling. = L2TP protocol (rfc3931) provides good security
=0A> >> mechanis= m and has the embedded control function too. Therefore,
=0A> someone<= br>=0A> >> can use it for MPLS client layer over Internet. To have= MPLS client
=0A> >> layer over an IGP underling network, IMO: = MPLS-in-L2TP-in-UDP is a
=0A> >> overkill and too complex. Here= we need a schema to support IGP
=0A> >> underlying transport w= ithout touching a overlay header. UDP
=0A> >> encapsulation is = the best choice to accomplish that and minimize the
=0A> >> cha= nges on existing routers, e.g. change at edge routers, no change on
=0A&= gt; >> transit routers.
=0A> >>>
=0A> >>&g= t; Regards,
=0A> >>> Lucy
=0A> >>>
=0A>= >>>
=0A> >>>
=0A> >>>> -----Orig= inal Message-----
=0A> >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
=0A> >>= ;>> Sent: Thursday, December 20, 2012 4:14 AM
=0A> >>>= > To: Shane Amante
=0A> >>>> Cc: Rogers, Josh; Shahram= Davari; draft-xu-mpls-in-
=0A> >> udp@tools.ietf.org;
=0A> >>>> mpls@ietf.org; =0Ampls-chairs@tools.ietf.org
=0A> >>>> Subje= ct: Discussion on how to transport MPLS over UDP tunnels
=0A> >>= ;>>
=0A> >>>> Hi Shane,
=0A> >>>>=
=0A> >>>> Thanks for your further comments and please se= e my response inline.
=0A> >>>>
=0A> >>>&g= t; Note: I changed the subject line according to Loa's suggestion.
=0A&g= t; >>>>
=0A> >>>>> -----=E9=82=AE=E4=BB=B6=E5= =8E=9F=E4=BB=B6-----
=0A> >>= ;>>> =E5=8F=91=E4=BB=B6=E4=BA=BA:= Shane Amante [mailto:shane@castl= epoint.net]
=0A> >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2012=E5=B9=B412=E6=9C=8819=E6=97=A5=0A 22:38
=0A> >>>>> =E6=94=B6=E4=BB= =B6=E4=BA=BA: Xuxiaohu
=0A> >&= gt;>>> =E6=8A=84=E9=80=81: Rogers, = Josh; Shahram Davari; draft-xu-mpls-in-
=0A> >>>> udp@tools.ietf.org;
=0A> >>&= gt;>> mpls@ietf.org; =0Ampls-chairs@tools.ietf.org
=0A&= gt; >>>>> =E4=B8=BB=E9=A2=98:= Re: [mpls] poll to see if we have support to make draft-xu-
=0A> >= ;>>> mpls-in-udp an
=0A> >>>>> mpls working g= roup document
=0A> >>>>>
=0A> >>>>&g= t; Xiaohu,
=0A> >>>>>
=0A> >>>>> = On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com>
=0A> wrote:
=0A> >>>= >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=0A> >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA= =BA: Shane Amante [mailto:shane@castlepoint.net]
=0A> >>= >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8819=E6=97=A5=0A 11:= 58
=0A> >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Rogers, Josh
=0A> >>>>>>= ;> =E6=8A=84=E9=80=81: Shahram Davari; Xu= xiaohu; draft-xu-mpls-in-
=0A> >>>> udp@tools.ietf.org;
=0A> >>>>>>&= gt; mpls@ietf.org; =0Ampls-chairs@tools.ietf.org
=0A> >= >>>>>> =E4=B8=BB=E9=A2=98:= Re: [mpls] poll to see if we have support to make draft-xu-
=0A> >= ;>>> mpls-in-udp
=0A> >>>>> an
=0A> >= ;>>>>>> mpls working group document
=0A> >>&g= t;>>>>
=0A> >>>>>>>
=0A> >&= gt;>>>>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh"
=0A&= gt; >>>> <josh= .rogers@twcable.com>
=0A> >>>>>>> wrote:<= br>=0A> >>>>>>>> I share your SP perspective, an= d do not see the problem this
=0A> >>>> solution
=0A&g= t; >>>>>>>> addresses in practice any longer.
= =0A> >>>>>>>
=0A> >>>>>>>= ; +1.  Please do not define yet another MPLS-over-IP encapsulation.=0A> >>>> The
=0A> >>>>> IETF
=0A&g= t; >>>>>>> already standardized MPLS over GRE.  T= he IETF has also
=0A> >>>> standardized
=0A> >&g= t;>>> MPLS
=0A> >>>>>>> over L2TPv3/UDP= /IP, which had seen some deployment in at least
=0A> >> one,=0A> >>>> very
=0A> >>>>>>> larg= e operator network that I'm aware of to support carriage of
=0A> >= >>> L3VPN over
=0A> >>>>> an
=0A> >&= gt;>>>>> IP-only network.
=0A> >>>>>>= ;
=0A> >>>>>> Hi Shane,
=0A> >>>>= >>
=0A> >>>>>> Thank you for telling us there= are actual deployments of MPLS over
=0A> >>>> IP in at=0A> >>>>> least one, very large operator network. This= fact must be very
=0A> >>>> valuable to those
=0A>= >>>>> people who had believed there is no application of MP= LS over IP in
=0A> >>>> today's SP
=0A> >>>= ;>> networks.
=0A> >>>>>>
=0A> >>= >>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3=
=0A> >>>>>>> [NOTE: the dates the above were pu= blished was back in the 2006
=0A> >>>>> timeframe!]=0A> >>>>>>>  RFC 4665 for requirements relat= ed to VPLS that say that VPLS
=0A> >>>> may be
=0A>= >>>>>>> carried over L2TPv3
=0A> >>>&g= t;>>>  And, here's evidence showing that at least one vendor = has
=0A> >>>>> implemented
=0A> >>>>= >>> IPVPN's over L2TPv3:
=0A> >> =0Ahttp://www.cisco.com/en/US/docs/ios/12_0s/feature/g= uide/csgl3vpn.html
=0A> >>>>>>
=0A> >= >>>>> Thanks again for sharing the above information. As men= tioned in
=0A> >>>> this draft
=0A> >>>>= ;> AND other drafts, the mechanism of performing hash calculation on
= =0A> >> the
=0A> >>>> Session
=0A> >>= ;>>> ID field in the L2TPv3 header or the Key field in the GRE hea= der as
=0A> >>>> defined in
=0A> >>>>&g= t; [RFC 5640] is not widely supported by existing core routers so far.
= =0A> >>>>>
=0A> >>>>> FWIW, I have h= ad success, in the relatively recent past, in
=0A> >>>> r= equesting a core
=0A> >>>>> router vendor to support c= hanges to the input-keys used in hash
=0A> >>>> calculati= ons in
=0A> >>>>> _existing_ hardware, already deploye= d (extensively) throughout my
=0A> >>>> network.
=0A&g= t; >>>>> Further, I suspect that most large network operator= s are savvy
=0A> >> folks
=0A> >>>> and
= =0A> >>>>> understand the internal architecture of their = HW fairly well.  As a
=0A> >>>> result, those
=0A= > >>>>> same operators know what is and is not technicall= y possible in this
=0A> >>>> regard.
=0A> >>&= gt;>> Thus, it may be a question of "methods" necessary to convince t= heir
=0A> >>>> HW
=0A> >>>>> supplie= r(s) to make appropriate changes in their equipment to
=0A> >> = achieve
=0A> >>>> their
=0A> >>>>> b= usiness goals.  :-)  However, this may not even be necessary ...<= br>=0A> >> see
=0A> >>>> below.
=0A> >&= gt;>>
=0A> >>>> Could you please briefly explain ho= w to make the above change in
=0A> >>>> EXISTING hardware= of already deployed core routers?
=0A> >>>>
=0A> &= gt;>>>>> In contrast, most existing core routers are already= capable of
=0A> >>>> balancing IP
=0A> >>>= ;>> traffic flows based on the hash of the five-tuple of UDP packets.=
=0A> >> By
=0A> >>>> using the
=0A> &g= t;>>>> MPLS-in-UDP encapsulation, the already available load-ba= lancing
=0A> >>>> capability of
=0A> >>>&g= t;> most existing core routers can be leveraged without requiring any=0A> >>>> change to
=0A> >>>>> them. T= hat is the major motivation of this draft.
=0A> >>>>><= br>=0A> >>>>> If this is a concern, then why not encapsul= ate the traffic in
=0A> >>>> MPLS/L2TPv3, which
=0A>= ; >>>>> uses UDP/IP, in the first place?
=0A> >>= >>
=0A> >>>> If I understand it correctly, you pref= er to use MPLS-in-L2TPv3-in-
=0A> >> UDP
=0A> >>>= ;> instead of MPLS-in-UDP, right?
=0A> >>>>
=0A>= >>>>> IMHO, a better proposal may be to consider a [minor] = (?) change to
=0A> >>>> RFC 3931,
=0A> >>>= >> which would allow the connection used for data packets (not contro= l
=0A> >>>> packets)
=0A> >>>>> to u= se a varying set of source ports (or, source IP addresses),
=0A> >= > based
=0A> >>>> on a hash
=0A> >>>>= ;> calculation, to achieve better load-balancing over existing
=0A>= ; >> equipment
=0A> >>>> in an
=0A> >>&= gt;>> IP-only core.  L2TP end-system implementations would be be= tter off
=0A> >>>> just using
=0A> >>>>= > the "Session ID" (and "Cookie") fields as the demultiplexor to
=0A&= gt; >>>> associate
=0A> >>>>> incoming pac= kets with the associated L2TP Control Channel.  In fact,
=0A> &g= t;>>> it's not
=0A> >>>>> clear to me that ex= isting implementations may /already/ do this,
=0A> >>>> m= aking any
=0A> >>>>> "check" on the incoming source po= rt unnecessary for L2TP end-system
=0A> >>>>> implemen= tations.
=0A> >>>>>
=0A> >>>>> Th= e beauty of the above approach is:
=0A> >>>>> 1) I wou= ld think that the above is most likely a change that is
=0A> >>= >> limited to the
=0A> >>>>> "control channel" (= software) of existing L2TP end-system
=0A> >>>> implement= ations.
=0A> >>>>> Heck, it may even be backwards comp= atible with existing L2TPv3
=0A> >>>>> implementations= .  (L2TPv3 implementors would need to comment on
=0A> >> t= hat).
=0A> >>>>
=0A> >>>> IMHO, no matt= er MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,  the hardware
=0A> >= > of
=0A> >>>> PE routers needs to be upgraded, e.g., = ingress PE routers need to
=0A> >> fill
=0A> >>>= > in an entropy value in the source port field of UDP headers.
=0A>= ; >>>>
=0A> >>>>> 2) There is a substantia= l added security one gets by using "Session
=0A> >>>> ID"= and
=0A> >>>>> "Cookie" fields to ensure the received= L2TPv3 packet is intended
=0A> >> for
=0A> >>>&= gt; the
=0A> >>>>> identified session.  Quoting f= rom Section 8.2 of RFC 3931:
=0A> >>>>> ---snip---
= =0A> >>>>>  L2TPv3 provides traffic separation for i= ts VPNs via a 32-bit
=0A> >>>> Session
=0A> >>= ;>>>  ID in the L2TPv3 data header.  When present, the L= 2TPv3 Cookie
=0A> >>>>>  (described in Section 4.= 1), provides an additional check to
=0A> >> ensure
=0A> &= gt;>>>>  that an arriving packet is intended for the ident= ified session.
=0A> >>>>>  Thus, use of a Cookie = with the Session ID provides an extra
=0A> >>>> guarantee=
=0A> >>>>>  that the Session ID lookup was perfo= rmed properly and that the
=0A> >>>>>  Session ID= itself was not corrupted in transit.
=0A> >>>>> ---sn= ip---
=0A> >>>>> ... in regard to this question alone,= I know the Security Area
=0A> >> folks
=0A> >>>= > have, in the
=0A> >>>>> past, had /substantial/ c= oncerns about encapsulation of MPLS over
=0A> >> IP
=0A> = >>>> transport.
=0A> >>>>> In fact, this i= s why you see text in Section 7.6, "Security", of
=0A> >> RFC=0A> >>>> 4665.
=0A> >>>>> (There's l= ikely similar language in other drafts that use MPLS for
=0A> >>= ;>> transport).
=0A> >>>>> While I'm not sure th= at Security Area folks pay much attention to
=0A> >>>> da= ily traffic on
=0A> >>>>> the MPLS WG mailing list, I'= m fairly confident this concern will
=0A> >>>> arise if/w= hen this
=0A> >>>>> draft goes to the IESG ...
=0A&= gt; >>>>
=0A> >>>> If I understand it correct= ly, the reason for your preference of
=0A> >> MPLS-
=0A> = >>>> in-L2TPv3-in-UDP is that it has an added security feature.= If that
=0A> >> is
=0A> >>>> so concerned, c= an you explain why MPLS-in-GRE is far more popular
=0A> >> than=
=0A> >>>> MPLS-in-L2TP in practice?
=0A> >>&= gt;>
=0A> >>>> Best regards,
=0A> >>>&g= t; Xiaohu
=0A> >>>>
=0A> >>>>> 3) Fi= nally, this approach only affects the end-systems that
=0A> >> = implement
=0A> >>>> L2TP, for
=0A> >>>>= > tunneling of MPLS/IP, and does not require an entire industry to
= =0A> >>>> support
=0A> >>>>> MPLS/UDP e= ncapsulation in their product lines.
=0A> >>>>>
=0A= > >>>>> -shane
=0A> >>>>>
=0A>= >>>>>
=0A> >>>>>>
=0A> >&g= t;>>>> Best regards,
=0A> >>>>>> Xiaohu=
=0A> >>>>>>
=0A> >>>>>>>= ; If there was market demand for MPLS over IP, then clearly it
=0A> &= gt;> would
=0A> >>>> have
=0A> >>>>&= gt; been
=0A> >>>>>>> more widely implemented by= equipment vendors, with either MPLS
=0A> >>>> over
= =0A> >>>>> GRE or
=0A> >>>>>>>= MPLS over L2TPv3.  (Where there's a will, there's a way).  I
= =0A> >> would
=0A> >>>> note
=0A> >>= >>> that
=0A> >>>>>>> the most likely r= easons this did not pan out was there are
=0A> >> several,
= =0A> >>>> practical
=0A> >>>>>>> = operational benefits one gets from going with native MPLS
=0A> >&g= t;>>>>> encapsulation/switching within the data plane, namel= y:
=0A> >>>>>>> - MPLS Fast Re-Route
=0A> = >>>>>>> - MPLS Traffic Engineering
=0A> >>= >>>>> ... to name, but a few.  Those have tended to be = quite compelling
=0A> >>>>> arguments
=0A> >&= gt;>>>>> to 'upgrade' network HW to support MPLS encapsulati= on/switching.
=0A> >>>>>>>
=0A> >>&g= t;>>>> -shane
=0A> >>>>>>>
=0A>= ; >>>>>>>
=0A> >>>>>>>> = -Josh
=0A> >>>>>>>>
=0A> >>>&g= t;>>>>
=0A> >>>>>>>> On 12/18/12 = 12:31 AM, "Shahram Davari" <davari= @broadcom.com>
=0A> >>>>> wrote:
=0A> >= ;>>>>>>>
=0A> >>>>>>>>&g= t; For service provider domain, MPLS over IP is legacy and there
=0A>= >> is
=0A> >>>> no need
=0A> >>>>= ;>>>>> to improve it.
=0A> >>>>>>>= ;>>
=0A> >>>>>>>>> Regards,
=0A&g= t; >>>>>>>>> Shahram
=0A> >>>>= >>>>>
=0A> >>>>>>>>>
=0A= > >>>>>>>>> On Dec 17, 2012, at 8:02 PM, "Xux= iaohu" <xuxiaohu@huawei.com>= ;
=0A> >>>>> wrote:
=0A> >>>>>>= ;>>>
=0A> >>>>>>>>>> Shahram,<= br>=0A> >>>>>>>>>>
=0A> >>>= >>>>>>> This draft is ONLY intended to provide a MPLS-= over-IP
=0A> >>>> encapsulation
=0A> >>>&g= t;>>>>>> method with a better load-balancing applicabilit= y so far to
=0A> >>>> those
=0A> >>>>&g= t;>>>>> operators who happen to require transporting MPLS ap= plication
=0A> >>>> traffic
=0A> >>>>&g= t;>>>>> across IP networks. I believe MPLS-based VPN over IP= , NVGRE
=0A> >> and
=0A> >>>>> VXLAN
= =0A> >>>>>>>>>> each have their own advoca= tors and use cases. If you
=0A> >> absolutely
=0A> >&g= t;>> believe
=0A> >>>>>>>>>> it's= meaningless of transporting MPLS application traffic
=0A> >>&g= t;> across IP
=0A> >>>>>>>>>> networ= ks and therefore those existing RFCs related to MPLS
=0A> >> ov= er
=0A> >>>> IP
=0A> >>>>>>>&g= t;>> tunneling mechanisms should be moved to Historic status,
=0A&= gt; >> please
=0A> >>>> say
=0A> >>>= >> so.
=0A> >>>>>>>>>>
=0A>= >>>>>>>>>> By the way, it seems this
=0A&= gt; >>>>>>>>>> (http://www.ietf.org/mail-=0A
=0A> >>>> archive/web/nvo3/current/msg01864.html) is=0A> >>>>>>>>>> just the right thread sui= table for you to make the following
=0A> >>>> argument=0A> >>>>>>>>>> (i.e., whether or not MPL= S-based VPN is applicable to data
=0A> >>>> centers). I=0A> >>>>>>>>>> had thought you would sp= eak up at that time. Sadly,
=0A> >>>> surprisingly silent=
=0A> >>>>>>>>>> till now.
=0A> &= gt;>>>>>>>>>
=0A> >>>>>>= >>>> Sigh, I didn't intend to say the above otherwise.
=0A&g= t; >>>>>>>>>>
=0A> >>>>>= >>>>> Xiaohu
=0A> >>>>>>>>>= >
=0A> >>>>>>>>>>> -----=E9=82=AE=E4= =BB=B6=E5=8E=9F=E4=BB=B6-----
=0A>= ; >>>>>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA:=0Ampls-bounces@ietf.org [mailto:mpls-bounces@ietf.org]
=0A> >> =E4=BB=A3
=0A> >>>> =E8=A1=A8
=0A> >>>>>>> S.
=0A> >>>= >>>>>>>> Davari
=0A> >>>>>>= >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2012=E5=B9=B412=E6=9C=8815=E6=97=A5=0A 13:= 34
=0A> >>>>>>>>>>> =E6=94=B6=E4=BB=B6=E4= =BA=BA: Loa Andersson
=0A> >&g= t;>>>>>>>>> =E6=8A=84=E9=80=81:=0Adraft-xu-mpls-in-udp@tools.ietf.org;=0Ampls@ietf.org;
=0A> >>>>>>>>>>= ;> mpls-chairs@tools= .ietf.org
=0A> >>>>>>>>>>> =E4=B8=BB= =E9=A2=98: Re: [mpls] poll to see if we= have support to make
=0A> >>>>>>>>>>&g= t; draft-xu-mpls-in-udp an
=0A> >>>>>>>>>&= gt;> mpls working group document
=0A> >>>>>>>= >>>>
=0A> >>>>>>>>>>> I = don't support this draft since it has no application in
=0A> >>= >> today's
=0A> >>>>>>>>>>> mo= dern metro
=0A> >>>>>>>>>>> and core= , where MPLS is dominant, and its only practical
=0A> >>>>= ; application
=0A> >>>>>>>>>>> in in= data
=0A> >>>>>>>>>>> center, which= already is crowded with other solutions such as
=0A> >>>>= ; NVGRE
=0A> >>>>> and
=0A> >>>>>= >>>>>> VXLAN.
=0A> >>>>>>>>= >>>
=0A> >>>>>>>>>>> It see= ms the authors are trying to bypass the NVO3 solution
=0A> >>&g= t;> selection
=0A> >>>>>>>>>>> pr= ocess
=0A> >>>>>>>>>>> by advancing = the draft in MPLS WG.
=0A> >>>>>>>>>>&g= t;
=0A> >>>>>>>>>>> Regards,
=0A&= gt; >>>>>>>>>>> Shahram
=0A> >>= ;>>>>>>>>>
=0A> >>>>>>&g= t;>>>>
=0A> >>>>>>>>>>> = On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu= > wrote:
=0A> >>>>>>>>>>>
= =0A> >>>>>>>>>>>> Working group,
= =0A> >>>>>>>>>>>>
=0A> >>= ;>>>>>>>>>> This is to start a "two week" pol= l on adopting
=0A> >>>>>>>>>>>> d= raft-xu-mpls-in-udp-06 as an MPLS working group document.
=0A> >&g= t;>>>>>>>>>> Due to the holiday season this p= oll has been extended with
=0A> >>>> one week.
=0A>= >>>>>>>>>>>>
=0A> >>>&g= t;>>>>>>>> Please send your comments (support/not s= upport) to the mpls
=0A> >>>>> working
=0A> >= >>>>>>>>>>> group mailing list (mpls at ie= tf.org). Please give an
=0A> >>>> technical
=0A> &g= t;>>>>>>>>>>> motivation for your support/= not support, especially if you
=0A> >>>> think that
= =0A> >>>>>>>>>>>> the document shoul= d not be adopted as a working group
=0A> >>>> document.=0A> >>>>>>>>>>>>
=0A> >&= gt;>>>>>>>>>> This poll ends January 07, 2013= .
=0A> >>>>>>>>>>>>
=0A> &g= t;>>>>>>>>>>> There is one IPR claim again= st this document -
=0A> >>>>>>>>>>>&= gt; https://datatracker.ietf.org/ipr/1941/ .
=0A> >= >>>>>>>>>>>
=0A> >>>>>= ;>>>>>>> All the active co-authors has stated on the w= orking group
=0A> >>>> mailing list
=0A> >>&g= t;>>>>>>>>> that they are not aware of any other= IPR claims than those
=0A> >>>> already
=0A> >&= gt;>>>>>>>>>> disclosed.
=0A> >>&= gt;>>>>>>>>>
=0A> >>>>>>= >>>>>> However, up to version -03 (the document that we u= sed for
=0A> >> the
=0A> >>>> IPR
=0A> = >>>>>>>>>>>> poll)
=0A> >>&= gt;>>>>>>>>> Marshall Eubanks was listed as one = of the authors. Marshall
=0A> >>>> has
=0A> >>= ;>>>>>>>>>> discontinued all interactions wit= h the IETF, including the
=0A> >>>> author team
=0A>= ; >>>>>>>>>>>> of draft-xu-mpls-in-udp-= 06. The working group chairs has
=0A> >>>> tried to
= =0A> >>>>>>>>>>>> contact Marshall b= y other means, to try get a response on
=0A> >> the
=0A> = >>>> IPR
=0A> >>>>>>>>>>>= ;> poll.
=0A> >>>>>>>>>>>> We = have had no success in this.
=0A> >>>>>>>>>= ;>>>
=0A> >>>>>>>>>>>> F= rom version -04 the authors decided to remove Marshall as a
=0A> >= >>>>>>>>>>> co-author.
=0A> >>= >>>>>>>>>>
=0A> >>>>>>= ;>>>>>> /Loa
=0A> >>>>>>>>&= gt;>>> (mpls wg co-chair)
=0A> >>>>>>>&= gt;>>>> --
=0A> >>>>>>>>>>&= gt;>
=0A> >>>>>>>>>>>>
=0A&= gt; >>>>>>>>>>>> Loa Andersson  &n= bsp;                     = email:
=0A> >>>>>>>>>>> loa.andersson@ericsson.com
= =0A> >>>>>>>>>>>> Sr Strategy and St= andards Manager            = =0Aloa@pi.nu
=0A> >>>>>>>>>>>>= ; Ericsson Inc                 = ;         phone: +46 10 717
=0A> 52
=0A> &g= t;> 13
=0A> >>>>>>>>>>>> =                     &nbs= p;                 +46 767 72 92=0A> 13
=0A> >>>>>>>>>>>> ___= ____________________________________________
=0A> >>>>>= ;>>>>>>> mpls mailing list
=0A> >>>>= >>>>>>>> mpls@ietf.org
=0A> >>>>>>>>>>>> =0Ahttps://www.ietf.org/mailman/listinfo/mpls
=0A> >>>= ;>>>>>>>> _________________________________________= ______
=0A> >>>>>>>>>>> mpls mailing= list
=0A> >>>>>>>>>>> mpls@ietf.org
=0A> >>>>>>>>&= gt;>> =0Ahttps://www.ietf.org/mailman/listinfo/mpls
=0A> >>>>>>>>>> ____________________= ___________________________
=0A> >>>>>>>>>= > mpls mailing list
=0A> >>>>>>>>>> = mpls@ietf.org
=0A> >>>>>= >>>>> =0Ahttps://www.ietf.org/mailman/listinf= o/mpls
=0A> >>>>>>>>> _______________= ________________________________
=0A> >>>>>>>>= ;> mpls mailing list
=0A> >>>>>>>>> mpls@ietf.org
=0A> >>>>>>= ;>>> =0Ahttps://www.ietf.org/mailman/listinfo/mpls =
=0A> >>>>>>>>
=0A> >>>>= ;>>>>
=0A> >>>>>>>> This E-mail a= nd any of its attachments may contain Time Warner
=0A> >>>&g= t; Cable
=0A> >>>>>>> proprietary information, w= hich is privileged, confidential, or
=0A> >>>> subject to=
=0A> >>>>>>> copyright belonging to Time Warner= Cable. This E-mail is intended
=0A> >>>> solely for
= =0A> >>>>> the
=0A> >>>>>>> us= e of the individual or entity to which it is addressed. If you
=0A> &= gt;>>> are not the
=0A> >>>>>>> intende= d recipient of this E-mail, you are hereby notified that
=0A> >>= ;>> any
=0A> >>>>> dissemination,
=0A> >= ;>>>>>> distribution, copying, or action taken in relatio= n to the
=0A> >> contents
=0A> >>>> of and=0A> >>>>>>> attachments to this E-mail is strictl= y prohibited and may be
=0A> >>>> unlawful. If you
=0A= > >>>>>>> have received this E-mail in error, pleas= e notify the sender
=0A> >>>> immediately and
=0A> = >>>>>>> permanently delete the original and any copy o= f this E-mail and
=0A> >>>> any printout.
=0A> >= >>>>>>> ______________________________________________= _
=0A> >>>>>>>> mpls mailing list
=0A> = >>>>>>>> mpls@ietf.org
=0A> >>>>>>>> https://www.ie= tf.org/mailman/listinfo/mpls=0A
=0A> >>>
=0A> >= >> _______________________________________________
=0A> >>= ;> mpls mailing list
=0A> >>> m= pls@ietf.org
=0A> >>> https://www.ietf.or= g/mailman/listinfo/mpls=0A
=0A> _________________________________= ______________
=0A> mpls mailing list
=0A> mpls@ietf.org
=0A> https://www.ietf.org/mail= man/listinfo/mpls=0A
=0A____________________________________________= ___
=0Ampls mailing list
=0Ampls@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/mpls
= =0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=0A=0A
<= br>
--275539708-1985452995-1356129621=:73091-- From lizhenbin@huawei.com Fri Dec 21 19:46:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A221E8037 for ; Fri, 21 Dec 2012 19:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=2.423, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw+NwYySPtlG for ; Fri, 21 Dec 2012 19:46:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8C21E8030 for ; Fri, 21 Dec 2012 19:46:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMS59568; Sat, 22 Dec 2012 03:46:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Dec 2012 03:46:15 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Dec 2012 03:46:10 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 22 Dec 2012 11:46:05 +0800 From: Lizhenbin To: Loa Andersson , "mpls@ietf.org" , "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN2dmWhDY9PQskSECmNT358Ih6CZgkOaRQ Date: Sat, 22 Dec 2012 03:46:04 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D077BE31B@szxeml525-mbs.china.huawei.com> References: <50CAEAD4.6000705@pi.nu> In-Reply-To: <50CAEAD4.6000705@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.196] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:46:31 -0000 U3VwcG9ydCBhcyBhIGNvLWF1dGhvcg0KDQpaaGVuYmluDQoNCg0KDQotLS0tLdPKvP7Urbz+LS0t LS0NCreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIExvYSBBbmRlcnNzb24NCreiy83KsbzkOiAyMDEyxOoxMtTCMTTI1SAxNzow MQ0KytW8/sjLOiBtcGxzQGlldGYub3JnOyBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1hcnRpbiBWaWdvdXJldXgNCtb3zOI6 IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1t cGxzLWluLXVkcCBhbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCg0KV29ya2luZyBncm91 cCwNCg0KVGhpcyBpcyB0byBzdGFydCBhICJ0d28gd2VlayIgcG9sbCBvbiBhZG9wdGluZw0KZHJh ZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K RHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0 aCBvbmUgd2Vlay4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3Vw cG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZw0KZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzIGF0IGll dGYub3JnKS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQptb3RpdmF0aW9uIGZvciB5b3VyIHN1 cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRoaW5rIHRoYXQNCnRoZSBkb2N1 bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K DQpUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KDQpUaGVyZSBpcyBvbmUgSVBSIGNs YWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2lwci8xOTQxLyAuDQoNCkFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0 aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCnRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9m IGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UgYWxyZWFkeQ0KZGlzY2xvc2VkLg0KDQpI b3dldmVyLCB1cCB0byB2ZXJzaW9uIC0wMyAodGhlIGRvY3VtZW50IHRoYXQgd2UgdXNlZCBmb3Ig dGhlIElQUiBwb2xsKQ0KTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUg YXV0aG9ycy4gTWFyc2hhbGwgaGFzDQpkaXNjb250aW51ZWQgYWxsIGludGVyYWN0aW9ucyB3aXRo IHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlIGF1dGhvciB0ZWFtDQpvZiBkcmFmdC14dS1tcGxzLWlu LXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcyB0cmllZCB0bw0KY29udGFjdCBN YXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFIg cG9sbC4NCldlIGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy4NCg0KIEZyb20gdmVyc2lvbiAt MDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYSBjby1hdXRob3Iu DQoNCi9Mb2ENCihtcGxzIHdnIGNvLWNoYWlyKQ0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20NClNy IFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udQ0KRXJp Y3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNyA1MiAx Mw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3Njcg NzIgOTIgMTMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From lizho.jin@gmail.com Sat Dec 22 18:45:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA721F8A92 for ; Sat, 22 Dec 2012 18:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfBtxSbL94AX for ; Sat, 22 Dec 2012 18:44:58 -0800 (PST) Received: from mail-ia0-f181.google.com (mail-ia0-f181.google.com [209.85.210.181]) by ietfa.amsl.com (Postfix) with ESMTP id BE8EA21F8A8C for ; Sat, 22 Dec 2012 18:44:57 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id s32so5012285iak.40 for ; Sat, 22 Dec 2012 18:44:57 -0800 (PST) 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=qFxust3XaQo1ZWKCD5uxky0Zp4HA3mNmWIzBJhOUQdo=; b=RfZf+vOG1NApAdFNELcXElV1OV+iS1pX8UuUKoEjStb3CAifdhms+ZkOkBQCBlKFVK jL5SKmZykwmzOVUlR8a9paIPATvTnoc6aIlLH9P/pEgA9WYu9uBcp14/YtKid14k+g5x fnw5BPsFe5NM0Z2QPbog3EDSpof3zPplHBJLQn8UE/eOVH7sm9cFnmgLAXF6O9g+rYxy Cqb+02WlMc+1DvxYZg4WlDU3wWmVopJDIi0nnyGQ5EQ0iVUXTj/BbVXPWcZTAIVhm0W3 hK0BtGzPJXICu8I0+MClGmZUV7XA0iKm4uaCNFF1+ghCt39cvHbSYyu5AQfYqYFaNuaf GfuA== MIME-Version: 1.0 Received: by 10.50.6.169 with SMTP id c9mr17393277iga.24.1356230697338; Sat, 22 Dec 2012 18:44:57 -0800 (PST) Received: by 10.50.70.106 with HTTP; Sat, 22 Dec 2012 18:44:57 -0800 (PST) Date: Sun, 23 Dec 2012 10:44:57 +0800 Message-ID: From: Lizhong Jin To: Pat Thaler , mpls@ietf.org Content-Type: multipart/alternative; boundary=e89a8f646717f2c76a04d17c10e5 Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 02:45:00 -0000 --e89a8f646717f2c76a04d17c10e5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I think everyone in this thread is very clear that the solution in this draft is to target NVO3 scenario. It's meaningless to mix it again and again with the service provider's network scenario. Agree with Pat, and it is premature to introduce NVO3 solution at this time, and it is also not the correct process to bypass NVO3 to do this solution. BTW, MPLS over UDP is already introduced in PWE3 by using MPLS over L2TP, and I do not see widely deployment in the service provider's network. Regards Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Dec 2012 20:49:29 +0000 > From: "Pat Thaler" > To: "Lucy yong" , "Andrew G. Malis" > , "Shane Amante" > Cc: "draft-xu-mpls-in-udp@tools.ietf.org" > , "mpls@ietf.org" > , "mpls-chairs@tools.ietf.org" > > Subject: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an mpls working group document > Message-ID: > < > EB9B93801780FD4CA165E0FBCB3C3E671DF206D1@SJEXCHMB09.corp.ad.broadcom.com> > > Content-Type: text/plain; charset="gb2312" > > Lucy, > > If your draft is intended to address the NVO3 requirements, then it should > be considered in NVO3 along with the other proposed solutions rather than > bypassing that process by submitting it to MPLS. > > The NVO charter requires that the preliminary analysis work be completed > before completing solutions: > The NVO3 WG will write the following informational RFCs, which > must have completed Working Group Last Call before rechartering can be > considered: > > Problem Statement > Framework document > Control plane requirements document > Data plane requirements document > Operational Requirements > Gap Analysis > > Driven by the requirements and consistent with the gap analysis, > the NVO3 WG may request being rechartered to document solutions > consisting of one or more data plane encapsulations and > control plane protocols as applicable. > > Based on the NVO3 charter, it is premature to consider solutions at this > point and suggesting that something should go forward because it supports > one item in a draft NVO3 requirements document is not justified. > > Regards, > Pat > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Lucy yong > Sent: Friday, December 21, 2012 11:27 AM > To: Andrew G. Malis; Shane Amante > Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an mpls working group document > > Andy, > > Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt > > 3.3.2.1. LAG and ECMP > > For performance reasons, multipath over LAG and ECMP paths SHOULD be > supported. > > LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal > Cost Multi Path) are commonly used techniques to perform load- > balancing of microflows over a set of a parallel links either at > Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware > implementations of LAG and ECMP uses a hash of various fields in the > encapsulation (outermost) header(s) (e.g. source and destination > MAC > addresses for non-IP traffic, source and destination IP addresses, > L4 protocol, L4 source and destination port numbers, etc). > Furthermore, hardware deployed for the underlay network(s) will be > most often unaware of the carried, innermost L2 frames or L3 packets > transmitted by the TS. Thus, in order to perform fine-grained load- > balancing over LAG and ECMP paths in the underlying network, the > encapsulation MUST result in sufficient entropy to exercise all > paths through several LAG/ECMP hops. The entropy information MAY be > inferred from the NVO3 overlay header or underlay header. > > Our draft provides an advanced solution in this space. > > Lucy > > From: mpls-bounces@ietf.org [mailto: > mpls-bounces@ietf.org] On Behalf > Of Andrew G. Malis > Sent: Friday, December 21, 2012 12:32 PM > To: Shane Amante > Cc: draft-xu-mpls-in-udp@tools.ietf.org draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org; > mpls-chairs@tools.ietf.org > Subject: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an mpls working group document > > I've commented earlier on this draft, and like Shane, I remain unconvinced > of its utility. I still don't think it has any utility at all for core > backbone networks - just use native MPLS, or if you must tunnel MPLS over > IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I > guess I could be convinced, but I would like to see a clear justification > in the form of requirements from nvo3 that could only be met by this draft. > > Thanks, > Andy > > On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante > wrote: > Xiaohu, > > On Dec 18, 2012, at 11:50 PM, Xuxiaohu xuxiaohu@huawei.com>> wrote: > -----????----- > >> ???: Shane Amante [mailto:shane@castlepoint.net shane@castlepoint.net>] > >> ????: 2012?12?19? 11:58 > >> ???: Rogers, Josh > >> ??: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org > ; > >> mpls@ietf.org; mpls-chairs@tools.ietf.org mpls-chairs@tools.ietf.org> > >> ??: Re: [mpls] poll to see if we have support to make > draft-xu-mpls-in-udp an > >> mpls working group document > >> > >> > >> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" > > >> wrote: > >>> I share your SP perspective, and do not see the problem this solution > >>> addresses in practice any longer. > >> > >> +1. Please do not define yet another MPLS-over-IP encapsulation. The > IETF > >> already standardized MPLS over GRE. The IETF has also standardized MPLS > >> over L2TPv3/UDP/IP, which had seen some deployment in at least one, very > >> large operator network that I'm aware of to support carriage of L3VPN > over an > >> IP-only network. > > > > Hi Shane, > > > > Thank you for telling us there are actual deployments of MPLS over IP in > at least one, very large operator network. This fact must be very valuable > to those people who had believed there is no application of MPLS over IP in > today's SP networks. > > > >> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 > >> [NOTE: the dates the above were published was back in the 2006 > timeframe!] > >> RFC 4665 for requirements related to VPLS that say that VPLS may be > >> carried over L2TPv3 > >> And, here's evidence showing that at least one vendor has > implemented > >> IPVPN's over L2TPv3: > >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html > > > > Thanks again for sharing the above information. As mentioned in this > draft AND other drafts, the mechanism of performing hash calculation on the > Session ID field in the L2TPv3 header or the Key field in the GRE header as > defined in [RFC 5640] is not widely supported by existing core routers so > far. > FWIW, I have had success, in the relatively recent past, in requesting a > core router vendor to support changes to the input-keys used in hash > calculations in _existing_ hardware, already deployed (extensively) > throughout my network. Further, I suspect that most large network > operators are savvy folks and understand the internal architecture of their > HW fairly well. As a result, those same operators know what is and is not > technically possible in this regard. Thus, it may be a question of > "methods" necessary to convince their HW supplier(s) to make appropriate > changes in their equipment to achieve their business goals. :-) However, > this may not even be necessary ... see below. > > > > In contrast, most existing core routers are already capable of balancing > IP traffic flows based on the hash of the five-tuple of UDP packets. By > using the MPLS-in-UDP encapsulation, the already available load-balancing > capability of most existing core routers can be leveraged without requiring > any change to them. That is the major motivation of this draft. > If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, > which uses UDP/IP, in the first place? > > IMHO, a better proposal may be to consider a [minor] (?) change to RFC > 3931, which would allow the connection used for data packets (not control > packets) to use a varying set of source ports (or, source IP addresses), > based on a hash calculation, to achieve better load-balancing over existing > equipment in an IP-only core. L2TP end-system implementations would be > better off just using the "Session ID" (and "Cookie") fields as the > demultiplexor to associate incoming packets with the associated L2TP > Control Channel. In fact, it's not clear to me that existing > implementations may /already/ do this, making any "check" on the incoming > source port unnecessary for L2TP end-system implementations. > > The beauty of the above approach is: > 1) I would think that the above is most likely a change that is limited to > the "control channel" (software) of existing L2TP end-system > implementations. Heck, it may even be backwards compatible with existing > L2TPv3 implementations. (L2TPv3 implementors would need to comment on > that). > 2) There is a substantial added security one gets by using "Session ID" > and "Cookie" fields to ensure the received L2TPv3 packet is intended for > the identified session. Quoting from Section 8.2 of RFC 3931: > ---snip--- > L2TPv3 provides traffic separation for its VPNs via a 32-bit Session > ID in the L2TPv3 data header. When present, the L2TPv3 Cookie > (described in Section 4.1), provides an additional check to ensure > that an arriving packet is intended for the identified session. > Thus, use of a Cookie with the Session ID provides an extra guarantee > that the Session ID lookup was performed properly and that the > Session ID itself was not corrupted in transit. > ---snip--- > ... in regard to this question alone, I know the Security Area folks have, > in the past, had /substantial/ concerns about encapsulation of MPLS over IP > transport. In fact, this is why you see text in Section 7.6, "Security", > of RFC 4665. (There's likely similar language in other drafts that use > MPLS for transport). While I'm not sure that Security Area folks pay much > attention to daily traffic on the MPLS WG mailing list, I'm fairly > confident this concern will arise if/when this draft goes to the IESG ... > 3) Finally, this approach only affects the end-systems that implement > L2TP, for tunneling of MPLS/IP, and does not require an entire industry to > support MPLS/UDP encapsulation in their product lines. > > -shane > > > > > > Best regards, > > Xiaohu > > > >> If there was market demand for MPLS over IP, then clearly it would have > been > >> more widely implemented by equipment vendors, with either MPLS over GRE > or > >> MPLS over L2TPv3. (Where there's a will, there's a way). I would note > that > >> the most likely reasons this did not pan out was there are several, > practical > >> operational benefits one gets from going with native MPLS > >> encapsulation/switching within the data plane, namely: > >> - MPLS Fast Re-Route > >> - MPLS Traffic Engineering > >> ... to name, but a few. Those have tended to be quite compelling > arguments > >> to 'upgrade' network HW to support MPLS encapsulation/switching. > >> > >> -shane > >> > >> > >>> -Josh > >>> > >>> > >>> On 12/18/12 12:31 AM, "Shahram Davari" davari@broadcom.com>> wrote: > >>> > >>>> For service provider domain, MPLS over IP is legacy and there is no > need > >>>> to improve it. > >>>> > >>>> Regards, > >>>> Shahram > >>>> > >>>> > >>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" xuxiaohu@huawei.com>> wrote: > >>>> > >>>>> Shahram, > >>>>> > >>>>> This draft is ONLY intended to provide a MPLS-over-IP encapsulation > >>>>> method with a better load-balancing applicability so far to those > >>>>> operators who happen to require transporting MPLS application traffic > >>>>> across IP networks. I believe MPLS-based VPN over IP, NVGRE and VXLAN > >>>>> each have their own advocators and use cases. If you absolutely > believe > >>>>> it's meaningless of transporting MPLS application traffic across IP > >>>>> networks and therefore those existing RFCs related to MPLS over IP > >>>>> tunneling mechanisms should be moved to Historic status, please say > so. > >>>>> > >>>>> By the way, it seems this > >>>>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) is > >>>>> just the right thread suitable for you to make the following argument > >>>>> (i.e., whether or not MPLS-based VPN is applicable to data centers). > I > >>>>> had thought you would speak up at that time. Sadly, surprisingly > silent > >>>>> till now. > >>>>> > >>>>> Sigh, I didn't intend to say the above otherwise. > >>>>> > >>>>> Xiaohu > >>>>> > >>>>>> -----????----- > >>>>>> ???: mpls-bounces@ietf.org [mailto: > mpls-bounces@ietf.org] ?? > >> S. > >>>>>> Davari > >>>>>> ????: 2012?12?15? 13:34 > >>>>>> ???: Loa Andersson > >>>>>> ??: draft-xu-mpls-in-udp@tools.ietf.org draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org; > >>>>>> mpls-chairs@tools.ietf.org > >>>>>> ??: Re: [mpls] poll to see if we have support to make > >>>>>> draft-xu-mpls-in-udp an > >>>>>> mpls working group document > >>>>>> > >>>>>> I don't support this draft since it has no application in today's > >>>>>> modern metro > >>>>>> and core, where MPLS is dominant, and its only practical application > >>>>>> in in data > >>>>>> center, which already is crowded with other solutions such as NVGRE > and > >>>>>> VXLAN. > >>>>>> > >>>>>> It seems the authors are trying to bypass the NVO3 solution > selection > >>>>>> process > >>>>>> by advancing the draft in MPLS WG. > >>>>>> > >>>>>> Regards, > >>>>>> Shahram > >>>>>> > >>>>>> > >>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson loa@pi.nu>> wrote: > >>>>>> > >>>>>>> Working group, > >>>>>>> > >>>>>>> This is to start a "two week" poll on adopting > >>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working group document. > >>>>>>> Due to the holiday season this poll has been extended with one > week. > >>>>>>> > >>>>>>> Please send your comments (support/not support) to the mpls working > >>>>>>> group mailing list (mpls at ietf.org). Please > give an technical > >>>>>>> motivation for your support/not support, especially if you think > that > >>>>>>> the document should not be adopted as a working group document. > >>>>>>> > >>>>>>> This poll ends January 07, 2013. > >>>>>>> > >>>>>>> There is one IPR claim against this document - > >>>>>>> https://datatracker.ietf.org/ipr/1941/ . > >>>>>>> > >>>>>>> All the active co-authors has stated on the working group mailing > list > >>>>>>> that they are not aware of any other IPR claims than those already > >>>>>>> disclosed. > >>>>>>> > >>>>>>> However, up to version -03 (the document that we used for the IPR > >>>>>>> poll) > >>>>>>> Marshall Eubanks was listed as one of the authors. Marshall has > >>>>>>> discontinued all interactions with the IETF, including the author > team > >>>>>>> of draft-xu-mpls-in-udp-06. The working group chairs has tried to > >>>>>>> contact Marshall by other means, to try get a response on the IPR > >>>>>>> poll. > >>>>>>> We have had no success in this. > >>>>>>> > >>>>>>> From version -04 the authors decided to remove Marshall as a > >>>>>>> co-author. > >>>>>>> > >>>>>>> /Loa > >>>>>>> (mpls wg co-chair) > >>>>>>> -- > >>>>>>> > >>>>>>> > >>>>>>> Loa Andersson email: > >>>>>> loa.andersson@ericsson.com > >>>>>>> Sr Strategy and Standards Manager loa@pi.nu loa@pi.nu> > >>>>>>> Ericsson Inc phone: +46 10 717 52 13 > > >>>>>>> +46 767 72 92 13 > > >>>>>>> _______________________________________________ --e89a8f646717f2c76a04d17c10e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
I think everyone in this = thread is very clear that the solution in this draft is to target NVO3 scen= ario. It's meaningless to mix it again and again with the service provi= der's network scenario. Agree with Pat, and it is premature to introduc= e NVO3 solution at this time, and it is also not the correct process to byp= ass NVO3 to do this solution.
BTW, MPLS over UDP is already introduced in PWE3 by using MPLS over L2= TP, and I do not see widely deployment in the service provider's networ= k.

Regards
Lizhong
=A0

----------------------------------------------------------------------

Message: 1
Date: Fri, 21 Dec 2012 20:49:29 +0000
From: "Pat Thaler" <pt= haler@broadcom.com>
To: "Lucy yong" <lucy.= yong@huawei.com>, "Andrew G. Malis"
=A0 =A0 =A0 =A0 <agmalis@gmail.com<= /a>>, =A0 =A0"Shane Amante" <shane@castlepoint.net>
Cc: "draft-xu-m= pls-in-udp@tools.ietf.org"
=A0 =A0 =A0 =A0 <= draft-xu-mpls-in-udp@tools.ietf.org>, "mpls@ietf.org"
=A0 =A0 =A0 =A0 <mpls@ietf.org>,= =A0 =A0 =A0 =A0"mpls-ch= airs@tools.ietf.org"
=A0 =A0 =A0 =A0 <mpls-chai= rs@tools.ietf.org>
Subject: Re: [mpls] poll to see if we have support to make
=A0 =A0 =A0 =A0 draft-xu-mpls-in-udp an mpls working group document
Message-ID:
=A0 =A0 =A0 =A0 <EB9B93801780FD4CA165E0FBCB3C3E671DF206= D1@SJEXCHMB09.corp.ad.broadcom.com>

Content-Type: text/plain; charset=3D"gb2312"

Lucy,

If your draft is intended to address the NVO3 requirements, then it should = be considered in NVO3 along with the other proposed solutions rather than b= ypassing that process by submitting it to MPLS.

The NVO charter requires that the preliminary analysis work be completed be= fore completing solutions:
The NVO3 WG will write the following informational RFCs, which
must have completed Working Group Last Call before rechartering can be
considered:

Problem Statement
Framework document
Control plane requirements document
Data plane requirements document
Operational Requirements
Gap Analysis

Driven by the requirements and consistent with the gap analysis,
the NVO3 WG may request being rechartered to document solutions
consisting of one or more data plane encapsulations and
control plane protocols as applicable.

Based on the NVO3 charter, it is premature to consider solutions at this po= int and suggesting that something should go forward because it supports one= item in a draft NVO3 requirements document is not justified.

Regards,
Pat

From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Lucy yong
Sent: Friday, December 21, 2012 11:27 AM
To: Andrew G. Malis; Shane Amante
Cc: draft-xu-mpls-in= -udp@tools.ietf.org; mpls@ietf.org= ; mpls-chairs@tools.ietf.org<= /a>
Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in= -udp an mpls working group document

Andy,

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

=A0 3.3.2.1. LAG and ECMP

=A0 =A0 =A0 =A0For performance reasons, multipath over LAG and ECMP paths S= HOULD be
=A0 =A0 =A0 =A0supported.

=A0 =A0 =A0 =A0LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (E= qual
=A0 =A0 =A0 =A0Cost Multi Path) are commonly used techniques to perform loa= d-
=A0 =A0 =A0 =A0balancing of microflows over a set of a parallel links eithe= r at
=A0 =A0 =A0 =A0Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware<= br> =A0 =A0 =A0 =A0implementations of LAG and ECMP uses a hash of various field= s in the
=A0 =A0 =A0 =A0 encapsulation (outermost) header(s) (e.g. source and destin= ation MAC
=A0 =A0 =A0 =A0addresses for non-IP traffic, source and destination IP addr= esses,
=A0 =A0 =A0 =A0L4 protocol, L4 source and destination port numbers, etc). =A0 =A0 =A0 =A0Furthermore, hardware deployed for the underlay network(s) w= ill be
=A0 =A0 =A0 =A0most often unaware of the carried, innermost L2 frames or L3= packets
=A0 =A0 =A0 =A0transmitted by the TS. Thus, in order to perform fine-graine= d load-
=A0 =A0 =A0 =A0balancing over LAG and ECMP paths in the underlying network,= the
=A0 =A0 =A0 =A0encapsulation MUST result in sufficient entropy to exercise = all
=A0 =A0 =A0 =A0paths through several LAG/ECMP hops. The entropy information= MAY be
=A0 =A0 =A0 =A0inferred from the NVO3 overlay header or underlay header.
Our draft provides an advanced solution in this space.

Lucy

From: mpls-bounces@ietf.org<= ;mailto:mpls-bounces@ietf.org&= gt; [mailto:mpls-bounces@ietf.org<= /a>]<mailto:[mailto:mpls-bounce= s@ietf.org]> On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in= -udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; mpl= s-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in= -udp an mpls working group document

I've commented earlier on this draft, and like Shane, I remain unconvin= ced of its utility. I still don't think it has any utility at all for c= ore backbone networks - just use native MPLS, or if you must tunnel MPLS ov= er IP, the GRE or L2TPv3 encapsulations. Regarding data center applications= , I guess I could be convinced, but I would like to see a clear justificati= on in the form of requirements from nvo3 that could only be met by this dra= ft.

Thanks,
Andy

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.net<mailto:shane@castlepoint.net>> wrote:
Xiaohu,

On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote:
-----????-----
>> ???: Shane Amante [mailto:shane@castlepoint.net<mailto:shane@castlepoint.net>]
>> ????: 2012?12?19? 11:58
>> ???: Rogers, Josh
>> ??: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools= .ietf.org>;
>> mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
>> ??: Re: [mpls] poll to see if we have support to make draft-xu-mpl= s-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com<mailto:<= a href=3D"mailto:josh.rogers@twcable.com">josh.rogers@twcable.com>&g= t;
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1. =A0Please do not define yet another MPLS-over-IP encapsulation= . =A0The IETF
>> already standardized MPLS over GRE. =A0The IETF has also standardi= zed MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage o= f L3VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>> =A0 =A0 RFC 4665 for requirements related to VPLS that say that VP= LS may be
>> carried over L2TPv3
>> =A0 =A0 And, here's evidence showing that at least one vendor = has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s= /feature/guide/csgl3vpn.html
>
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so = far.
FWIW, I have had success, in the relatively recent past, in requesting a co= re router vendor to support changes to the input-keys used in hash calculat= ions in _existing_ hardware, already deployed (extensively) throughout my n= etwork. =A0Further, I suspect that most large network operators are savvy f= olks and understand the internal architecture of their HW fairly well. =A0A= s a result, those same operators know what is and is not technically possib= le in this regard. =A0Thus, it may be a question of "methods" nec= essary to convince their HW supplier(s) to make appropriate changes in thei= r equipment to achieve their business goals. =A0:-) =A0However, this may no= t even be necessary ... see below.


> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring = any change to them. That is the major motivation of this draft.
If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, = which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipm= ent in an IP-only core. =A0L2TP end-system implementations would be better = off just using the "Session ID" (and "Cookie") fields a= s the demultiplexor to associate incoming packets with the associated L2TP = Control Channel. =A0In fact, it's not clear to me that existing impleme= ntations may /already/ do this, making any "check" on the incomin= g source port unnecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations. =A0Heck, it may even be backwards compatible with existing L2T= Pv3 implementations. =A0(L2TPv3 implementors would need to comment on that)= .
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session. =A0Quoting from Section 8.2 of RFC 3= 931:
---snip---
=A0 =A0L2TPv3 provides traffic separation for its VPNs via a 32-bit Session=
=A0 =A0ID in the L2TPv3 data header. =A0When present, the L2TPv3 Cookie
=A0 =A0(described in Section 4.1), provides an additional check to ensure =A0 =A0that an arriving packet is intended for the identified session.
=A0 =A0Thus, use of a Cookie with the Session ID provides an extra guarante= e
=A0 =A0that the Session ID lookup was performed properly and that the
=A0 =A0Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport. =A0In fact, this is why you see text in Section 7.6, "Secu= rity", of RFC 4665. =A0(There's likely similar language in other d= rafts that use MPLS for transport). =A0While I'm not sure that Security= Area folks pay much attention to daily traffic on the MPLS WG mailing list= , I'm fairly confident this concern will arise if/when this draft goes = to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane


>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3. =A0(Where there's a will, there's a way)= . =A0I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few. =A0Those have tended to be quite compellin= g arguments
>> to 'upgrade' network HW to support MPLS encapsulation/swit= ching.
>>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com<mailto:davari@broadcom.com>> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application = traffic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.<= br> >>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----????-----
>>>>>> ???: mpls= -bounces@ietf.org<mailto:mp= ls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] ??
>> S.
>>>>>> Davari
>>>>>> ????: 2012?12?15? 13:34
>>>>>> ???: Loa Andersson
>>>>>> ??: draft-xu-mpls-in-udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools.ietf.org<= /a>>; mpls@ietf.org<mailto:mpls@ietf.org>;
>>>>>> mpls= -chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
>>>>>> ??: Re: [mpls] poll to see if we have support to m= ake
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no app= lication in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org<http://ietf.org>). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 email:
>>>>>> loa.= andersson@ericsson.com<mailto:loa.andersson@ericsson.com>
>>>>>>> Sr Strategy and Standards Manager =A0 =A0 =A0 = =A0 =A0 =A0loa@pi.nu<mailto:loa@pi.nu>
>>>>>>> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0phone: +46 10 717 52 13<tel:%2B46%2010%20717%2052%2013>= ;
>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+46 767 72 92 13<tel:%2B46%20767%2072%= 2092%2013>
>>>>>>> ______________________________________________= _
--e89a8f646717f2c76a04d17c10e5-- From loa@pi.nu Sun Dec 23 02:21:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBF521F859A for ; Sun, 23 Dec 2012 02:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_64=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyfLJeu3GLiJ for ; Sun, 23 Dec 2012 02:21:49 -0800 (PST) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0B21F86D9 for ; Sun, 23 Dec 2012 02:21:48 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id EA79E8244B; Sun, 23 Dec 2012 11:21:43 +0100 (CET) Message-ID: <50D6DB30.5070908@pi.nu> Date: Sun, 23 Dec 2012 11:21:36 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <50C88CD6.6020103@pi.nu> In-Reply-To: <50C88CD6.6020103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-ads@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] soliciting comments on response to liaison from SG15 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 10:21:49 -0000 Working Group, we sent this mail soliciting comments on the on the outgoing liaison text. There have been no comments on the list, but some directly to the working group chairs. We have updated the text and intend to send this version the day before the dead line. ------------- proposed liaison text ----------------------- Thank you for your liaison statement COM15-LS435-E "Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks" with the questions and concerns that it raises about RFC 6378 MPLS-TP linear protection. We have passed your concerns to the working group. We hope that anyone who agrees with them and is concerned to modify the MPLS-TP linear protection specification will write an Internet-Draft using the normal IETF process. We know that a number of people have been actively discussing the issues you raised with a view to making modifications to the specification presented in RFC 6378. Here are some additional notes for the specific points in your liaison. #1 RFC5654 includes R.83, which states "The external controls as defined in [RFC4427] MUST be supported." RFC4427 clearly requires FS > SF-P; please see the LS from the IETF to the ITU dated 2012-08-06. An alternate approach allowing SF-P > FS could be defined such that it can co-exist with FS > SF-P. #2 The scenario described in Annex 2 of your liaison describes a defect in RFC 6378. It makes no sense to continue to send SF(1,1) when W has not failed. #3 No requirement for EXER was documented in RFC5654. There is also no mention of EXER in RFCs 4427 an 6372. EXER could be added to the MPLS-TP function-set. #4 There is currently no definition of SD for an MPLS environment. SD is included in RFC6378 as a placeholder (see RFC6378 Section 3.1: "The determination and actions for SD are for further study and may appear in a separate document"). We encourage interested parties to submit an Internet-Draft for consideration by the IPPM and MPLS working groups. There is no requirement MS-W in RFC5654 or RFC4427. We encourage interested parties to submit an Internet-Draft for consideration by the MPLS working group. #5 You ask whether your understanding that Clear Signal Fail (SFc) is used to trigger the WTR in section 4.3.3.5 of RFC 6378. CSF should not be thought of as a trigger, but as the removal of a trigger. If a node has multiple alarms active, the removal (Clear) of the highest priority alarm causes a node to re-evaluate its current inputs and act accordingly. If a SF is Cleared and there are no other active inputs, the resulting transition into Normal will trigger WTR, per rfc6378 sec. 3.5. #6 RFC6378 is a protocol specification and does not describe how to implement error reporting to the operator. An error reporting paradigm could be defined. #7 Mechanisms for alerting operators about mismatches are outside of the scope of the protocol specification: they may be considered as issues for implementers. A default operational state for MPLS-TP linear protection in absence of any specific configuration could be defined. #8 The scenario described in Annex 3 of your liaison should be addressed in an Internet-Draft describing the problem and proposing a solution. #9 RFC5654 R.83 requires that the external commands in RFC4427 be implemented. RFC4427 defines 'Freeze' as "A configuration action.that prevents any switch-over action from being taken". This is a local behavior on a node (there is no signaled message as a result) and thus it is not part of the MPLS-TP linear protection protocol specification. RFC4427 defines "Manual switch-over for recovery LSP/span" as "A switch-over action, initiated externally, that switches normal traffic to the working LSP/span, unless a fault condition exists on the working LSP/span or an equal or higher priority switch-over command is in effect". This function is provided by the FS and MS messages in RFC6378. If there is a desire for a switchover behavior which differs from FS or MS then it should be documented in an Internet-Draft for consideration by the MPLS working group. Loa Andersson Ross Callon George Swallow mpls working group chairs ------------------- end liaison text --------------------- On 2012-12-12 14:55, Loa Andersson wrote: > Working Group, > > I sent this one time, but it came out "weird" - resending with another > subject line! > > We've had a small team that prepared a response to and incoming liaison > from ITU-T SG15 on linear protection; both the liaison and the proposed > response is included in this mail. In my opinion this team has done a > tremendous job in creating the proposed response. > > This mail is to start soliciting comments on the response. > > We need to send the response before the end of the year, but will have > meeting the 18th to check that everything is OK. Comments will be > useful whenever we get, all the way up to when the response is sent; but > they will particular if we get them before 10am (Boston time) on > December 18. > > Thanks to the team (Eric O, Scott M and Yaacov W) for all the work they > have put into this, thanks also to the support from our ADs, Adrian and > Stewart. > > /Loa > for the wg chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From xuxiaohu@huawei.com Sun Dec 23 18:31:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F321F878F for ; Sun, 23 Dec 2012 18:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.592 X-Spam-Level: X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=1.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vavljz5CF2Xv for ; Sun, 23 Dec 2012 18:31:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20621F85A4 for ; Sun, 23 Dec 2012 18:31:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOC56980; Mon, 24 Dec 2012 02:31:21 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 02:31:05 +0000 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 02:31:19 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.003; Mon, 24 Dec 2012 10:30:59 +0800 From: Xuxiaohu To: "S. Davari" , Lucy yong , Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sszh5eWXqDbZUC4MEZ17BejhpghW8uAgAAGHQCAAAntgIABD+5A///lsoCAAOaJAIAADKCAgAPjKKA= Date: Mon, 24 Dec 2012 02:30:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98A@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com> In-Reply-To: <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98Aszxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:31:31 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98Aszxeml525mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCuWPkeS7tuS6ujogUy4gRGF2YXJpIFttYWlsdG86ZGF2YXJpc2hAeWFob28uY29tXQ0K5Y+R 6YCB5pe26Ze0OiAyMDEy5bm0MTLmnIgyMuaXpSA2OjQwDQrmlLbku7bkuro6IEx1Y3kgeW9uZzsg WHV4aWFvaHU7IFNoYWhyYW0gRGF2YXJpDQrmioTpgIE6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRv b2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K 5Li76aKYOiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlp bmcgbmV0d29yaw0KDQpMdWN5LA0KDQpJIGNhbiBvbmx5IHNlZSBDaGluYSBUZWxlY29tIGFzIGNv LWF1dGhvciwgYW5kIHRoZSBBcHBsaWNhYmlsaXR5IHNlY3Rpb24gc2F5cyBMMlZQTiBhbmQgTDNW UE4uIFNvIGlzIENoaW5hIFRlbGVjb20gdXNpbmcgaXQgZm9yIHRoZWlyIEVudGVycHJpc2UgVlBO IHNlcnZpY2U/IGJ1dCB5b3VyIGVhcmxpZXIgZW1haWxzIHN1Z2dlc3RzIHRoYXQgdGhpcyBpcyBu b3QgdGhlIGludGVuZGVkIHVzYWdlIHJhdGhlciBpdCBpcyBmb3IgRGF0YSBDZW50ZXIuIFNvIHdo aWNoIG9uZSBpcyBpdD8gV2h5IGlzbid0IENoaW5hIFRlbGVjb20gc3BlYWtpbmcgb24gdGhlIGxp c3QgYW5kIGV4cGxhaW5pbmcgdGhlaXIgdXNhZ2UgbW9kZWw/DQoNCltYaWFvaHVdIFllcywgdGhl IEFwcGxpY2FiaWxpdHkgc2VjdGlvbiBzYXlzIEwyVlBOIGFuZCBMM1ZQTiwgYnV0IHRoZXJlIGlz IG5vIGxpbWl0IHRoYXQgdGhlc2UgdGVjaG5vbG9naWVzIGNvdWxkIG9ubHkgYmUgdXNlZCBieSBz ZXJ2aWNlIHByb3ZpZGVycz8gIEVudGVycHJpc2VzIHRoZW1zZWx2ZXMgY291bGQgYWRvcHQgdGhl c2UgdGVjaG5vbG9naWVzIHRvIGludGVyY29ubmVjdCB0aGVpciBtdWx0aXBsZSBzaXRlcyBhbmQg ZGF0YSBjZW50ZXIgb3BlcmF0b3JzIGNvdWxkIHVzZSB0aGVtIHdpdGhpbiBvciBldmVuIGFjcm9z cyBkYXRhIGNlbnRlcnMgYXMgd2VsbCBpZiB0aGV5IHdvdWxkIGxpa2UuIExldCBtZSBpdGVyYXRl IHRoYXQgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCBjYW4gYmUgdXNlZCBpbiBTUCBuZXR3b3Jrcywg ZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgZXZlbiBkYXRhIGNlbnRlcnMgYW5kIHRoZXJlZm9yZSBN UExTLWluLVVEUCBpcyBhcHBsaWNhYmxlIHRvIGFueSBvZiB0aGUgYWJvdmUgc2NlbmFyaW8gYXMg d2VsbC4NCg0KQWxzbyByZWdhcmRpbmcgTXVsdGljYXN0LCB0aGlzIG1lYW5zIHlvdSBuZWVkIHRv IG1hcCBNdWx0aWNhc3QgdHJhZmZpYyB0byBQMlAgUFcsIHdoaWNoIGlzIGluZmVyaW9yIHRvIG90 aGVyIG1ldGhvZHMgc3VjaCBhcyBOVkdSRSBhbmQgVlhMQU4gc2luY2UgdGhleSBuYXRpdmVseSBz dXBwb3J0IGVmZmljaWVudCBNdWx0aWNhc3QuDQoNCltYaWFvaHVdIEZpcnN0LCByZW1lbWJlciB0 aGF0IE1QTFMtaW4tVURQIGlzIG5vdCBvbmx5IHN1aXRhYmxlIGZvciBNUExTLWJhc2VkIEwyVlBO IGJ1dCBhbHNvIHN1aXRhYmxlIGZvciBMM1ZQTi4gU2Vjb25kLCBNUExTLWJhc2VkIFZQTiBjYW4g c3VwcG9ydCBib3RoIGluZ3Jlc3MgcmVwbGljYXRpb24gbW9kZSBhbmQgbXVsdGljYXN0IHRyZWUg bW9kZS4NCg0KVGhhbmtzLA0KU2hhaHJhbQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb20+DQpUbzogUy4g RGF2YXJpIDxkYXZhcmlzaEB5YWhvby5jb20+OyBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNv bT47IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJvYWRjb20uY29tPg0KQ2M6ICJkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyIgPGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmll dGYub3JnPjsgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPjsgIm1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnIiA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXks IERlY2VtYmVyIDIxLCAyMDEyIDE6NTU6MTAgUE0NClN1YmplY3Q6IFJFOiBbbXBsc10gTVBMUyBj bGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQoNCg0KU2hhaHJhbSwN Cg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IFMuIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNo QHlhaG9vLmNvbV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjEsIDIwMTIgMjoxMCBBTQ0KVG86 IFh1eGlhb2h1OyBTaGFocmFtIERhdmFyaTsgTHVjeSB5b25nDQpDYzogZHJhZnQteHUtbXBscy1p bi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQ IHVuZGVybHlpbmcgbmV0d29yaw0KDQpIaSwNCg0KSSB0aGluayB3ZSBhcmUgaW4gYSB2aWNpb3Vz IGN5Y2xlLiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggbmV0d29yayBvcGVyYXRvciBp cyBhc2tpbmcgZm9yIE1QTFMgb3ZlciBVRFAgYW5kIHdoYXQgaXMgdGhlIGFwcGxpY2F0aW9uLg0K W0x1Y3ldIGl0IGlzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuDQpBbHNvIGhvdyBkbyB5b3UgcGxh biB0byBhZGRyZXNzIHRoZSBNUExTIE11bHRpY2FzdCAod2hpY2ggaXMgcHJvYmFibHkgbW9yZSBp bXBvcnRhbnQgdGhhbiBpbXByb3ZpbmcgdGhlIGxvYWQgYmFsYW5jaW5nKSwgZ2l2ZW4gdGhhdCBS RkM0MDIzIGRvZXMgbm90IHN1cHBvcnQgTXVsdGljYXN0Lg0KW0x1Y3ldIE1QTFMgQ2xpZW50IExh eWVyIGlzIHJlc3BvbnNpYmxlIHRvIG1hcCBtdWx0aWNhc3QgdHJhZmZpYyB0byB1bmRlcmx5aW5n IHRyYW5zcG9ydCwgd2hpY2ggaXMgc3BlY2lmaWVkIGluIEVWUE4gYW5kIElQIFZQTi4gVGhpcyBw cm9wb3NhbCBqdXN0IHJlcXVlc3RzIGluZ3Jlc3MgUEUgdG8gZmlsbCB0aGUgZmxvdyBlbnRyb3B5 IGludG8gVURQIHNvdXJjZSBwb3J0LCBpbiB3aGljaCB0aGUgZmxvdyBjYW4gYmUgdW5pY2FzdCBv ciBtdWx0aWNhc3QuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpUaGFua3MsDQpTaGFocmFtDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFh1eGlhb2h1IDx4dXhp YW9odUBodWF3ZWkuY29tPg0KVG86IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlAYnJvYWRjb20uY29t PjsgTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4NCkNjOiAiZHJhZnQteHUtbXBscy1p bi11ZHBAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9y Zz47ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz47ICJtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZyIgPG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU2VudDogVGh1cnNkYXksIERl Y2VtYmVyIDIwLCAyMDEyIDU6NTY6MjMgUE0NClN1YmplY3Q6IFJlOiBbbXBsc10gTVBMUyBjbGll bnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQoNCg0KDQo+IC0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dIOS7o+ihqA0KPiBTaGFocmFtIERhdmFyaQ0KPiDl j5HpgIHml7bpl7Q6IDIwMTLlubQxMuaciDIx5pelIDE6MzENCj4g5pS25Lu25Lq6OiBMdWN5IHlv bmcNCj4g5oqE6YCBOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Ow0KPiBtcGxzQGlldGYu b3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiDkuLvpopg6IFJlOiBbbXBsc10gTVBMUyBjbGll bnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQo+DQo+IFBsZWFzZSBkb24n dCBtaXggdXAgdGhpbmdzLiBUaGUgTVBMUyBwcm90b2NvbCBkZXNpZ24gSSBhZ3JlZSBtdXN0IGJl IGRvbmUgYnkNCj4gTVBMUyBXRy4gQnV0IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdXIgcHJv cG9zYWwgbWVldHMgdGhlIG5ldHdvcmsNCj4gdmlydHVhbGl6YXRpb24gcmVxdWlyZW1lbnRzLg0K DQpDYW4geW91IHRlbGwgdXMgd2hlcmUgTVBMUy1pbi1HUkUvSVAgW1JGQzQwMjNdIGFuZCBvdGhl ciBNUExTIG92ZXIgSVAgZW5jYXBzdWxhdGlvbiBtZWNoYW5pc21zIGhhdmUgYmVlbiBkaXNjdXNz ZWQgYmVmb3JlPw0KDQpTaW5jZSBNUExTLWluLVVEUCBpcyBqdXN0IGludGVuZGVkIHRvIGJlIHVz ZWQgaW4gdGhlIHNjZW5hcmlvcyB3aGVyZSBNUExTLWluLUdSRS9JUCBoYXMgYmVlbiB1c2VkIGFu ZCBpcyB0byBiZSB1c2VkLCBNUExTLWluLVVEUCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBz YW1lIFdHIHdoZXJlIE1QTFMtaW4tR1JFL0lQIGhhcyBiZWVuIGRpc2N1c3NlZC4NCg0KWGlhb2h1 DQoNCj4gVGhlIE5WTzMgdGFzayBpcyB0byBkb2N1bWVudCB0aGUgaXNzdWVzLCByZXF1aXJlbWVu dHMgYW5kIGZyYW1ld29yayBmb3INCj4gTnZPMy4gVGhlbiBpZiBNUExTIG92ZXIgSVAgbG9va3Mg bGlrZSBhIHN1aXRhYmxlIHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlDQo+IHJlcXVpcmVtZW50cyBz dWNoIGFzIHRoZSBzY2FsZSwgbW9iaWxpdHksIGV0YywgdGhlbiB0aGV5IHdpbGwgYXNrIE1QTFMg V0cgZm9yDQo+IHByb3RvY29sIGRlc2lnbi4NCj4NCj4gU28gYmVmb3JlIHByb2NlZWRpbmcgdGhp cyBkcmFmdCwgSSB0aGluayB5b3Ugc2hvdWxkIHRha2UgaXQgdG8gTlZPMyBXRyBhbmQNCj4gY29u dmluY2UgdGhlbSB0aGlzIHNvbHV0aW9uIG1lZXRzIHRoZWlyIHJlcXVpcmVtZW50cyBhbmQgZnJh bWV3b3JrLg0KPg0KPiBXZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNv bHV0aW9ucyBmb3IgdGhlIHNhbWUgcHJvYmxlbSwgZG8NCj4gd2U/DQo+DQo+IC1TaGFocmFtDQo+ DQo+DQo+DQo+IFJlZ2FyZHMsDQo+IFNoYWhyYW0NCj4NCj4NCj4gT24gRGVjIDIwLCAyMDEyLCBh dCA4OjU2IEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3ku eW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+DQo+ID4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBv dmVybGF5IGlzIGRpc2N1c3NlZCB1bmRlciBudm8zIFdHLiBUaGlzIGRvZXMgbm90DQo+IG1lYW4g dGhhdCBudm8zIFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEgdW5kZXJseWlu ZyBuZXR3b3JrIG9yIGENCj4gbmV3IHByb3RvY29sIGZvciBhIG92ZXJsYXkgbmV0d29yay4gSW4g ZmFjdCwgcGVvcGxlIHRoZXJlIGFpbSBvbiBsZXZlcmFnZQ0KPiBzdGFuZGFyZCBuZXR3b3JrIHBy b3RvY29scyB0byBhY2NvbXBsaXNoIHRoZW0uIElNTzogdGhlc2UgZXhwYW5zaW9ucyBvbiBhbg0K PiBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhl IHByb3RvY29sIFdHIGdyb3VwLCBpdA0KPiBzaG91bGQgbm90IGdpdmUgbnZvMyBXRyBmcmVlIHJp Z2h0IHRvIGVuaGFuY2UgdGhlc2UgcHJvdG9jb2xzLiBGb3IgYSBicmFuZA0KPiBuZXcgcHJvdG9j b2wgZm9yIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSwgbnZvMyBXRyBtYXkgYmUgdGhl IHBsYWNlIHRvDQo+IHN0YXJ0Lg0KPiA+DQo+ID4gTHVjeQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJp QGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT5dDQo+ID4+IFNlbnQ6IFRo dXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiAxMDozNCBBTQ0KPiA+PiBUbzogTHVjeSB5b25nDQo+ ID4+IENjOiBTaGFuZSBBbWFudGU7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPiA+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBb bXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQo+ ID4+DQo+ID4+IE5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBtdXN0IGJlIGRpc2N1c3Nl ZCBhbmQgY29uc2VudGVkICBpbiBOVk8zDQo+ID4+IFdHLg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0K PiA+PiBTaGFocmFtDQo+ID4+DQo+ID4+DQo+ID4+IE9uIERlYyAyMCwgMjAxMiwgYXQgNzozOSBB TSwgIkx1Y3kgeW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVh d2VpLmNvbT4+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSGkgU2hhbmUsDQo+ID4+Pg0KPiA+Pj4gSSB1 bmRlcnN0YW5kIG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBzdWxhdGlvbiB0byBhbiBl eGlzdGluZw0KPiA+PiBuZXR3b3JrLg0KPiA+Pj4NCj4gPj4+IEhvd2V2ZXIsIE1QTFMtaW4tVURQ IGRvZXMgbm90IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9NUExTDQo+ID4+IG5ldHdv cmsgYXQgYWxsLg0KPiA+Pj4gTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxh eWVyIHRvIGJlIGRlY291cGxlZCBmcm9tIE1QTFMNCj4gPj4gc2VydmVyIGxheWVyIGFuZCB1c2Ug TVBMUyBjbGllbnQgbGF5ZXIgYXMgb3ZlcmxheSBuZXR3b3JrIGFuZCBhbiBJR1AgYXMNCj4gPj4g YSB1bmRlcmx5aW5nIG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBm b3IgREMuIFlvdSBtYXkNCj4gPj4gYXJndWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBm b3IgTVBMUyBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcNCj4gPj4gbmV0d29yay4gV2UgaGF2 ZSBwb2ludGVkIG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJvdXRlcnMgaW4gREMNCj4g Pj4gYmFyZWx5IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCBNUExTLWluLUdS RSBhcmUgYmFyZWx5IHVzZWQNCj4gPj4gaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRl cnMgaW4gREMgcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkDQo+ID4+IGJhbGFuY2luZyBub3cu DQo+ID4+Pg0KPiA+Pj4gRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQ IGVuY2Fwc3VsYXRpb24gaGFzDQo+ID4+IGFkdmFudGFnZSBvdmVyIEdSRSBlbmNhcHN1bGF0aW9u IHRvby4gSW4gVURQIGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZQ0KPiA+PiBoZWFkZXIgZGVjb3Vw bGVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRl cg0KPiA+PiBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBo ZWFkZXIsIHdoaWNoDQo+ID4+IHVuZGVybHlpbmcgbmV0d29yayB1c2VzIG9ubHkuIEhvd2V2ZXIs IEdSRSBoZWFkZXIgaGFzIHRoZSBmaWVsZHMgZm9yDQo+ID4+IHRoZSBvdmVybGF5IG5ldHdvcmsg YW5kIHVzZXMgdGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3IgbG9hZA0KPiA+PiBi YWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBHUkUgaGVh ZGVyIHRvby4gSW4NCj4gPj4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5 aW5nIG5ldHdvcmtzIHRvZ2V0aGVyLiBTaW5jZSBpdA0KPiA+PiBoYXMgbm90IHVzZWQgYSBsb3Qs IHBlb3BsZSBhcmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaA0KPiA+PiBj b3VwbGluZy4NCj4gPj4+DQo+ID4+PiBBcyB0aGUgaW5kdXN0cnkgbW92ZXMgdG93YXJkIG5ldHdv cmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBhbmQNCj4gPj4gZGVjb3VwbGVzIG92ZXJsYXkgbmV0 d29ya3MgZnJvbSB0aGUgdW5kZXJseWluZyBuZXR3b3JrLiBBIGNsZWFyDQo+ID4+IHNlcGFyYXRp b24gb2Ygb3ZlcmxheSBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlzIGEgIk1VU1QiIGlu IG15DQo+ID4+IG9waW5pb24uIElmIHdlIGNvdW50IEdSRSBhcyB0aGUgb3ZlcmxheSBoZWFkZXIs IHRoZW4gZm9yIElQdjQNCj4gPj4gdW5kZXJseWluZyBuZXR3b3JrLCB0aGVyZSBpcyBubyBmaWVs ZCBmb3IgdGhlIGZsb3cgZW50cm9weS4gVGhpcyBpcyB0aGUNCj4gPj4gcmVhc29uIHdlIHByb3Bv c2UgdGhlIFVEUCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVybHlpbmcNCj4g Pj4gbmV0d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkgbmV0d29yayBi ZXNpZGUgTVBMUyBjbGllbnQNCj4gPj4gbGF5ZXIgKGUuZy4gVlhMQU4sIEwyVFAtaW4tVURQLCBl dGMpLg0KPiA+Pj4NCj4gPj4+IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVE UCBpbnN0ZWFkLiBZZXMsIE1QTFMtaW4tTDJUUC0NCj4gPj4gaW4tVURQIHNjaGVtYSBhbHNvIHBy b3ZpZGVzIGEgb3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKQ0KPiA+PiBuZXR3b3Jr IGRlY291cGxpbmcuIEwyVFAgcHJvdG9jb2wgKHJmYzM5MzEpIHByb3ZpZGVzIGdvb2Qgc2VjdXJp dHkNCj4gPj4gbWVjaGFuaXNtIGFuZCBoYXMgdGhlIGVtYmVkZGVkIGNvbnRyb2wgZnVuY3Rpb24g dG9vLiBUaGVyZWZvcmUsDQo+IHNvbWVvbmUNCj4gPj4gY2FuIHVzZSBpdCBmb3IgTVBMUyBjbGll bnQgbGF5ZXIgb3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudA0KPiA+PiBsYXllciBv dmVyIGFuIElHUCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWluLUwyVFAtaW4tVURQIGlz IGENCj4gPj4gb3ZlcmtpbGwgYW5kIHRvbyBjb21wbGV4LiBIZXJlIHdlIG5lZWQgYSBzY2hlbWEg dG8gc3VwcG9ydCBJR1ANCj4gPj4gdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0aG91dCB0b3VjaGlu ZyBhIG92ZXJsYXkgaGVhZGVyLiBVRFANCj4gPj4gZW5jYXBzdWxhdGlvbiBpcyB0aGUgYmVzdCBj aG9pY2UgdG8gYWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGUNCj4gPj4gY2hhbmdlcyBv biBleGlzdGluZyByb3V0ZXJzLCBlLmcuIGNoYW5nZSBhdCBlZGdlIHJvdXRlcnMsIG5vIGNoYW5n ZSBvbg0KPiA+PiB0cmFuc2l0IHJvdXRlcnMuDQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+ IEx1Y3kNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+Pj4+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbTxt YWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT5dDQo+ID4+Pj4gU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDIwLCAyMDEyIDQ6MTQgQU0NCj4gPj4+PiBUbzogU2hhbmUgQW1hbnRlDQo+ID4+Pj4gQ2M6 IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4+IHVk cEB0b29scy5pZXRmLm9yZzxtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnPjsNCj4gPj4+PiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6IERp c2N1c3Npb24gb24gaG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIgVURQIHR1bm5lbHMNCj4gPj4+ Pg0KPiA+Pj4+IEhpIFNoYW5lLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB5b3VyIGZ1cnRo ZXIgY29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0KPiA+Pj4+DQo+ ID4+Pj4gTm90ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdz IHN1Z2dlc3Rpb24uDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ Pj4+PiDlj5Hku7bkuro6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5l dDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4gPj4+Pj4g5Y+R6YCB5pe26Ze0OiAy MDEy5bm0MTLmnIgxOeaXpSAyMjozOA0KPiA+Pj4+PiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4+ Pj4+IOaKhOmAgTogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1p bi0NCj4gPj4+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnVkcEB0b29scy5pZXRmLm9yZz47 DQo+ID4+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+ Pj4+IOS4u+mimDogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8g bWFrZSBkcmFmdC14dS0NCj4gPj4+PiBtcGxzLWluLXVkcCBhbg0KPiA+Pj4+PiBtcGxzIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4NCj4gPj4+Pj4gWGlhb2h1LA0KPiA+Pj4+Pg0KPiA+ Pj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQo+IHdyb3RlOg0KPiA+Pj4+PiAt LS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+Pj4+Pj4g5Y+R5Lu25Lq6OiBTaGFuZSBBbWFudGUg W21haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5l dD5dDQo+ID4+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MTLmnIgxOeaXpSAxMTo1OA0KPiA+ Pj4+Pj4+IOaUtuS7tuS6ujogUm9nZXJzLCBKb3NoDQo+ID4+Pj4+Pj4g5oqE6YCBOiBTaGFocmFt IERhdmFyaTsgWHV4aWFvaHU7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4+Pj4gdWRwQHRvb2xzLmll dGYub3JnPG1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWls dG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4g5Li76aKYOiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LQ0KPiA+ Pj4+IG1wbHMtaW4tdWRwDQo+ID4+Pj4+IGFuDQo+ID4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3Vw IGRvY3VtZW50DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIERlYyAxOCwgMjAx MiwgYXQgODo1MCBBTSwgIlJvZ2VycywgSm9zaCINCj4gPj4+PiA8am9zaC5yb2dlcnNAdHdjYWJs ZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCj4gPj4+Pj4+PiB3cm90ZToN Cj4gPj4+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90IHNlZSB0 aGUgcHJvYmxlbSB0aGlzDQo+ID4+Pj4gc29sdXRpb24NCj4gPj4+Pj4+Pj4gYWRkcmVzc2VzIGlu IHByYWN0aWNlIGFueSBsb25nZXIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiArMS4gIFBsZWFzZSBk byBub3QgZGVmaW5lIHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0aW9uLg0KPiA+ Pj4+IFRoZQ0KPiA+Pj4+PiBJRVRGDQo+ID4+Pj4+Pj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBM UyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvDQo+ID4+Pj4gc3RhbmRhcmRpemVkDQo+ID4+ Pj4+IE1QTFMNCj4gPj4+Pj4+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNv bWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdA0KPiA+PiBvbmUsDQo+ID4+Pj4gdmVyeQ0KPiA+Pj4+ Pj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBj YXJyaWFnZSBvZg0KPiA+Pj4+IEwzVlBOIG92ZXINCj4gPj4+Pj4gYW4NCj4gPj4+Pj4+PiBJUC1v bmx5IG5ldHdvcmsuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU2hhbmUsDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gVGhhbmsgeW91IGZvciB0ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwgZGVwbG95bWVu dHMgb2YgTVBMUyBvdmVyDQo+ID4+Pj4gSVAgaW4gYXQNCj4gPj4+Pj4gbGVhc3Qgb25lLCB2ZXJ5 IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkNCj4gPj4+PiB2 YWx1YWJsZSB0byB0aG9zZQ0KPiA+Pj4+PiBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0aGVyZSBp cyBubyBhcHBsaWNhdGlvbiBvZiBNUExTIG92ZXIgSVAgaW4NCj4gPj4+PiB0b2RheSdzIFNQDQo+ ID4+Pj4+IG5ldHdvcmtzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBTZWU6IFJGQydzIDQ0NTQsIDQ3 MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4+PiBbTk9URTogdGhl IGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUgMjAwNg0KPiA+ Pj4+PiB0aW1lZnJhbWUhXQ0KPiA+Pj4+Pj4+ICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJl bGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4gPj4+PiBtYXkgYmUNCj4gPj4+Pj4+ PiBjYXJyaWVkIG92ZXIgTDJUUHYzDQo+ID4+Pj4+Pj4gIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNo b3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcw0KPiA+Pj4+PiBpbXBsZW1lbnRlZA0K PiA+Pj4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+ID4+IGh0dHA6Ly93d3cuY2lzY28uY29t L2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRtbA0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmluZyB0aGUgYWJvdmUgaW5mb3JtYXRp b24uIEFzIG1lbnRpb25lZCBpbg0KPiA+Pj4+IHRoaXMgZHJhZnQNCj4gPj4+Pj4gQU5EIG90aGVy IGRyYWZ0cywgdGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb24gb24N Cj4gPj4gdGhlDQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYz IGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzDQo+ID4+Pj4gZGVm aW5lZCBpbg0KPiA+Pj4+PiBbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4 aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEZXSVcsIEkgaGF2 ZSBoYWQgc3VjY2VzcywgaW4gdGhlIHJlbGF0aXZlbHkgcmVjZW50IHBhc3QsIGluDQo+ID4+Pj4g cmVxdWVzdGluZyBhIGNvcmUNCj4gPj4+Pj4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5n ZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4+Pj4gY2FsY3VsYXRpb25zIGlu DQo+ID4+Pj4+IF9leGlzdGluZ18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2 ZWx5KSB0aHJvdWdob3V0IG15DQo+ID4+Pj4gbmV0d29yay4NCj4gPj4+Pj4gRnVydGhlciwgSSBz dXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkNCj4gPj4g Zm9sa3MNCj4gPj4+PiBhbmQNCj4gPj4+Pj4gdW5kZXJzdGFuZCB0aGUgaW50ZXJuYWwgYXJjaGl0 ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPiA+Pj4+IHJlc3VsdCwgdGhv c2UNCj4gPj4+Pj4gc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3QgdGVjaG5p Y2FsbHkgcG9zc2libGUgaW4gdGhpcw0KPiA+Pj4+IHJlZ2FyZC4NCj4gPj4+Pj4gVGh1cywgaXQg bWF5IGJlIGEgcXVlc3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVp cg0KPiA+Pj4+IEhXDQo+ID4+Pj4+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlhdGUgY2hh bmdlcyBpbiB0aGVpciBlcXVpcG1lbnQgdG8NCj4gPj4gYWNoaWV2ZQ0KPiA+Pj4+IHRoZWlyDQo+ ID4+Pj4+IGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBi ZSBuZWNlc3NhcnkgLi4uDQo+ID4+IHNlZQ0KPiA+Pj4+IGJlbG93Lg0KPiA+Pj4+DQo+ID4+Pj4g Q291bGQgeW91IHBsZWFzZSBicmllZmx5IGV4cGxhaW4gaG93IHRvIG1ha2UgdGhlIGFib3ZlIGNo YW5nZSBpbg0KPiA+Pj4+IEVYSVNUSU5HIGhhcmR3YXJlIG9mIGFscmVhZHkgZGVwbG95ZWQgY29y ZSByb3V0ZXJzPw0KPiA+Pj4+DQo+ID4+Pj4+PiBJbiBjb250cmFzdCwgbW9zdCBleGlzdGluZyBj b3JlIHJvdXRlcnMgYXJlIGFscmVhZHkgY2FwYWJsZSBvZg0KPiA+Pj4+IGJhbGFuY2luZyBJUA0K PiA+Pj4+PiB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxl IG9mIFVEUCBwYWNrZXRzLg0KPiA+PiBCeQ0KPiA+Pj4+IHVzaW5nIHRoZQ0KPiA+Pj4+PiBNUExT LWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNp bmcNCj4gPj4+PiBjYXBhYmlsaXR5IG9mDQo+ID4+Pj4+IG1vc3QgZXhpc3RpbmcgY29yZSByb3V0 ZXJzIGNhbiBiZSBsZXZlcmFnZWQgd2l0aG91dCByZXF1aXJpbmcgYW55DQo+ID4+Pj4gY2hhbmdl IHRvDQo+ID4+Pj4+IHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2YgdGhpcyBk cmFmdC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5IG5v dCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbg0KPiA+Pj4+IE1QTFMvTDJUUHYzLCB3aGljaA0K PiA+Pj4+PiB1c2VzIFVEUC9JUCwgaW4gdGhlIGZpcnN0IHBsYWNlPw0KPiA+Pj4+DQo+ID4+Pj4g SWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgeW91IHByZWZlciB0byB1c2UgTVBMUy1pbi1M MlRQdjMtaW4tDQo+ID4+IFVEUA0KPiA+Pj4+IGluc3RlYWQgb2YgTVBMUy1pbi1VRFAsIHJpZ2h0 Pw0KPiA+Pj4+DQo+ID4+Pj4+IElNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25z aWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0KPiA+Pj4+IFJGQyAzOTMxLA0KPiA+Pj4+PiB3 aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1c2VkIGZvciBkYXRhIHBhY2tldHMgKG5v dCBjb250cm9sDQo+ID4+Pj4gcGFja2V0cykNCj4gPj4+Pj4gdG8gdXNlIGEgdmFyeWluZyBzZXQg b2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksDQo+ID4+IGJhc2VkDQo+ ID4+Pj4gb24gYSBoYXNoDQo+ID4+Pj4+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBs b2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nDQo+ID4+IGVxdWlwbWVudA0KPiA+Pj4+IGluIGFu DQo+ID4+Pj4+IElQLW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMg d291bGQgYmUgYmV0dGVyIG9mZg0KPiA+Pj4+IGp1c3QgdXNpbmcNCj4gPj4+Pj4gdGhlICJTZXNz aW9uIElEIiAoYW5kICJDb29raWUiKSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlwbGV4b3IgdG8NCj4g Pj4+PiBhc3NvY2lhdGUNCj4gPj4+Pj4gaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lh dGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwNCj4gPj4+PiBpdCdzIG5vdA0KPiA+ Pj4+PiBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkgL2FscmVh ZHkvIGRvIHRoaXMsDQo+ID4+Pj4gbWFraW5nIGFueQ0KPiA+Pj4+PiAiY2hlY2siIG9uIHRoZSBp bmNvbWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtDQo+ID4+ Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIGJlYXV0eSBvZiB0aGUg YWJvdmUgYXBwcm9hY2ggaXM6DQo+ID4+Pj4+IDEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgYWJv dmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcw0KPiA+Pj4+IGxpbWl0ZWQgdG8gdGhl DQo+ID4+Pj4+ICJjb250cm9sIGNoYW5uZWwiIChzb2Z0d2FyZSkgb2YgZXhpc3RpbmcgTDJUUCBl bmQtc3lzdGVtDQo+ID4+Pj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4+PiBIZWNrLCBpdCBtYXkg ZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2Mw0KPiA+Pj4+ PiBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNv bW1lbnQgb24NCj4gPj4gdGhhdCkuDQo+ID4+Pj4NCj4gPj4+PiBJTUhPLCBubyBtYXR0ZXIgTVBM Uy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCAgdGhlIGhhcmR3YXJlDQo+ID4+IG9m DQo+ID4+Pj4gUEUgcm91dGVycyBuZWVkcyB0byBiZSB1cGdyYWRlZCwgZS5nLiwgaW5ncmVzcyBQ RSByb3V0ZXJzIG5lZWQgdG8NCj4gPj4gZmlsbA0KPiA+Pj4+IGluIGFuIGVudHJvcHkgdmFsdWUg aW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiA+Pj4+DQo+ID4+Pj4+ IDIpIFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdldHMgYnkgdXNp bmcgIlNlc3Npb24NCj4gPj4+PiBJRCIgYW5kDQo+ID4+Pj4+ICJDb29raWUiIGZpZWxkcyB0byBl bnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQNCj4gPj4gZm9yDQo+ ID4+Pj4gdGhlDQo+ID4+Pj4+IGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0 aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gPj4+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4+PiAgTDJUUHYz IHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzItYml0DQo+ ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRlci4gIFdo ZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWUNCj4gPj4+Pj4gIChkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGNoZWNrIHRvDQo+ID4+IGVuc3VyZQ0K PiA+Pj4+PiAgdGhhdCBhbiBhcnJpdmluZyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yIHRoZSBpZGVu dGlmaWVkIHNlc3Npb24uDQo+ID4+Pj4+ICBUaHVzLCB1c2Ugb2YgYSBDb29raWUgd2l0aCB0aGUg U2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0KPiA+Pj4+IGd1YXJhbnRlZQ0KPiA+Pj4+PiAg dGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZvcm1lZCBwcm9wZXJseSBhbmQgdGhh dCB0aGUNCj4gPj4+Pj4gIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3QgY29ycnVwdGVkIGluIHRy YW5zaXQuDQo+ID4+Pj4+IC0tLXNuaXAtLS0NCj4gPj4+Pj4gLi4uIGluIHJlZ2FyZCB0byB0aGlz IHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWENCj4gPj4gZm9sa3MNCj4g Pj4+PiBoYXZlLCBpbiB0aGUNCj4gPj4+Pj4gcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2Vy bnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXINCj4gPj4gSVANCj4gPj4+PiB0cmFu c3BvcnQuDQo+ID4+Pj4+IEluIGZhY3QsIHRoaXMgaXMgd2h5IHlvdSBzZWUgdGV4dCBpbiBTZWN0 aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YNCj4gPj4gUkZDDQo+ID4+Pj4gNDY2NS4NCj4gPj4+Pj4g KFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdXNl IE1QTFMgZm9yDQo+ID4+Pj4gdHJhbnNwb3J0KS4NCj4gPj4+Pj4gV2hpbGUgSSdtIG5vdCBzdXJl IHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8NCj4gPj4+PiBk YWlseSB0cmFmZmljIG9uDQo+ID4+Pj4+IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdCwgSSdtIGZh aXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGwNCj4gPj4+PiBhcmlzZSBpZi93aGVuIHRo aXMNCj4gPj4+Pj4gZHJhZnQgZ29lcyB0byB0aGUgSUVTRyAuLi4NCj4gPj4+Pg0KPiA+Pj4+IElm IEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJlZmVyZW5j ZSBvZg0KPiA+PiBNUExTLQ0KPiA+Pj4+IGluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBoYXMg YW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdA0KPiA+PiBpcw0KPiA+Pj4+IHNvIGNv bmNlcm5lZCwgY2FuIHlvdSBleHBsYWluIHdoeSBNUExTLWluLUdSRSBpcyBmYXIgbW9yZSBwb3B1 bGFyDQo+ID4+IHRoYW4NCj4gPj4+PiBNUExTLWluLUwyVFAgaW4gcHJhY3RpY2U/DQo+ID4+Pj4N Cj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4gWGlhb2h1DQo+ID4+Pj4NCj4gPj4+Pj4gMykg RmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQN Cj4gPj4gaW1wbGVtZW50DQo+ID4+Pj4gTDJUUCwgZm9yDQo+ID4+Pj4+IHR1bm5lbGluZyBvZiBN UExTL0lQLCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG8NCj4gPj4+ PiBzdXBwb3J0DQo+ID4+Pj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIgcHJvZHVj dCBsaW5lcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gLXNoYW5lDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+Pj4gWGlhb2h1DQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4+IElmIHRoZXJlIHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92ZXIgSVAsIHRo ZW4gY2xlYXJseSBpdA0KPiA+PiB3b3VsZA0KPiA+Pj4+IGhhdmUNCj4gPj4+Pj4gYmVlbg0KPiA+ Pj4+Pj4+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRo IGVpdGhlciBNUExTDQo+ID4+Pj4gb3Zlcg0KPiA+Pj4+PiBHUkUgb3INCj4gPj4+Pj4+PiBNUExT IG92ZXIgTDJUUHYzLiAgKFdoZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5KS4gIEkN Cj4gPj4gd291bGQNCj4gPj4+PiBub3RlDQo+ID4+Pj4+IHRoYXQNCj4gPj4+Pj4+PiB0aGUgbW9z dCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBub3QgcGFuIG91dCB3YXMgdGhlcmUgYXJlDQo+ID4+ IHNldmVyYWwsDQo+ID4+Pj4gcHJhY3RpY2FsDQo+ID4+Pj4+Pj4gb3BlcmF0aW9uYWwgYmVuZWZp dHMgb25lIGdldHMgZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+ID4+Pj4+Pj4gZW5jYXBz dWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+ID4+Pj4+ Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4gPj4+Pj4+PiAtIE1QTFMgVHJhZmZpYyBFbmdpbmVl cmluZw0KPiA+Pj4+Pj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRl ZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nDQo+ID4+Pj4+IGFyZ3VtZW50cw0KPiA+Pj4+Pj4+IHRv ICd1cGdyYWRlJyBuZXR3b3JrIEhXIHRvIHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0aW9uL3N3aXRj aGluZy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IC1zaGFuZQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gLUpvc2gNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gT24g MTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb208 bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KPiA+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQIGlz IGxlZ2FjeSBhbmQgdGhlcmUNCj4gPj4gaXMNCj4gPj4+PiBubyBuZWVkDQo+ID4+Pj4+Pj4+PiB0 byBpbXByb3ZlIGl0Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+ Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE9uIERl YyAxNywgMjAxMiwgYXQgODowMiBQTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2VpLmNvbTxt YWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gVGhpcyBk cmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVANCj4gPj4+PiBl bmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxh bmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gPj4+PiB0aG9zZQ0KPiA+Pj4+Pj4+Pj4+ IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGlj YXRpb24NCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+Pj4+Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJ IGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4gPj4gYW5kDQo+ID4+Pj4+ IFZYTEFODQo+ID4+Pj4+Pj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBhZHZvY2F0b3JzIGFuZCB1 c2UgY2FzZXMuIElmIHlvdQ0KPiA+PiBhYnNvbHV0ZWx5DQo+ID4+Pj4gYmVsaWV2ZQ0KPiA+Pj4+ Pj4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24g dHJhZmZpYw0KPiA+Pj4+IGFjcm9zcyBJUA0KPiA+Pj4+Pj4+Pj4+IG5ldHdvcmtzIGFuZCB0aGVy ZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMNCj4gPj4gb3Zlcg0KPiA+ Pj4+IElQDQo+ID4+Pj4+Pj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMgc2hvdWxkIGJlIG1vdmVk IHRvIEhpc3RvcmljIHN0YXR1cywNCj4gPj4gcGxlYXNlDQo+ID4+Pj4gc2F5DQo+ID4+Pj4+IHNv Lg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQnkgdGhlIHdheSwgaXQgc2VlbXMgdGhpcw0K PiA+Pj4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ID4+Pj4gYXJjaGl2ZS93 ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+Pj4+Pj4+Pj4ganVzdCB0aGUg cmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9sbG93aW5nDQo+ID4+ Pj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNl ZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+ID4+Pj4gY2VudGVycykuIEkNCj4gPj4+Pj4+ Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhhdCB0aW1lLiBTYWRseSwN Cj4gPj4+PiBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+Pj4+Pj4+Pj4gdGlsbCBub3cuDQo+ID4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBh Ym92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBYaWFvaHUNCj4gPj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+Pj4+Pj4+ Pj4+IOWPkeS7tuS6ujogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmc+XQ0KPiA+PiDku6MNCj4gPj4+PiDooagNCj4gPj4+Pj4+PiBTLg0KPiA+Pj4+ Pj4+Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MTLmnIgx NeaXpSAxMzozNA0KPiA+Pj4+Pj4+Pj4+PiDmlLbku7bkuro6IExvYSBBbmRlcnNzb24NCj4gPj4+ Pj4+Pj4+Pj4g5oqE6YCBOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPjsNCj4gPj4+Pj4+Pj4+Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+PiDk uLvpopg6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UN Cj4gPj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPj4+Pj4+Pj4+Pj4gbXBs cyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEkg ZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbg0K PiA+Pj4+IHRvZGF5J3MNCj4gPj4+Pj4+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+ID4+Pj4+Pj4+Pj4+ IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQgaXRzIG9ubHkgcHJhY3RpY2Fs DQo+ID4+Pj4gYXBwbGljYXRpb24NCj4gPj4+Pj4+Pj4+Pj4gaW4gaW4gZGF0YQ0KPiA+Pj4+Pj4+ Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90aGVyIHNvbHV0aW9u cyBzdWNoIGFzDQo+ID4+Pj4gTlZHUkUNCj4gPj4+Pj4gYW5kDQo+ID4+Pj4+Pj4+Pj4+IFZYTEFO Lg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUg dHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbg0KPiA+Pj4+IHNlbGVjdGlvbg0KPiA+ Pj4+Pj4+Pj4+PiBwcm9jZXNzDQo+ID4+Pj4+Pj4+Pj4+IGJ5IGFkdmFuY2luZyB0aGUgZHJhZnQg aW4gTVBMUyBXRy4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+ Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5u dTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+ PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFRoaXMgaXMg dG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+Pj4+Pj4+Pj4+IGRy YWZ0LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4N Cj4gPj4+Pj4+Pj4+Pj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBi ZWVuIGV4dGVuZGVkIHdpdGgNCj4gPj4+PiBvbmUgd2Vlay4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0 KSB0byB0aGUgbXBscw0KPiA+Pj4+PiB3b3JraW5nDQo+ID4+Pj4+Pj4+Pj4+PiBncm91cCBtYWls aW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhbg0KPiA+Pj4+IHRlY2hu aWNhbA0KPiA+Pj4+Pj4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBw b3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiA+Pj4+IHRoaW5rIHRoYXQNCj4gPj4+Pj4+Pj4+Pj4+ IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwDQo+ ID4+Pj4gZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBwb2xs IGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBU aGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQo+ID4+Pj4+Pj4+ Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+ID4+Pj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28tYXV0aG9ycyBoYXMgc3RhdGVk IG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+Pj4gbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4+ PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWltcyB0aGFuIHRo b3NlDQo+ID4+Pj4gYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4+Pj4gZGlzY2xvc2VkLg0KPiA+Pj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9j dW1lbnQgdGhhdCB3ZSB1c2VkIGZvcg0KPiA+PiB0aGUNCj4gPj4+PiBJUFINCj4gPj4+Pj4+Pj4+ Pj4+IHBvbGwpDQo+ID4+Pj4+Pj4+Pj4+PiBNYXJzaGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMg b25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbA0KPiA+Pj4+IGhhcw0KPiA+Pj4+Pj4+Pj4+Pj4g ZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRo ZQ0KPiA+Pj4+IGF1dGhvciB0ZWFtDQo+ID4+Pj4+Pj4+Pj4+PiBvZiBkcmFmdC14dS1tcGxzLWlu LXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcw0KPiA+Pj4+IHRyaWVkIHRvDQo+ ID4+Pj4+Pj4+Pj4+PiBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0 IGEgcmVzcG9uc2Ugb24NCj4gPj4gdGhlDQo+ID4+Pj4gSVBSDQo+ID4+Pj4+Pj4+Pj4+PiBwb2xs Lg0KPiA+Pj4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPiA+Pj4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhvcnMgZGVj aWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPiA+Pj4+Pj4+Pj4+Pj4gY28tYXV0aG9yLg0K PiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IC9Mb2ENCj4gPj4+Pj4+Pj4+Pj4+IChtcGxz IHdnIGNvLWNoYWlyKQ0KPiA+Pj4+Pj4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOg0KPiA+Pj4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxtYWls dG86bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DQo+ID4+Pj4+Pj4+Pj4+PiBTciBTdHJhdGVn eSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBw aS5udT4NCj4gPj4+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAg ICAgcGhvbmU6ICs0NiAxMCA3MTcNCj4gNTINCj4gPj4gMTMNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTINCj4gMTMNCj4g Pj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+Pj4gbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+PiBt cGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+ PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcg0KPiA+ Pj4+IENhYmxlDQo+ID4+Pj4+Pj4gcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHBy aXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4gPj4+PiBzdWJqZWN0IHRvDQo+ID4+Pj4+Pj4g Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMg aW50ZW5kZWQNCj4gPj4+PiBzb2xlbHkgZm9yDQo+ID4+Pj4+IHRoZQ0KPiA+Pj4+Pj4+IHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5 b3UNCj4gPj4+PiBhcmUgbm90IHRoZQ0KPiA+Pj4+Pj4+IGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdA0KPiA+Pj4+IGFueQ0KPiA+ Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPiA+Pj4+Pj4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZQ0KPiA+PiBjb250ZW50cw0KPiA+Pj4+IG9m IGFuZA0KPiA+Pj4+Pj4+IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZQ0KPiA+Pj4+IHVubGF3ZnVsLiBJZiB5b3UNCj4gPj4+Pj4+PiBo YXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXINCj4gPj4+PiBpbW1lZGlhdGVseSBhbmQNCj4gPj4+Pj4+PiBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQNCj4gPj4+PiBhbnkg cHJpbnRvdXQuDQo+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxzIG1haWxpbmcg bGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0K PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98Aszxeml525mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC55aXYyMDM5MzczMDI2bXNvbm9ybWFsLCBsaS55aXYyMDM5MzczMDI2bXNvbm9ybWFs LCBkaXYueWl2MjAzOTM3MzAyNm1zb25vcm1hbA0KCXttc28tc3R5bGUtbmFtZTp5aXYyMDM5Mzcz MDI2bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnAueWl2MjAzOTM3MzAyNm1z b2NocGRlZmF1bHQsIGxpLnlpdjIwMzkzNzMwMjZtc29jaHBkZWZhdWx0LCBkaXYueWl2MjAzOTM3 MzAyNm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3MzAyNm1zb2NocGRl ZmF1bHQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi55aXYyMDM5MzczMDI2bXNvaHlw ZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjIwMzkzNzMwMjZtc29oeXBlcmxpbms7fQ0Kc3Bh bi55aXYyMDM5MzczMDI2bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjAzOTM3MzAyNm1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MjAzOTM3MzAyNmVtYWls c3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTp5aXYyMDM5MzczMDI2ZW1haWxzdHlsZTE3O30NCnAu eWl2MjAzOTM3MzAyNm1zb25vcm1hbDEsIGxpLnlpdjIwMzkzNzMwMjZtc29ub3JtYWwxLCBkaXYu eWl2MjAzOTM3MzAyNm1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3MzAyNm1z b25vcm1hbDE7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNw YW4ueWl2MjAzOTM3MzAyNm1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3 MzAyNm1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4ueWl2MjAzOTM3MzAyNm1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5 bGUtbmFtZTp5aXYyMDM5MzczMDI2bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MjAzOTM3MzAyNmVtYWls c3R5bGUxNzENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3MzAyNmVtYWlsc3R5bGUxNzE7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnAu eWl2MjAzOTM3MzAyNm1zb2NocGRlZmF1bHQxLCBsaS55aXYyMDM5MzczMDI2bXNvY2hwZGVmYXVs dDEsIGRpdi55aXYyMDM5MzczMDI2bXNvY2hwZGVmYXVsdDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjAzOTM3MzAyNm1zb2NocGRlZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4u RW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+IFMuIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNoQHlhaG9vLmNvbV0NCjxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiAyMDEyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTI8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjIy PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gNjo0MDxicj4NCjwvc3Bhbj48Yj7mlLbku7bk uro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBMdWN5 IHlvbmc7IFh1eGlhb2h1OyBTaGFocmFtIERhdmFyaTxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBv dmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5MdWN5LDxicj4NCjxicj4NCkkgY2FuIG9u bHkgc2VlIENoaW5hIFRlbGVjb20gYXMgY28tYXV0aG9yLCBhbmQgdGhlIEFwcGxpY2FiaWxpdHkg c2VjdGlvbiBzYXlzIEwyVlBOIGFuZCBMM1ZQTi4gU28gaXMgQ2hpbmEgVGVsZWNvbSB1c2luZyBp dCBmb3IgdGhlaXIgRW50ZXJwcmlzZSBWUE4gc2VydmljZT8gYnV0IHlvdXIgZWFybGllciBlbWFp bHMgc3VnZ2VzdHMgdGhhdCB0aGlzIGlzIG5vdCB0aGUgaW50ZW5kZWQgdXNhZ2UgcmF0aGVyIGl0 IGlzIGZvciBEYXRhIENlbnRlci4NCiBTbyB3aGljaCBvbmUgaXMgaXQ/IFdoeSBpc24ndCBDaGlu YSBUZWxlY29tIHNwZWFraW5nIG9uIHRoZSBsaXN0IGFuZCBleHBsYWluaW5nIHRoZWlyIHVzYWdl IG1vZGVsPzxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSBZZXMs IHRoZSBBcHBsaWNhYmlsaXR5IHNlY3Rpb24gc2F5cyBMMlZQTiBhbmQgTDNWUE4sIGJ1dCB0aGVy ZSBpcyBubyBsaW1pdCB0aGF0IHRoZXNlIHRlY2hub2xvZ2llcw0KIGNvdWxkIG9ubHkgYmUgdXNl ZCBieSBzZXJ2aWNlIHByb3ZpZGVycz8gJm5ic3A7RW50ZXJwcmlzZXMgdGhlbXNlbHZlcyBjb3Vs ZCBhZG9wdCB0aGVzZSB0ZWNobm9sb2dpZXMgdG8gaW50ZXJjb25uZWN0IHRoZWlyIG11bHRpcGxl IHNpdGVzIGFuZCBkYXRhIGNlbnRlciBvcGVyYXRvcnMgY291bGQgdXNlIHRoZW0gd2l0aGluIG9y IGV2ZW4gYWNyb3NzIGRhdGEgY2VudGVycyBhcyB3ZWxsIGlmIHRoZXkgd291bGQgbGlrZS4gTGV0 IG1lIGl0ZXJhdGUgdGhhdA0KIE1QTFMtYmFzZWQgVlBOIG92ZXIgSVAgY2FuIGJlIHVzZWQgaW4g U1AgbmV0d29ya3MsIGVudGVycHJpc2UgbmV0d29ya3MgYW5kIGV2ZW4gZGF0YSBjZW50ZXJzIGFu ZCB0aGVyZWZvcmUgTVBMUy1pbi1VRFAgaXMgYXBwbGljYWJsZSB0byBhbnkgb2YgdGhlIGFib3Zl IHNjZW5hcmlvIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpBbHNvIHJlZ2FyZGluZyBN dWx0aWNhc3QsIHRoaXMgbWVhbnMgeW91IG5lZWQgdG8gbWFwIE11bHRpY2FzdCB0cmFmZmljIHRv IFAyUCBQVywgd2hpY2ggaXMgaW5mZXJpb3IgdG8gb3RoZXIgbWV0aG9kcyBzdWNoIGFzIE5WR1JF IGFuZCBWWExBTiBzaW5jZSB0aGV5IG5hdGl2ZWx5IHN1cHBvcnQgZWZmaWNpZW50IE11bHRpY2Fz dC48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1hpYW9odV0gRmlyc3QsIHJl bWVtYmVyIHRoYXQgTVBMUy1pbi1VRFAgaXMgbm90IG9ubHkgc3VpdGFibGUgZm9yIE1QTFMtYmFz ZWQgTDJWUE4gYnV0IGFsc28gc3VpdGFibGUNCiBmb3IgTDNWUE4uIFNlY29uZCwgTVBMUy1iYXNl ZCBWUE4gY2FuIHN1cHBvcnQgYm90aCBpbmdyZXNzIHJlcGxpY2F0aW9uIG1vZGUgYW5kIG11bHRp Y2FzdCB0cmVlIG1vZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpUaGFua3MsPGJyPg0KU2hhaHJh bTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4N CjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IEx1Y3kgeW9uZyAmbHQ7bHVjeS55b25nQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+VG86PC9iPiBT LiBEYXZhcmkgJmx0O2RhdmFyaXNoQHlhaG9vLmNvbSZndDs7IFh1eGlhb2h1ICZsdDt4dXhpYW9o dUBodWF3ZWkuY29tJmd0OzsgU2hhaHJhbSBEYXZhcmkgJmx0O2RhdmFyaUBicm9hZGNvbS5jb20m Z3Q7DQo8YnI+DQo8Yj5DYzo8L2I+ICZxdW90O2RyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmll dGYub3JnJnF1b3Q7ICZsdDtkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyZndDs7 ICZxdW90O21wbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHNAaWV0Zi5vcmcmZ3Q7OyAmcXVvdDtt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZxdW90OyAmbHQ7bXBscy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmcmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAx OjU1OjEwIFBNPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5 ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdiBpZD0ieWl2MjAzOTM3MzAyNiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TaGFocmFtLDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGlubGlu ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiBTLg0KIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNoQHlhaG9vLmNvbV0gPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMjEsIDIwMTIgMjoxMCBBTTxicj4NCjxiPlRv OjwvYj4gWHV4aWFvaHU7IFNoYWhyYW0gRGF2YXJpOyBMdWN5IHlvbmc8YnI+DQo8Yj5DYzo8L2I+ IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIE1Q TFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yazwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGksPGJyPg0KPGJyPg0KSSB0aGluayB3ZSBh cmUgaW4gYSB2aWNpb3VzIGN5Y2xlLiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggbmV0 d29yayBvcGVyYXRvciBpcyBhc2tpbmcgZm9yIE1QTFMgb3ZlciBVRFAgYW5kIHdoYXQgaXMgdGhl IGFwcGxpY2F0aW9uLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ W0x1Y3ldIGl0IGlzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuPC9zcGFuPjwvaT48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWxzbyBob3cgZG8g eW91IHBsYW4gdG8gYWRkcmVzcyB0aGUgTVBMUyBNdWx0aWNhc3QgKHdoaWNoIGlzIHByb2JhYmx5 IG1vcmUgaW1wb3J0YW50IHRoYW4gaW1wcm92aW5nIHRoZSBsb2FkIGJhbGFuY2luZyksIGdpdmVu IHRoYXQgUkZDNDAyMw0KIGRvZXMgbm90IHN1cHBvcnQgTXVsdGljYXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMdWN5XSBNUExTIENsaWVudCBMYXllciBpcyByZXNwb25z aWJsZSB0byBtYXAgbXVsdGljYXN0IHRyYWZmaWMgdG8gdW5kZXJseWluZyB0cmFuc3BvcnQsIHdo aWNoIGlzIHNwZWNpZmllZA0KIGluIEVWUE4gYW5kIElQIFZQTi4gVGhpcyBwcm9wb3NhbCBqdXN0 IHJlcXVlc3RzIGluZ3Jlc3MgUEUgdG8gZmlsbCB0aGUgZmxvdyBlbnRyb3B5IGludG8gVURQIHNv dXJjZSBwb3J0LCBpbiB3aGljaCB0aGUgZmxvdyBjYW4gYmUgdW5pY2FzdCBvciBtdWx0aWNhc3Qu DQo8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkx1Y3k8L3NwYW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwv aT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClNoYWhyYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiBYdXhpYW9odQ0KICZsdDt4dXhpYW9odUBodWF3ZWkuY29t Jmd0Ozxicj4NCjxiPlRvOjwvYj4gU2hhaHJhbSBEYXZhcmkgJmx0O2RhdmFyaUBicm9hZGNvbS5j b20mZ3Q7OyBMdWN5IHlvbmcgJmx0O2x1Y3kueW9uZ0BodWF3ZWkuY29tJmd0Ow0KPGJyPg0KPGI+ Q2M6PC9iPiAmcXVvdDtkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyZxdW90OyAm bHQ7ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmcmZ3Q7OyAmcXVvdDttcGxzQGll dGYub3JnJnF1b3Q7ICZsdDttcGxzQGlldGYub3JnJmd0OzsgJnF1b3Q7bXBscy1jaGFpcnNAdG9v bHMuaWV0Zi5vcmcmcXVvdDsgJmx0O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0Ow0KPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA1OjU2OjIzIFBNPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJ R1AgdW5kZXJseWluZyBuZXR3b3JrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+6YKu5Lu25Y6f5Lu2PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0tLTxicj4NCiZndDsgPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj46DQo8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxz LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ 5Luj6KGoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+ DQomZ3Q7IFNoYWhyYW0gRGF2YXJpPGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuW5tDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjIxPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5pelPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAxOjMxPGJyPg0KJmd0 OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7mlLbku7bkuro8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjogTHVjeSB5b25nPGJyPg0KJmd0OyA8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjoNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LXh1LW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PC9hPjs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPuS4u+mimDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlp bmcgbmV0d29yazxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2UgZG9uJ3QgbWl4IHVwIHRoaW5n cy4gVGhlIE1QTFMgcHJvdG9jb2wgZGVzaWduIEkgYWdyZWUgbXVzdCBiZSBkb25lIGJ5PGJyPg0K Jmd0OyBNUExTIFdHLiBCdXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91ciBwcm9wb3NhbCBt ZWV0cyB0aGUgbmV0d29yazxicj4NCiZndDsgdmlydHVhbGl6YXRpb24gcmVxdWlyZW1lbnRzLjxi cj4NCjxicj4NCkNhbiB5b3UgdGVsbCB1cyB3aGVyZSBNUExTLWluLUdSRS9JUCBbUkZDNDAyM10g YW5kIG90aGVyIE1QTFMgb3ZlciBJUCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMgaGF2ZSBiZWVu IGRpc2N1c3NlZCBiZWZvcmU/PGJyPg0KPGJyPg0KU2luY2UgTVBMUy1pbi1VRFAgaXMganVzdCBp bnRlbmRlZCB0byBiZSB1c2VkIGluIHRoZSBzY2VuYXJpb3Mgd2hlcmUgTVBMUy1pbi1HUkUvSVAg aGFzIGJlZW4gdXNlZCBhbmQgaXMgdG8gYmUgdXNlZCwgTVBMUy1pbi1VRFAgc2hvdWxkIGJlIGRp c2N1c3NlZCBpbiB0aGUgc2FtZSBXRyB3aGVyZSBNUExTLWluLUdSRS9JUCBoYXMgYmVlbiBkaXNj dXNzZWQuPGJyPg0KPGJyPg0KWGlhb2h1PGJyPg0KPGJyPg0KJmd0OyBUaGUgTlZPMyB0YXNrIGlz IHRvIGRvY3VtZW50IHRoZSBpc3N1ZXMsIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrIGZvcjxi cj4NCiZndDsgTnZPMy4gVGhlbiBpZiBNUExTIG92ZXIgSVAgbG9va3MgbGlrZSBhIHN1aXRhYmxl IHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlPGJyPg0KJmd0OyByZXF1aXJlbWVudHMgc3VjaCBhcyB0 aGUgc2NhbGUsIG1vYmlsaXR5LCBldGMsIHRoZW4gdGhleSB3aWxsIGFzayBNUExTIFdHIGZvcjxi cj4NCiZndDsgcHJvdG9jb2wgZGVzaWduLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTbyBiZWZvcmUg cHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJIHRoaW5rIHlvdSBzaG91bGQgdGFrZSBpdCB0byBOVk8z IFdHIGFuZDxicj4NCiZndDsgY29udmluY2UgdGhlbSB0aGlzIHNvbHV0aW9uIG1lZXRzIHRoZWly IHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZSBkb24n dCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0aW9ucyBmb3IgdGhlIHNhbWUg cHJvYmxlbSwgZG88YnI+DQomZ3Q7IHdlPzxicj4NCiZndDsgPGJyPg0KJmd0OyAtU2hhaHJhbTxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQom Z3Q7IFNoYWhyYW08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBEZWMgMjAsIDIw MTIsIGF0IDg6NTYgQU0sICZxdW90O0x1Y3kgeW9uZyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bHVjeS55b25nQGh1YXdlaS5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBOZXR3b3JrIHZpcnR1 YWxpemF0aW9uIG92ZXJsYXkgaXMgZGlzY3Vzc2VkIHVuZGVyIG52bzMgV0cuIFRoaXMgZG9lcyBu b3Q8YnI+DQomZ3Q7IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJvdG9j b2wgZm9yIGEgdW5kZXJseWluZyBuZXR3b3JrIG9yIGE8YnI+DQomZ3Q7IG5ldyBwcm90b2NvbCBm b3IgYSBvdmVybGF5IG5ldHdvcmsuIEluIGZhY3QsIHBlb3BsZSB0aGVyZSBhaW0gb24gbGV2ZXJh Z2U8YnI+DQomZ3Q7IHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29tcGxpc2ggdGhl bS4gSU1POiB0aGVzZSBleHBhbnNpb25zIG9uIGFuPGJyPg0KJmd0OyBleGlzdGluZyBzdGFuZGFy ZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhlIHByb3RvY29sIFdHIGdyb3Vw LCBpdDxicj4NCiZndDsgc2hvdWxkIG5vdCBnaXZlIG52bzMgV0cgZnJlZSByaWdodCB0byBlbmhh bmNlIHRoZXNlIHByb3RvY29scy4gRm9yIGEgYnJhbmQ8YnI+DQomZ3Q7IG5ldyBwcm90b2NvbCBm b3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5LCBudm8zIFdHIG1heSBiZSB0aGUgcGxh Y2UgdG88YnI+DQomZ3Q7IHN0YXJ0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBMdWN5 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgJmd0OyZndDsgRnJvbTogU2hhaHJhbSBEYXZhcmkgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmFyaUBi cm9hZGNvbS5jb208L2E+XTxicj4NCiZndDsgJmd0OyZndDsgU2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDIwLCAyMDEyIDEwOjM0IEFNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUbzogTHVjeSB5b25nPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBDYzogU2hhbmUgQW1hbnRlOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXh1 LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHNAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVy bHlpbmcgbmV0d29yazxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE5ldHdv cmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBtdXN0IGJlIGRpc2N1c3NlZCBhbmQgY29uc2VudGVk Jm5ic3A7IGluIE5WTzM8YnI+DQomZ3Q7ICZndDsmZ3Q7IFdHLjxicj4NCiZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTaGFocmFtPGJy Pg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9u IERlYyAyMCwgMjAxMiwgYXQgNzozOSBBTSwgJnF1b3Q7THVjeSB5b25nJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5sdWN5Lnlv bmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IEkgdW5kZXJzdGFuZCBvcGVyYXRvciBjb25jZXJuIG9uIGEgbmV3IGVuY2Fw c3VsYXRpb24gdG8gYW4gZXhpc3Rpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBIb3dldmVyLCBNUExTLWlu LVVEUCBkb2VzIG5vdCBhaW0gb24gY2hhbmdpbmcgZXhpc3RpbmcgU1AgSVAvTVBMUzxicj4NCiZn dDsgJmd0OyZndDsgbmV0d29yayBhdCBhbGwuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgTVBMUy1p bi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVyIHRvIGJlIGRlY291cGxlZCBmcm9t IE1QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNlcnZlciBsYXllciBhbmQgdXNlIE1QTFMgY2xpZW50 IGxheWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBhIHVuZGVybHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBTdWNoIGFwcGxpY2F0aW9uIGlz IGZvciBEQy4gWW91IG1heTxicj4NCiZndDsgJmd0OyZndDsgYXJndWUgd2h5IG5vdCB1c2UgdGhl IEdSRSB3aGljaCBpcyBmb3IgTVBMUyBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmc8YnI+DQom Z3Q7ICZndDsmZ3Q7IG5ldHdvcmsuIFdlIGhhdmUgcG9pbnRlZCBvdXQgaW4gdGhlIGRyYWZ0IHRo YXQgY3VycmVudCByb3V0ZXJzIGluIERDPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBiYXJlbHkgc3VwcG9y dCBHUkUgYmFzZWQgbG9hZCBiYWxhbmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkgdXNl ZDxicj4NCiZndDsgJmd0OyZndDsgaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRlcnMg aW4gREMgcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBiYWxh bmNpbmcgbm93Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg RnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQIGVuY2Fwc3VsYXRpb24g aGFzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhZHZhbnRhZ2Ugb3ZlciBHUkUgZW5jYXBzdWxhdGlvbiB0 b28uIEluIFVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgZnJhbWU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGhl YWRlciBkZWNvdXBsZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29yayBjbGVhcmx5 LCBpLmUuIG91dGVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVy LiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFkZXIsIHdoaWNoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1 bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBvbmx5LiBIb3dldmVyLCBHUkUgaGVhZGVyIGhhcyB0aGUg ZmllbGRzIGZvcjxicj4NCiZndDsgJmd0OyZndDsgdGhlIG92ZXJsYXkgbmV0d29yayBhbmQgdXNl cyB0aGUga2V5IGZpZWxkIGZvciBmbG93IGVudHJvcHkuIEZvciBsb2FkPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBiYWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBH UkUgaGVhZGVyIHRvby4gSW48YnI+DQomZ3Q7ICZndDsmZ3Q7IHNob3J0LCBHUkUgdGllcyB0aGUg b3ZlcmxheSBhbmQgdW5kZXJseWluZyBuZXR3b3JrcyB0b2dldGhlci4gU2luY2UgaXQ8YnI+DQom Z3Q7ICZndDsmZ3Q7IGhhcyBub3QgdXNlZCBhIGxvdCwgcGVvcGxlIGFyZSBub3QgYXdhcmUgb2Yg dGhlIGRpc2FkdmFudGFnZSBvZiBzdWNoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb3VwbGluZy48YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFzIHRoZSBpbmR1c3Ry eSBtb3ZlcyB0b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGFuZDxicj4NCiZn dDsgJmd0OyZndDsgZGVjb3VwbGVzIG92ZXJsYXkgbmV0d29ya3MgZnJvbSB0aGUgdW5kZXJseWlu ZyBuZXR3b3JrLiBBIGNsZWFyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzZXBhcmF0aW9uIG9mIG92ZXJs YXkgaGVhZGVyIGFuZCB1bmRlcmx5aW5nIGhlYWRlciBpcyBhICZxdW90O01VU1QmcXVvdDsgaW4g bXk8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9waW5pb24uIElmIHdlIGNvdW50IEdSRSBhcyB0aGUgb3Zl cmxheSBoZWFkZXIsIHRoZW4gZm9yIElQdjQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IHVuZGVybHlpbmcg bmV0d29yaywgdGhlcmUgaXMgbm8gZmllbGQgZm9yIHRoZSBmbG93IGVudHJvcHkuIFRoaXMgaXMg dGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVuY2Fwc3Vs YXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZzxicj4NCiZndDsgJmd0OyZndDsgbmV0 d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkgbmV0d29yayBiZXNpZGUg TVBMUyBjbGllbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGxheWVyIChlLmcuIFZYTEFOLCBMMlRQLWlu LVVEUCwgZXRjKS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVEUCBpbnN0ZWFkLiBZZXMsIE1Q TFMtaW4tTDJUUC08YnI+DQomZ3Q7ICZndDsmZ3Q7IGluLVVEUCBzY2hlbWEgYWxzbyBwcm92aWRl cyBhIG92ZXJsYXkgKEwyVFApIGFuZCB1bmRlcmx5aW5nIChJUCk8YnI+DQomZ3Q7ICZndDsmZ3Q7 IG5ldHdvcmsgZGVjb3VwbGluZy4gTDJUUCBwcm90b2NvbCAocmZjMzkzMSkgcHJvdmlkZXMgZ29v ZCBzZWN1cml0eTxicj4NCiZndDsgJmd0OyZndDsgbWVjaGFuaXNtIGFuZCBoYXMgdGhlIGVtYmVk ZGVkIGNvbnRyb2wgZnVuY3Rpb24gdG9vLiBUaGVyZWZvcmUsPGJyPg0KJmd0OyBzb21lb25lPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBjYW4gdXNlIGl0IGZvciBNUExTIGNsaWVudCBsYXllciBvdmVyIElu dGVybmV0LiBUbyBoYXZlIE1QTFMgY2xpZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBsYXllciBvdmVy IGFuIElHUCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWluLUwyVFAtaW4tVURQIGlzIGE8 YnI+DQomZ3Q7ICZndDsmZ3Q7IG92ZXJraWxsIGFuZCB0b28gY29tcGxleC4gSGVyZSB3ZSBuZWVk IGEgc2NoZW1hIHRvIHN1cHBvcnQgSUdQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1bmRlcmx5aW5nIHRy YW5zcG9ydCB3aXRob3V0IHRvdWNoaW5nIGEgb3ZlcmxheSBoZWFkZXIuIFVEUDxicj4NCiZndDsg Jmd0OyZndDsgZW5jYXBzdWxhdGlvbiBpcyB0aGUgYmVzdCBjaG9pY2UgdG8gYWNjb21wbGlzaCB0 aGF0IGFuZCBtaW5pbWl6ZSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNoYW5nZXMgb24gZXhpc3Rp bmcgcm91dGVycywgZS5nLiBjaGFuZ2UgYXQgZWRnZSByb3V0ZXJzLCBubyBjaGFuZ2Ugb248YnI+ DQomZ3Q7ICZndDsmZ3Q7IHRyYW5zaXQgcm91dGVycy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgTHVj eTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBYdXhpYW9odSBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6 IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA0OjE0IEFNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFRvOiBTaGFuZSBBbWFudGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgQ2M6IFJv Z2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tPGJyPg0KJmd0OyAm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dWRwQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cgdG8gdHJhbnNwb3J0IE1QTFMg b3ZlciBVRFAgdHVubmVsczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIgY29tbWVudHMgYW5k IHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBOb3RlOiBJIGNoYW5nZWQgdGhlIHN1YmplY3Qg bGluZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+6YKu5Lu25Y6f5Lu2PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4tLS0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46IFNoYW5lIEFtYW50ZSBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQiIHRhcmdldD0iX2JsYW5rIj5zaGFu ZUBjYXN0bGVwb2ludC5uZXQ8L2E+XTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5Y+R6YCB5pe26Ze0PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46IDIwMTI8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjEyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4xOTwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+DQogMjI6Mzg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+OiBYdXhpYW9odTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5oqE6YCBPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46IFJvZ2VycywgSm9zaDsgU2hhaHJh bSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51ZHBAdG9v bHMuaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuS4u+mimDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+OiBSZTogW21wbHNdIHBvbGwg dG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBtcGxzLWluLXVkcCBhbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWGlhb2h1LDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIERlYyAx OCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFv aHVAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5jb208L2E+Jmd0 Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLTwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5Y+R 5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj46IFNo YW5lIEFtYW50ZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQi IHRhcmdldD0iX2JsYW5rIj5zaGFuZUBjYXN0bGVwb2ludC5uZXQ8L2E+XTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjogMjAxMjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjE5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAxMTo1ODxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij7mlLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjogUm9nZXJzLCBKb3NoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuaKhOmAgTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+OiBTaGFocmFtIERhdmFyaTsgWHV4aWFvaHU7IGRy YWZ0LXh1LW1wbHMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzp1ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51ZHBAdG9vbHMuaWV0Zi5vcmc8 L2E+Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N Cm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7kuLvpopg8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjogUmU6IFttcGxzXSBw b2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS08YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgbXBscy1pbi11ZHA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgd29ya2lu ZyBncm91cCBkb2N1bWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTgsIDIwMTIsIGF0IDg6NTAgQU0sICZxdW90O1Jv Z2VycywgSm9zaCZxdW90Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9zaC5yb2dl cnNAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkg c2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gdGhp czxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWRkcmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICYjNDM7MS4mbmJzcDsgUGxlYXNlIGRvIG5vdCBkZWZpbmUg eWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSUVURjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbHJlYWR5IHN0YW5kYXJkaXplZCBNUExT IG92ZXIgR1JFLiZuYnNwOyBUaGUgSUVURiBoYXMgYWxzbzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBzdGFuZGFyZGl6ZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1QTFM8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3ZlciBMMlRQdjMvVURQL0lQLCB3 aGljaCBoYWQgc2VlbiBzb21lIGRlcGxveW1lbnQgaW4gYXQgbGVhc3Q8YnI+DQomZ3Q7ICZndDsm Z3Q7IG9uZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdmVyeTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYXJnZSBvcGVyYXRvciBuZXR3b3JrIHRoYXQgSSdtIGF3 YXJlIG9mIHRvIHN1cHBvcnQgY2FycmlhZ2Ugb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg TDNWUE4gb3Zlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSVAtb25seSBuZXR3b3JrLjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SGkgU2hhbmUsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJl IGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgSVAgaW4gYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXN0IG9uZSwgdmVy eSBsYXJnZSBvcGVyYXRvciBuZXR3b3JrLiBUaGlzIGZhY3QgbXVzdCBiZSB2ZXJ5PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVhYmxlIHRvIHRob3NlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlv biBvZiBNUExTIG92ZXIgSVAgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdG9kYXkncyBT UDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29ya3MuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgU2VlOiBSRkMncyA0NDU0LCA0NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtOT1RFOiB0aGUgZGF0ZXMg dGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aW1lZnJhbWUhXTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g VlBMUyB0aGF0IHNheSB0aGF0IFZQTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbWF5IGJl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhcnJpZWQgb3ZlciBMMlRQ djM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgQW5kLCBoZXJl J3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0IG9uZSB2ZW5kb3IgaGFzPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJUFZQTidzIG92ZXIgTDJUUHYzOjxicj4NCiZndDsgJmd0OyZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3MvMTJfMHMvZmVhdHVy ZS9ndWlkZS9jc2dsM3Zwbi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmNpc2Nv LmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJlL2d1aWRlL2NzZ2wzdnBuLmh0bWwgPC9h Pjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1h dGlvbi4gQXMgbWVudGlvbmVkIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgZHJh ZnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFORCBvdGhlciBkcmFmdHMsIHRoZSBt ZWNoYW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9uIG9uPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2Vzc2lvbjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSUQgZmllbGQgaW4gdGhlIEwyVFB2MyBoZWFkZXIgb3IgdGhlIEtl eSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciBhczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBk ZWZpbmVkIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbUkZDIDU2NDBdIGlzIG5v dCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg RldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwg aW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVxdWVzdGluZyBhIGNvcmU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJvdXRlciB2ZW5kb3IgdG8gc3VwcG9ydCBjaGFuZ2VzIHRv IHRoZSBpbnB1dC1rZXlzIHVzZWQgaW4gaGFzaDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBj YWxjdWxhdGlvbnMgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9leGlzdGluZ18g aGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0 b3JzIGFyZSBzYXZ2eTxicj4NCiZndDsgJmd0OyZndDsgZm9sa3M8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kIHRo ZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuJm5ic3A7IEFz IGE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVzdWx0LCB0aG9zZTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3Qg dGVjaG5pY2FsbHkgcG9zc2libGUgaW4gdGhpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBy ZWdhcmQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaHVzLCBpdCBtYXkgYmUgYSBx dWVzdGlvbiBvZiAmcXVvdDttZXRob2RzJnF1b3Q7IG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVp cjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBIVzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVx dWlwbWVudCB0bzxicj4NCiZndDsgJmd0OyZndDsgYWNoaWV2ZTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyB0aGVpcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnVzaW5lc3MgZ29h bHMuJm5ic3A7IDotKSZuYnNwOyBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3Nh cnkgLi4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzZWU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg YmVsb3cuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IENvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBleHBsYWluIGhvdyB0byBtYWtlIHRoZSBhYm92 ZSBjaGFuZ2UgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRVhJU1RJTkcgaGFyZHdhcmUg b2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gY29udHJhc3QsIG1vc3Qg ZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBhbHJlYWR5IGNhcGFibGUgb2Y8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgYmFsYW5jaW5nIElQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVE UCBwYWNrZXRzLjxicj4NCiZndDsgJmd0OyZndDsgQnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgdXNpbmcgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNUExTLWluLVVEUCBl bmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmc8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2FwYWJpbGl0eSBvZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRo b3V0IHJlcXVpcmluZyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2hhbmdlIHRvPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBtb3Rp dmF0aW9uIG9mIHRoaXMgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5 IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBNUExTL0wyVFB2Mywgd2hpY2g8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVzZXMg VURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHlv dSBwcmVmZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLTxicj4NCiZndDsgJmd0OyZndDsgVURQ PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RlYWQgb2YgTVBMUy1pbi1VRFAsIHJpZ2h0 Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAo PykgY2hhbmdlIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFJGQyAzOTMxLDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hpY2ggd291bGQgYWxsb3cgdGhlIGNvbm5lY3Rpb24g dXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBwYWNrZXRzKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdXNlIGEgdmFy eWluZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBiYXNlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBvbiBhIGhhc2g8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJl dHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlcXVp cG1lbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaW4gYW48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IElQLW9ubHkgY29yZS4mbmJzcDsgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVu dGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIgb2ZmPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGp1 c3QgdXNpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSAmcXVvdDtTZXNzaW9u IElEJnF1b3Q7IChhbmQgJnF1b3Q7Q29va2llJnF1b3Q7KSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlw bGV4b3IgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRlPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQg TDJUUCBDb250cm9sIENoYW5uZWwuJm5ic3A7IEluIGZhY3QsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGl0J3Mgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGVhciB0byBt ZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkgL2FscmVhZHkvIGRvIHRoaXMsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2luZyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZxdW90O2NoZWNrJnF1b3Q7IG9uIHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1 bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGJlYXV0eSBvZiB0aGUgYWJvdmUgYXBwcm9h Y2ggaXM6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBJIHdvdWxkIHRoaW5rIHRo YXQgdGhlIGFib3ZlIGlzIG1vc3QgbGlrZWx5IGEgY2hhbmdlIHRoYXQgaXM8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgbGltaXRlZCB0byB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZxdW90O2NvbnRyb2wgY2hhbm5lbCZxdW90OyAoc29mdHdhcmUpIG9mIGV4aXN0aW5nIEwy VFAgZW5kLXN5c3RlbTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbnMu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNr d2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2Mzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb25zLiZuYnNwOyAoTDJUUHYzIGltcGxlbWVudG9ycyB3 b3VsZCBuZWVkIHRvIGNvbW1lbnQgb248YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoYXQpLjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJTUhPLCBubyBt YXR0ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCZuYnNwOyB0aGUgaGFy ZHdhcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBF IHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUuZy4sIGluZ3Jlc3MgUEUgcm91dGVycyBu ZWVkIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmaWxsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFk ZXJzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgMikgVGhlcmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBi eSB1c2luZyAmcXVvdDtTZXNzaW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElEJnF1b3Q7 IGFuZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7Q29va2llJnF1b3Q7IGZp ZWxkcyB0byBlbnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGU8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZWQgc2Vzc2lvbi4mbmJzcDsgUXVvdGlu ZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgLS0tc25pcC0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgTDJU UHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzItYml0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNlc3Npb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IElEIGluIHRoZSBMMlRQdjMgZGF0YSBoZWFkZXIuJm5ic3A7IFdoZW4g cHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7IChkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFs IGNoZWNrIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbnN1cmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IHRoYXQgYW4gYXJyaXZpbmcgcGFja2V0IGlzIGludGVuZGVkIGZvciB0 aGUgaWRlbnRpZmllZCBzZXNzaW9uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsgVGh1cywgdXNlIG9mIGEgQ29va2llIHdpdGggdGhlIFNlc3Npb24gSUQgcHJvdmlkZXMgYW4g ZXh0cmE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZ3VhcmFudGVlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVy Zm9ybWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsgU2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLXNuaXAtLS08YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IC4uLiBpbiByZWdhcmQgdG8gdGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBr bm93IHRoZSBTZWN1cml0eSBBcmVhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmb2xrczxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBoYXZlLCBpbiB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHBhc3QsIGhhZCAvc3Vic3RhbnRpYWwvIGNvbmNlcm5zIGFib3V0IGVuY2Fwc3VsYXRpb24g b2YgTVBMUyBvdmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJUDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyB0cmFuc3BvcnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBmYWN0LCB0 aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQgaW4gU2VjdGlvbiA3LjYsICZxdW90O1NlY3VyaXR5JnF1 b3Q7LCBvZjxicj4NCiZndDsgJmd0OyZndDsgUkZDPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IDQ2NjUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoVGhlcmUncyBsaWtlbHkgc2lt aWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhhdCB1c2UgTVBMUyBmb3I8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0KS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFdoaWxlIEknbSBub3Qgc3VyZSB0aGF0IFNlY3VyaXR5IEFyZWEgZm9sa3MgcGF5IG11Y2gg YXR0ZW50aW9uIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRhaWx5IHRyYWZmaWMgb248 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdCwg SSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGw8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgYXJpc2UgaWYvd2hlbiB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0 aGUgcmVhc29uIGZvciB5b3VyIHByZWZlcmVuY2Ugb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7IE1QTFMt PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBo YXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdDxicj4NCiZndDsgJmd0OyZndDsg aXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxh aW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXI8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHRoYW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTVBMUy1pbi1MMlRQIGluIHByYWN0aWNl Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBC ZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMykgRmluYWxs eSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQ8YnI+DQom Z3Q7ICZndDsmZ3Q7IGltcGxlbWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBMMlRQLCBm b3I8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHR1bm5lbGluZyBvZiBNUExTL0lQLCBh bmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG88YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgc3VwcG9ydDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTVBMUy9V RFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC1zaGFuZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWGlhb2h1PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQg Zm9yIE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3b3Vs ZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBoYXZlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiZWVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vcmUg d2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExT PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG92ZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEdSRSBvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNUExT IG92ZXIgTDJUUHYzLiZuYnNwOyAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkp LiZuYnNwOyBJPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3b3VsZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBub3RlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMg ZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNldmVyYWws PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByYWN0aWNhbDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvcGVyYXRpb25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdv aW5nIHdpdGggbmF0aXZlIE1QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gTVBMUyBGYXN0IFJlLVJv dXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gTVBMUyBUcmFmZmlj IEVuZ2luZWVyaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC4uLiB0 byBuYW1lLCBidXQgYSBmZXcuJm5ic3A7IFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNv bXBlbGxpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZ3VtZW50czxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byAndXBncmFkZScgbmV0d29yayBIVyB0 byBzdXBwb3J0IE1QTFMgZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IC1zaGFuZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLUpvc2g8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gMTIvMTgvMTIgMTI6MzEg QU0sICZxdW90O1NoYWhyYW0gRGF2YXJpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2YXJp QGJyb2FkY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmFyaUBicm9hZGNvbS5jb208L2E+Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQ IGlzIGxlZ2FjeSBhbmQgdGhlcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGlzPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IG5vIG5lZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB0byBpbXByb3ZlIGl0Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBTaGFocmFtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIERlYyAxNywgMjAxMiwg YXQgODowMiBQTSwgJnF1b3Q7WHV4aWFvaHUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhp YW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaGFocmFtLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJv dmlkZSBhIE1QTFMtb3Zlci1JUDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBlbmNhcHN1bGF0 aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1l dGhvZCB3aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRv PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRob3NlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVp cmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgdHJhZmZpYzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQ LCBOVkdSRTxicj4NCiZndDsgJmd0OyZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBWWExBTjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhYnNvbHV0ZWx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGJlbGlldmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFm ZmljPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFjcm9zcyBJUDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrcyBhbmQgdGhlcmVmb3Jl IHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBNUExTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBv dmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBi ZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBwbGVhc2U8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2F5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzby48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnkgdGhl IHdheSwgaXQgc2VlbXMgdGhpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCjwvYT48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGp1c3QgdGhl IHJpZ2h0IHRocmVhZCBzdWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmd1bWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNl ZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNl bnRlcnMpLiBJPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzdXJwcmlzaW5nbHkgc2lsZW50PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRpbGwgbm93Ljxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaWdoLCBJIGRpZG4ndCBpbnRl bmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7p gq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pi0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7lj5Hku7bkuro8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjoNCjxhIGhyZWY9Im1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7ku6M8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7ooag8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRGF2YXJpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj7lj5HpgIHml7bp l7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjogMjAxMjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjE1PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAxMzozNDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+5pS25Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj46IExvYSBBbmRlcnNzb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPuaKhOmA gTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Og0KPGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0i bWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxh IGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+5Li76aKYPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij46IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2U8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0 LXh1LW1wbHMtaW4tdWRwIGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IHN1cHBvcnQg dGhpcyBkcmFmdCBzaW5jZSBpdCBoYXMgbm8gYXBwbGljYXRpb24gaW48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgdG9kYXknczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbW9kZXJuIG1ldHJvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgY29yZSwgd2hlcmUgTVBMUyBpcyBkb21p bmFudCwgYW5kIGl0cyBvbmx5IHByYWN0aWNhbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBh cHBsaWNhdGlvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaW4gaW4gZGF0YTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgY2VudGVyLCB3aGljaCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBv dGhlciBzb2x1dGlvbnMgc3VjaCBhczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBOVkdSRTxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBWWExBTi48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJdCBzZWVtcyB0aGUgYXV0aG9ycyBh cmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBzZWxlY3Rpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHByb2Nlc3M8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ5IGFkdmFuY2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWdh cmRzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgU2hhaHJhbTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhy ZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgV29ya2luZyBncm91cCw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMgaXMgdG8gc3RhcnQgYSAmcXVvdDt0d28gd2Vl ayZxdW90OyBwb2xsIG9uIGFkb3B0aW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4g TVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24g dGhpcyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdpdGg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgb25lIHdlZWsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBz dXBwb3J0KSB0byB0aGUgbXBsczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ya2lu Zzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRlY2huaWNhbDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3U8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgdGhpbmsgdGhhdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0 ZWQgYXMgYSB3b3JraW5nIGdyb3VwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvY3VtZW50 Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIG9uZSBJ UFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvPC9hPiAuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbGwgdGhlIGFjdGl2ZSBjby1hdXRo b3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVy IElQUiBjbGFpbXMgdGhhbiB0aG9zZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhbHJlYWR5 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZGlzY2xvc2VkLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVu dCB0aGF0IHdlIHVzZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgSVBSPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgcG9sbCk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJzaGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMg b25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBo YXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkaXNjb250aW51ZWQgYWxsIGludGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRp bmcgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGF1dGhvciB0ZWFtPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXM8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgdHJpZWQgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1l YW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb248YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJUFI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwb2xsLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGhhdmUgaGFkIG5vIHN1Y2Nl c3MgaW4gdGhpcy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byBy ZW1vdmUgTWFyc2hhbGwgYXMgYTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvLWF1dGhvci48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC9Mb2E8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAobXBscyB3ZyBjby1j aGFpcik8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBMb2EgQW5kZXJzc29uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg ZW1haWw6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5sb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTciBTdHJhdGVneSBhbmQg U3RhbmRhcmRzIE1hbmFnZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8 L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgRXJpY3Nzb24gSW5jJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBob25l OiAmIzQzOzQ2IDEwIDcxNzxicj4NCiZndDsgNTI8YnI+DQomZ3Q7ICZndDsmZ3Q7IDEzPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7NDYgNzY3IDcyIDkyPGJyPg0KJmd0OyAxMzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXBscyBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyA8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMgPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIEUtbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBDYWJsZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFs LCBvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzdWJqZWN0IHRvPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJu ZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IHNvbGVseSBmb3I8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGFyZSBub3QgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhbnk8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGRpc3NlbWluYXRpb24sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJl bGF0aW9uIHRvIHRoZTxicj4NCiZndDsgJmd0OyZndDsgY29udGVudHM8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgb2YgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB1bmxhd2Z1bC4gSWYgeW91PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBpbW1lZGlhdGVseSBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBF LW1haWwgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFueSBwcmludG91dC48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBtcGxzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzDQo8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGll dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPC9hPjxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCjwvYT48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t cGxzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBsczwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98Aszxeml525mbschi_-- From xuxiaohu@huawei.com Sun Dec 23 18:39:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8900621F8BD1 for ; Sun, 23 Dec 2012 18:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9KIkAbKj1Cx for ; Sun, 23 Dec 2012 18:39:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7B21F8A7B for ; Sun, 23 Dec 2012 18:39:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT69710; Mon, 24 Dec 2012 02:39:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 02:38:55 +0000 Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 10:39:10 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.01.0323.003; Mon, 24 Dec 2012 10:38:59 +0800 From: Xuxiaohu To: Pat Thaler , Lucy yong , "Andrew G. Malis" , Shane Amante Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3Olzo1M6JwDPXkycxIud0O1KBJgeLvSAgADLHACAAKzhwIAABiEAgANl/ICAAA9vAIAAFuuAgAQKz2A= Date: Mon, 24 Dec 2012 02:38:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A99D@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> 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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A99Dszxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:39:16 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A99Dszxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGF0LA0KDQpUaGlzIE1QTFMtaW4tVURQIHRlY2hub2xvZ3kgaXMgaW50ZW5kZWQgdG8gYmUg dXNlZCBpbiB0aGUgc2NlbmFyaW9zIHdoZXJlIGV4aXN0aW5nIE1QTFMgb3ZlciBJUCB0ZWNobm9s b2dpZXMgKGUuZy4sIE1QTFMgb3ZlciBHUkUpIGhhdmUgYmVlbiB1c2VkIGFuZCBhcmUgdG8gYmUg dXNlZC4gRGF0YSBjZW50ZXIgaXMganVzdCBvbmUgc2NlbmFyaW8gYnV0IG5vdCB0aGUgb25seSBv bmUuDQoNClhpYW9odQ0KDQq3orz+yMs6IFBhdCBUaGFsZXIgW21haWx0bzpwdGhhbGVyQGJyb2Fk Y29tLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMtTCMjLI1SA0OjQ5DQrK1bz+yMs6IEx1Y3kgeW9u ZzsgQW5kcmV3IEcuIE1hbGlzOyBTaGFuZSBBbWFudGUNCrOty806IGRyYWZ0LXh1LW1wbHMtaW4t dWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZw0K1vfM4jogUkU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8g bWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQN Cg0KTHVjeSwNCg0KSWYgeW91ciBkcmFmdCBpcyBpbnRlbmRlZCB0byBhZGRyZXNzIHRoZSBOVk8z IHJlcXVpcmVtZW50cywgdGhlbiBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiBOVk8zIGFsb25n IHdpdGggdGhlIG90aGVyIHByb3Bvc2VkIHNvbHV0aW9ucyByYXRoZXIgdGhhbiBieXBhc3Npbmcg dGhhdCBwcm9jZXNzIGJ5IHN1Ym1pdHRpbmcgaXQgdG8gTVBMUy4NCg0KVGhlIE5WTyBjaGFydGVy IHJlcXVpcmVzIHRoYXQgdGhlIHByZWxpbWluYXJ5IGFuYWx5c2lzIHdvcmsgYmUgY29tcGxldGVk IGJlZm9yZSBjb21wbGV0aW5nIHNvbHV0aW9uczoNClRoZSBOVk8zIFdHIHdpbGwgd3JpdGUgdGhl IGZvbGxvd2luZyBpbmZvcm1hdGlvbmFsIFJGQ3MsIHdoaWNoDQptdXN0IGhhdmUgY29tcGxldGVk IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGJlZm9yZSByZWNoYXJ0ZXJpbmcgY2FuIGJlDQpjb25z aWRlcmVkOg0KDQpQcm9ibGVtIFN0YXRlbWVudA0KRnJhbWV3b3JrIGRvY3VtZW50DQpDb250cm9s IHBsYW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KRGF0YSBwbGFuZSByZXF1aXJlbWVudHMgZG9j dW1lbnQNCk9wZXJhdGlvbmFsIFJlcXVpcmVtZW50cw0KR2FwIEFuYWx5c2lzDQoNCkRyaXZlbiBi eSB0aGUgcmVxdWlyZW1lbnRzIGFuZCBjb25zaXN0ZW50IHdpdGggdGhlIGdhcCBhbmFseXNpcywN CnRoZSBOVk8zIFdHIG1heSByZXF1ZXN0IGJlaW5nIHJlY2hhcnRlcmVkIHRvIGRvY3VtZW50IHNv bHV0aW9ucw0KY29uc2lzdGluZyBvZiBvbmUgb3IgbW9yZSBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRp b25zIGFuZA0KY29udHJvbCBwbGFuZSBwcm90b2NvbHMgYXMgYXBwbGljYWJsZS4NCg0KQmFzZWQg b24gdGhlIE5WTzMgY2hhcnRlciwgaXQgaXMgcHJlbWF0dXJlIHRvIGNvbnNpZGVyIHNvbHV0aW9u cyBhdCB0aGlzIHBvaW50IGFuZCBzdWdnZXN0aW5nIHRoYXQgc29tZXRoaW5nIHNob3VsZCBnbyBm b3J3YXJkIGJlY2F1c2UgaXQgc3VwcG9ydHMgb25lIGl0ZW0gaW4gYSBkcmFmdCBOVk8zIHJlcXVp cmVtZW50cyBkb2N1bWVudCBpcyBub3QganVzdGlmaWVkLg0KDQpSZWdhcmRzLA0KUGF0DQoNCkZy b206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAx MToyNyBBTQ0KVG86IEFuZHJldyBHLiBNYWxpczsgU2hhbmUgQW1hbnRlDQpDYzogZHJhZnQteHUt bXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUg c3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2luZyBncm91 cCBkb2N1bWVudA0KDQpBbmR5LA0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1u dm8zLWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0DQoNCiAgMy4zLjIuMS4gTEFHIGFuZCBF Q01QDQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVhc29ucywgbXVsdGlwYXRoIG92ZXIgTEFH IGFuZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAgIHN1cHBvcnRlZC4NCg0KICAgICAgIExB RyAoTGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUgODAyLjFBWC0yMDA4XSBhbmQgRUNNUCAo RXF1YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFyZSBjb21tb25seSB1c2VkIHRlY2huaXF1 ZXMgdG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvZiBtaWNyb2Zsb3dzIG92ZXIg YSBzZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIgYXQNCiAgICAgICBMYXllci0yIChMQUcp IG9yIExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBsb3llZCBoYXJkd2FyZQ0KICAgICAgIGlt cGxlbWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNlcyBhIGhhc2ggb2YgdmFyaW91cyBmaWVs ZHMgaW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24gKG91dGVybW9zdCkgaGVhZGVyKHMpIChl LmcuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQogICAgICAgYWRkcmVzc2VzIGZvciBub24t SVAgdHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMsDQogICAgICAg TDQgcHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBldGMp Lg0KICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBkZXBsb3llZCBmb3IgdGhlIHVuZGVybGF5 IG5ldHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qgb2Z0ZW4gdW5hd2FyZSBvZiB0aGUgY2Fy cmllZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBwYWNrZXRzDQogICAgICAgdHJhbnNtaXR0 ZWQgYnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBwZXJmb3JtIGZpbmUtZ3JhaW5lZCBsb2Fk LQ0KICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQgRUNNUCBwYXRocyBpbiB0aGUgdW5kZXJs eWluZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1bGF0aW9uIE1VU1QgcmVzdWx0IGluIHN1 ZmZpY2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwNCiAgICAgICBwYXRocyB0aHJvdWdoIHNl dmVyYWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkgaW5mb3JtYXRpb24gTUFZIGJlDQogICAg ICAgaW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5IGhlYWRlciBvciB1bmRlcmxheSBoZWFk ZXIuDQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZhbmNlZCBzb2x1dGlvbiBpbiB0aGlzIHNw YWNlLg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOltt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxp cw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMjozMiBQTQ0KVG86IFNoYW5lIEFt YW50ZQ0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdl IGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2lu ZyBncm91cCBkb2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBlYXJsaWVyIG9uIHRoaXMgZHJhZnQs IGFuZCBsaWtlIFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCBvZiBpdHMgdXRpbGl0eS4gSSBz dGlsbCBkb24ndCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkgYXQgYWxsIGZvciBjb3JlIGJhY2ti b25lIG5ldHdvcmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMsIG9yIGlmIHlvdSBtdXN0IHR1bm5l bCBNUExTIG92ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVuY2Fwc3VsYXRpb25zLiBSZWdhcmRp bmcgZGF0YSBjZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNzIEkgY291bGQgYmUgY29udmluY2Vk LCBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1c3RpZmljYXRpb24gaW4gdGhlIGZv cm0gb2YgcmVxdWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNvdWxkIG9ubHkgYmUgbWV0IGJ5IHRo aXMgZHJhZnQuDQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2VkLCBEZWMgMTksIDIwMTIgYXQgOToz OCBBTSwgU2hhbmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNh c3RsZXBvaW50Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpPbiBEZWMgMTgsIDIwMTIsIGF0IDEx OjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IFNoYW5lIEFt YW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9p bnQubmV0Pl0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KPj4gytW8/sjLOiBS b2dlcnMsIEpvc2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUt bXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRv b2xzLmlldGYub3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc+DQo+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0 byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQNCj4+DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBK b3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUu Y29tPj4NCj4+IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRv IG5vdCBzZWUgdGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0KPj4+IGFkZHJlc3NlcyBpbiBwcmFj dGljZSBhbnkgbG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFu b3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBUaGUgSUVURg0KPj4gYWxyZWFkeSBz dGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvIHN0YW5kYXJkaXpl ZCBNUExTDQo+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95 bWVudCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhh dCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZiBMM1ZQTiBvdmVyIGFuDQo+PiBJ UC1vbmx5IG5ldHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0KPiBUaGFuayB5b3UgZm9yIHRlbGxp bmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXIgSVAgaW4gYXQg bGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJl IHZlcnkgdmFsdWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMg bm8gYXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRvZGF5J3MgU1AgbmV0d29ya3MuDQo+ DQo+PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQ djMNCj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNr IGluIHRoZSAyMDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBiZQ0KPj4gY2FycmllZCBv dmVyIEwyVFB2Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBs ZWFzdCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4gSVBWUE4ncyBvdmVyIEwyVFB2MzoN Cj4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3Vp ZGUvY3NnbDN2cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3Zl IGluZm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBBTkQgb3RoZXIgZHJhZnRz LCB0aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgU2Vz c2lvbiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRo ZSBHUkUgaGVhZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQwXSBpcyBub3Qgd2lkZWx5IHN1cHBv cnRlZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFyLg0KRldJVywgSSBoYXZlIGhhZCBz dWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4gcmVxdWVzdGluZyBhIGNv cmUgcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNl ZCBpbiBoYXNoIGNhbGN1bGF0aW9ucyBpbiBfZXhpc3RpbmdfIGhhcmR3YXJlLCBhbHJlYWR5IGRl cGxveWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBuZXR3b3JrLiAgRnVydGhlciwgSSBz dXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3Mg YW5kIHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWly bHkgd2VsbC4gIEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMg YW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzIHJlZ2FyZC4gIFRodXMsIGl0 IG1heSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhl aXIgSFcgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVx dWlwbWVudCB0byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0 aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxvdy4NCg0KDQo+IEluIGNv bnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9m IGJhbGFuY2luZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZl LXR1cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxh dGlvbiwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkgb2Yg bW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVp cmluZyBhbnkgY2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2Yg dGhpcyBkcmFmdC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBub3QgZW5jYXBzdWxh dGUgdGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoIHVzZXMgVURQL0lQLCBpbiB0aGUg Zmlyc3QgcGxhY2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRl ciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwgd2hpY2ggd291bGQgYWxsb3cgdGhl IGNvbm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbCBwYWNrZXRzKSB0 byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVz c2VzKSwgYmFzZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2Fk LWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbiBJUC1vbmx5IGNvcmUuICBM MlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmYganVzdCB1 c2luZyB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0 aXBsZXhvciB0byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVk IEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhh dCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLCBtYWtpbmcg YW55ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBM MlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpUaGUgYmVhdXR5IG9mIHRoZSBhYm92 ZSBhcHByb2FjaCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBs aWtlbHkgYSBjaGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRoZSAiY29udHJvbCBjaGFubmVsIiAo c29mdHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMuICBI ZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwy VFB2MyBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRv IGNvbW1lbnQgb24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3Vy aXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBhbmQgIkNvb2tpZSIgZmllbGRzIHRv IGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlk ZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToN Ci0tLXNuaXAtLS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFmZmljIHNlcGFyYXRpb24gZm9yIGl0 cyBWUE5zIHZpYSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVh ZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KICAgKGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8gZW5zdXJlDQogICB0 aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vz c2lvbi4NCiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3Zp ZGVzIGFuIGV4dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2Fz IHBlcmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAgIFNlc3Npb24gSUQgaXRzZWxmIHdh cyBub3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlwLS0tDQouLi4gaW4gcmVnYXJkIHRv IHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYSBmb2xrcyBoYXZl LCBpbiB0aGUgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxh dGlvbiBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91 IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBSRkMgNDY2NS4gIChUaGVy ZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExT IGZvciB0cmFuc3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBm b2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBvbiB0aGUgTVBMUyBXRyBt YWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsIGFyaXNl IGlmL3doZW4gdGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KMykgRmluYWxseSwgdGhp cyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1wbGVtZW50IEwy VFAsIGZvciB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50 aXJlIGluZHVzdHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBw cm9kdWN0IGxpbmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1 DQo+DQo+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVu IGNsZWFybHkgaXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3JlIHdpZGVseSBpbXBsZW1lbnRlZCBi eSBlcXVpcG1lbnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBMUyBvdmVyIEdSRSBvcg0KPj4gTVBM UyBvdmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUncyBhIHdheSkuICBJ IHdvdWxkIG5vdGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90 IHBhbiBvdXQgd2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4+IG9wZXJhdGlvbmFs IGJlbmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBuYXRpdmUgTVBMUw0KPj4gZW5jYXBz dWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+PiAtIE1Q TFMgRmFzdCBSZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+IC4uLiB0 byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxs aW5nIGFyZ3VtZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExT IGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1zaGFuZQ0KPj4NCj4+DQo+Pj4gLUpv c2gNCj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIg PGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+PiB3cm90ZToN Cj4+Pg0KPj4+PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBs ZWdhY3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4+Pj4NCj4+ Pj4gUmVnYXJkcywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBEZWMgMTcsIDIw MTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1 eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFNoYWhyYW0sDQo+Pj4+Pg0K Pj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXIt SVAgZW5jYXBzdWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNp bmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFw cGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPj4+ Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwg TlZHUkUgYW5kIFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5k IHVzZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj4+Pj4gaXQncyBtZWFuaW5n bGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUA0K Pj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQg dG8gTVBMUyBvdmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92 ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNvLg0KPj4+Pj4NCj4+Pj4+IEJ5IHRo ZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+Pj4+PiBqdXN0IHRoZSBy aWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgYXJndW1l bnQNCj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNh YmxlIHRvIGRhdGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVh ayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2lsZW50DQo+Pj4+PiB0aWxs IG5vdy4NCj4+Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92 ZSBvdGhlcndpc2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0t08q8 /tStvP4tLS0tLQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBTLg0KPj4+Pj4+IERhdmFyaQ0KPj4+ Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4+Pj4+IMrVvP7IyzogTG9hIEFu ZGVyc3Nvbg0KPj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+Pj4+PiDW98ziOiBSZTog W21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+Pj4+Pj4gZHJh ZnQteHUtbXBscy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQN Cj4+Pj4+Pg0KPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBu byBhcHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+Pj4+Pj4gYW5k IGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBw bGljYXRpb24NCj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5 IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBOVkdSRSBhbmQNCj4+Pj4+ PiBWWExBTi4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcg dG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPj4+Pj4+IHByb2Nlc3MNCj4+ Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+Pj4+Pj4NCj4+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDE0 LCAyMDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBw aS5udT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+ Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRv Y3VtZW50Lg0KPj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMg YmVlbiBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5n DQo+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZzxodHRwOi8vaWV0 Zi5vcmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+Pj4+Pj4+IG1vdGl2YXRpb24gZm9y IHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0K Pj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBn cm91cCBkb2N1bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAw NywgMjAxMy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0 IHRoaXMgZG9jdW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lw ci8xOTQxLyAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFz IHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gdGhhdCB0 aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJl YWR5DQo+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8g dmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFINCj4+Pj4+ Pj4gcG9sbCkNCj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0 aGUgYXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJh Y3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0NCj4+Pj4+Pj4g b2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMg dHJpZWQgdG8NCj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5 IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbC4NCj4+Pj4+Pj4gV2UgaGF2 ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcm9tIHZlcnNpb24g LTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxsIGFzIGENCj4+Pj4+Pj4g Y28tYXV0aG9yLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+IChtcGxzIHdnIGNvLWNo YWlyKQ0KPj4+Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBMb2EgQW5kZXJzc29u ICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJp Y3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj4gU3Ig U3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0 bzpsb2FAcGkubnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAg ICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2JTIwMTAlMjA3MTclMjA1MiUyMDEz Pg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3 NjcgNzIgOTIgMTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5MiUyMDEzPg0KPj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBtcGxz IG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+IGNv cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+PiBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0 YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kDQo+PiBhdHRhY2htZW50cyB0 byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu IElmIHlvdQ0KPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4gcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4N Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+ DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1w bHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A99Dszxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Pat,

 = ;

This MPLS-= in-UDP technology is intended to be used in the scenarios where existing MP= LS over IP technologies (e.g., MPLS over GRE) have been used and are to be used. Data center is just one scenario but not the only one.=

 = ;

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: Pat Thaler [mailto:pthaler@broadcom.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C222=C8=D5 = 4:49
=CA=D5=BC=FE=C8=CB: Lucy yong; Andrew G. Malis; Shane Amante
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.iet= f.org
=D6=F7=CC=E2: RE: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an= mpls working group document

 

Lucy,=

 = ;

If your dr= aft is intended to address the NVO3 requirements, then it should be conside= red in NVO3 along with the other proposed solutions rather than bypassing that process by submitting it to MPLS.

 = ;

The NVO ch= arter requires that the preliminary analysis work be completed before compl= eting solutions:

The NVO3 WG will write the= following informational RFCs, which
must have completed Working Group Last Call before rechartering can be
considered:

Problem Statement
Framework document
Control plane requirements document
Data plane requirements document
Operational Requirements
Gap Analysis

Driven by the requirements and consistent with the gap analysis,
the NVO3 WG may request being rechartered to document solutions
consisting of one or more data plane encapsulations and
control plane protocols as applicable.

 = ;

Based on t= he NVO3 charter, it is premature to consider solutions at this point and su= ggesting that something should go forward because it supports one item in a draft NVO3 requirements document is not justified.

 = ;

Regards,

Pat

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Friday, December 21, 2012 11:27 AM
To: Andrew G. Malis; Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@= tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

Andy,=

 = ;

Here is th= e text from draft-ietf-nvo3-dataplane-requirements-00.txt

 = ;

  3.3.2.= 1. LAG and ECMP 

 

  &= nbsp;    For performance reasons, multipath over LAG and ECM= P paths SHOULD be

  &= nbsp;    supported.

 

  &= nbsp;    LAG (Link Aggregation Group) [IEEE 802.1AX-2008] an= d ECMP (Equal

  &= nbsp;    Cost Multi Path) are commonly used techniques = to perform load-

  &= nbsp;    balancing of microflows over a set of a parallel li= nks either at

  &= nbsp;    Layer-2 (LAG) or Layer-3 (ECMP). Existing depl= oyed hardware

  &= nbsp;    implementations of LAG and ECMP uses a hash of= various fields in the

  &= nbsp;     encapsulation (outermost) header(s) (e.g= . source and destination MAC

  &= nbsp;    addresses for non-IP traffic, source and desti= nation IP addresses,

  &= nbsp;    L4 protocol, L4 source and destination port nu= mbers, etc).

  &= nbsp;    Furthermore, hardware deployed for the underla= y network(s) will be

  &= nbsp;    most often unaware of the carried, innermost L= 2 frames or L3 packets

  &= nbsp;    transmitted by the TS. Thus, in order to perfo= rm fine-grained load-

  &= nbsp;    balancing over LAG and ECMP paths in the underlying= network, the

  &= nbsp;    encapsulation MUST result in sufficient entrop= y to exercise all

  &= nbsp;    paths through several LAG/ECMP hops. The entro= py information MAY be

  &= nbsp;    inferred from the NVO3 overlay header or under= lay header.

 

Our draft pro= vides an advanced solution in this space.

 = ;

Lucy<= /o:p>

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-= mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this = draft, and like Shane, I remain unconvinced of its utility. I still don't t= hink it has any utility at all for core backbone networks - just use native= MPLS, or if you must tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, = I guess I could be convinced, but I would like to see a clear justification= in the form of requirements from nvo3 that could only be met by this draft= .

Thanks,
Andy

=  

On Wed, Dec 19, 2012 at 9:38 AM= , Shane Amante <shane@castlepoint.net> wrote:

Xiaohu,

=
On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlepoint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012= =C4=EA12=D4=C219=C8= =D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in th= e relatively recent past, in requesting a core router vendor to support cha= nges to the input-keys used in hash calculations in _existing_ hardware, al= ready deployed (extensively) throughout my network.  Further, I suspect that most large network operators are= savvy folks and understand the internal architecture of their HW fairly we= ll.  As a result, those same operators know what is and is not technic= ally possible in this regard.  Thus, it may be a question of "methods" necessary to convince their HW suppli= er(s) to make appropriate changes in their equipment to achieve their busin= ess goals.  :-)  However, this may not even be necessary ... see = below.

=

> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why = not encapsulate the traffic in MPLS/L2TPv3, which uses UDP/IP, in the first= place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org;
>>>>>> mpls= -chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.= andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46= 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org=
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A99Dszxeml525mbschi_-- From davari@broadcom.com Sun Dec 23 18:47:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715E121F8B1C for ; Sun, 23 Dec 2012 18:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlxoV6-S0UqY for ; Sun, 23 Dec 2012 18:47:07 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id D99F021F8A7B for ; Sun, 23 Dec 2012 18:46:57 -0800 (PST) Received: from [10.16.192.224] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Sun, 23 Dec 2012 18:42:00 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Sun, 23 Dec 2012 18:46:46 -0800 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Sun, 23 Dec 2012 18:46:46 -0800 From: "Shahram Davari" To: Xuxiaohu Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3s+/R6wH2496W026x2QpZjBKZ5gibhgA//+D0HCAARNWgIAAaGeAgADmiQCAAAyfgIADZRqA//9+Tdo= Date: Mon, 24 Dec 2012 02:46:46 +0000 Message-ID: <814D9C14-9211-4EDD-8C2A-564FDB7F5D78@broadcom.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98A@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98A@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-WSS-ID: 7CC91F7239W17406194-01-01 Content-Type: multipart/alternative; boundary=_000_814D9C1492114EDD8C2A564FDB7F5D78broadcomcom_ Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:47:11 -0000 --_000_814D9C1492114EDD8C2A564FDB7F5D78broadcomcom_ Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 TVBMUyBiYXNlZCBWUE4gc3VwcG9ydHMgbXVsdGljYXN0IFRyZWUsIGJ1dCBvbmx5IHdoZW4gVHJh bnNwb3J0IGlzIE1QTFMgYW5kIG5vdCBJUC4gTVBMUyBvdmVyIElQIGRvZXMgbm90IHN1cHBvcnQg TXVsdGljYXN0IHRyZWUuDQoNClJlZ2FyZHMsDQpTaGFocmFtDQoNCg0KT24gRGVjIDIzLCAyMDEy LCBhdCA2OjMyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhp YW9odUBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCg0KDQq3orz+yMs6IFMuIERhdmFyaSBbbWFpbHRv OmRhdmFyaXNoQHlhaG9vLmNvbV0NCreiy83KsbzkOiAyMDEyxOoxMtTCMjLI1SA2OjQwDQrK1bz+ yMs6IEx1Y3kgeW9uZzsgWHV4aWFvaHU7IFNoYWhyYW0gRGF2YXJpDQqzrcvNOiBkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0K 1vfM4jogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5n IG5ldHdvcmsNCg0KTHVjeSwNCg0KSSBjYW4gb25seSBzZWUgQ2hpbmEgVGVsZWNvbSBhcyBjby1h dXRob3IsIGFuZCB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uIHNheXMgTDJWUE4gYW5kIEwzVlBO LiBTbyBpcyBDaGluYSBUZWxlY29tIHVzaW5nIGl0IGZvciB0aGVpciBFbnRlcnByaXNlIFZQTiBz ZXJ2aWNlPyBidXQgeW91ciBlYXJsaWVyIGVtYWlscyBzdWdnZXN0cyB0aGF0IHRoaXMgaXMgbm90 IHRoZSBpbnRlbmRlZCB1c2FnZSByYXRoZXIgaXQgaXMgZm9yIERhdGEgQ2VudGVyLiBTbyB3aGlj aCBvbmUgaXMgaXQ/IFdoeSBpc24ndCBDaGluYSBUZWxlY29tIHNwZWFraW5nIG9uIHRoZSBsaXN0 IGFuZCBleHBsYWluaW5nIHRoZWlyIHVzYWdlIG1vZGVsPw0KDQpbWGlhb2h1XSBZZXMsIHRoZSBB cHBsaWNhYmlsaXR5IHNlY3Rpb24gc2F5cyBMMlZQTiBhbmQgTDNWUE4sIGJ1dCB0aGVyZSBpcyBu byBsaW1pdCB0aGF0IHRoZXNlIHRlY2hub2xvZ2llcyBjb3VsZCBvbmx5IGJlIHVzZWQgYnkgc2Vy dmljZSBwcm92aWRlcnM/ICBFbnRlcnByaXNlcyB0aGVtc2VsdmVzIGNvdWxkIGFkb3B0IHRoZXNl IHRlY2hub2xvZ2llcyB0byBpbnRlcmNvbm5lY3QgdGhlaXIgbXVsdGlwbGUgc2l0ZXMgYW5kIGRh dGEgY2VudGVyIG9wZXJhdG9ycyBjb3VsZCB1c2UgdGhlbSB3aXRoaW4gb3IgZXZlbiBhY3Jvc3Mg ZGF0YSBjZW50ZXJzIGFzIHdlbGwgaWYgdGhleSB3b3VsZCBsaWtlLiBMZXQgbWUgaXRlcmF0ZSB0 aGF0IE1QTFMtYmFzZWQgVlBOIG92ZXIgSVAgY2FuIGJlIHVzZWQgaW4gU1AgbmV0d29ya3MsIGVu dGVycHJpc2UgbmV0d29ya3MgYW5kIGV2ZW4gZGF0YSBjZW50ZXJzIGFuZCB0aGVyZWZvcmUgTVBM Uy1pbi1VRFAgaXMgYXBwbGljYWJsZSB0byBhbnkgb2YgdGhlIGFib3ZlIHNjZW5hcmlvIGFzIHdl bGwuDQoNCkFsc28gcmVnYXJkaW5nIE11bHRpY2FzdCwgdGhpcyBtZWFucyB5b3UgbmVlZCB0byBt YXAgTXVsdGljYXN0IHRyYWZmaWMgdG8gUDJQIFBXLCB3aGljaCBpcyBpbmZlcmlvciB0byBvdGhl ciBtZXRob2RzIHN1Y2ggYXMgTlZHUkUgYW5kIFZYTEFOIHNpbmNlIHRoZXkgbmF0aXZlbHkgc3Vw cG9ydCBlZmZpY2llbnQgTXVsdGljYXN0Lg0KDQpbWGlhb2h1XSBGaXJzdCwgcmVtZW1iZXIgdGhh dCBNUExTLWluLVVEUCBpcyBub3Qgb25seSBzdWl0YWJsZSBmb3IgTVBMUy1iYXNlZCBMMlZQTiBi dXQgYWxzbyBzdWl0YWJsZSBmb3IgTDNWUE4uIFNlY29uZCwgTVBMUy1iYXNlZCBWUE4gY2FuIHN1 cHBvcnQgYm90aCBpbmdyZXNzIHJlcGxpY2F0aW9uIG1vZGUgYW5kIG11bHRpY2FzdCB0cmVlIG1v ZA0KDQpUaGFua3MsDQpTaGFocmFtDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55 b25nQGh1YXdlaS5jb20+Pg0KVG86IFMuIERhdmFyaSA8ZGF2YXJpc2hAeWFob28uY29tPG1haWx0 bzpkYXZhcmlzaEB5YWhvby5jb20+PjsgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFp bHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PjsgU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNv bS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KQ2M6ICJkcmFmdC14dS1tcGxzLWlu LXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0 Zi5vcmc+IiA8ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPj47ICJtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PjsgIm1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zz4iIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxOjU1OjEwIFBNDQpT dWJqZWN0OiBSRTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlp bmcgbmV0d29yaw0KDQoNClNoYWhyYW0sDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpGcm9tOiBT LiBEYXZhcmkgW21haWx0bzpkYXZhcmlzaEB5YWhvby5jb21dDQpTZW50OiBGcmlkYXksIERlY2Vt YmVyIDIxLCAyMDEyIDI6MTAgQU0NClRvOiBYdXhpYW9odTsgU2hhaHJhbSBEYXZhcmk7IEx1Y3kg eW9uZw0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVy IG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KDQpIaSwNCg0KSSB0aGluayB3ZSBhcmUg aW4gYSB2aWNpb3VzIGN5Y2xlLiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggbmV0d29y ayBvcGVyYXRvciBpcyBhc2tpbmcgZm9yIE1QTFMgb3ZlciBVRFAgYW5kIHdoYXQgaXMgdGhlIGFw cGxpY2F0aW9uLg0KW0x1Y3ldIGl0IGlzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQuDQpBbHNvIGhv dyBkbyB5b3UgcGxhbiB0byBhZGRyZXNzIHRoZSBNUExTIE11bHRpY2FzdCAod2hpY2ggaXMgcHJv YmFibHkgbW9yZSBpbXBvcnRhbnQgdGhhbiBpbXByb3ZpbmcgdGhlIGxvYWQgYmFsYW5jaW5nKSwg Z2l2ZW4gdGhhdCBSRkM0MDIzIGRvZXMgbm90IHN1cHBvcnQgTXVsdGljYXN0Lg0KW0x1Y3ldIE1Q TFMgQ2xpZW50IExheWVyIGlzIHJlc3BvbnNpYmxlIHRvIG1hcCBtdWx0aWNhc3QgdHJhZmZpYyB0 byB1bmRlcmx5aW5nIHRyYW5zcG9ydCwgd2hpY2ggaXMgc3BlY2lmaWVkIGluIEVWUE4gYW5kIElQ IFZQTi4gVGhpcyBwcm9wb3NhbCBqdXN0IHJlcXVlc3RzIGluZ3Jlc3MgUEUgdG8gZmlsbCB0aGUg ZmxvdyBlbnRyb3B5IGludG8gVURQIHNvdXJjZSBwb3J0LCBpbiB3aGljaCB0aGUgZmxvdyBjYW4g YmUgdW5pY2FzdCBvciBtdWx0aWNhc3QuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpUaGFua3Ms DQpTaGFocmFtDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4N ClRvOiBTaGFocmFtIERhdmFyaSA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJy b2FkY29tLmNvbT4+OyBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5 LnlvbmdAaHVhd2VpLmNvbT4+DQpDYzogImRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC14 dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmc+PjsgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8 bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+OyAibXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPiIgPG1wbHMtY2hhaXJz QHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4+DQpTZW50 OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNTo1NjoyMyBQTQ0KU3ViamVjdDogUmU6IFtt cGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCg0K DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+IFNoYWhyYW0gRGF2YXJp DQo+ILeiy83KsbzkOiAyMDEyxOoxMtTCMjHI1SAxOjMxDQo+IMrVvP7IyzogTHVjeSB5b25nDQo+ ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14 dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47DQo+IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+DQo+INb3zOI6IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIg b3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQo+DQo+IFBsZWFzZSBkb24ndCBtaXggdXAg dGhpbmdzLiBUaGUgTVBMUyBwcm90b2NvbCBkZXNpZ24gSSBhZ3JlZSBtdXN0IGJlIGRvbmUgYnkN Cj4gTVBMUyBXRy4gQnV0IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdXIgcHJvcG9zYWwgbWVl dHMgdGhlIG5ldHdvcmsNCj4gdmlydHVhbGl6YXRpb24gcmVxdWlyZW1lbnRzLg0KDQpDYW4geW91 IHRlbGwgdXMgd2hlcmUgTVBMUy1pbi1HUkUvSVAgW1JGQzQwMjNdIGFuZCBvdGhlciBNUExTIG92 ZXIgSVAgZW5jYXBzdWxhdGlvbiBtZWNoYW5pc21zIGhhdmUgYmVlbiBkaXNjdXNzZWQgYmVmb3Jl Pw0KDQpTaW5jZSBNUExTLWluLVVEUCBpcyBqdXN0IGludGVuZGVkIHRvIGJlIHVzZWQgaW4gdGhl IHNjZW5hcmlvcyB3aGVyZSBNUExTLWluLUdSRS9JUCBoYXMgYmVlbiB1c2VkIGFuZCBpcyB0byBi ZSB1c2VkLCBNUExTLWluLVVEUCBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRoZSBzYW1lIFdHIHdo ZXJlIE1QTFMtaW4tR1JFL0lQIGhhcyBiZWVuIGRpc2N1c3NlZC4NCg0KWGlhb2h1DQoNCj4gVGhl IE5WTzMgdGFzayBpcyB0byBkb2N1bWVudCB0aGUgaXNzdWVzLCByZXF1aXJlbWVudHMgYW5kIGZy YW1ld29yayBmb3INCj4gTnZPMy4gVGhlbiBpZiBNUExTIG92ZXIgSVAgbG9va3MgbGlrZSBhIHN1 aXRhYmxlIHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlDQo+IHJlcXVpcmVtZW50cyBzdWNoIGFzIHRo ZSBzY2FsZSwgbW9iaWxpdHksIGV0YywgdGhlbiB0aGV5IHdpbGwgYXNrIE1QTFMgV0cgZm9yDQo+ IHByb3RvY29sIGRlc2lnbi4NCj4NCj4gU28gYmVmb3JlIHByb2NlZWRpbmcgdGhpcyBkcmFmdCwg SSB0aGluayB5b3Ugc2hvdWxkIHRha2UgaXQgdG8gTlZPMyBXRyBhbmQNCj4gY29udmluY2UgdGhl bSB0aGlzIHNvbHV0aW9uIG1lZXRzIHRoZWlyIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrLg0K Pg0KPiBXZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0aW9ucyBm b3IgdGhlIHNhbWUgcHJvYmxlbSwgZG8NCj4gd2U/DQo+DQo+IC1TaGFocmFtDQo+DQo+DQo+DQo+ IFJlZ2FyZHMsDQo+IFNoYWhyYW0NCj4NCj4NCj4gT24gRGVjIDIwLCAyMDEyLCBhdCA4OjU2IEFN LCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQo+DQo+ID4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGlz IGRpc2N1c3NlZCB1bmRlciBudm8zIFdHLiBUaGlzIGRvZXMgbm90DQo+IG1lYW4gdGhhdCBudm8z IFdHIGhhcyB0byBkZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEgdW5kZXJseWluZyBuZXR3b3Jr IG9yIGENCj4gbmV3IHByb3RvY29sIGZvciBhIG92ZXJsYXkgbmV0d29yay4gSW4gZmFjdCwgcGVv cGxlIHRoZXJlIGFpbSBvbiBsZXZlcmFnZQ0KPiBzdGFuZGFyZCBuZXR3b3JrIHByb3RvY29scyB0 byBhY2NvbXBsaXNoIHRoZW0uIElNTzogdGhlc2UgZXhwYW5zaW9ucyBvbiBhbg0KPiBleGlzdGlu ZyBzdGFuZGFyZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhlIHByb3RvY29s IFdHIGdyb3VwLCBpdA0KPiBzaG91bGQgbm90IGdpdmUgbnZvMyBXRyBmcmVlIHJpZ2h0IHRvIGVu aGFuY2UgdGhlc2UgcHJvdG9jb2xzLiBGb3IgYSBicmFuZA0KPiBuZXcgcHJvdG9jb2wgZm9yIG5l dHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSwgbnZvMyBXRyBtYXkgYmUgdGhlIHBsYWNlIHRv DQo+IHN0YXJ0Lg0KPiA+DQo+ID4gTHVjeQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+IEZyb206IFNoYWhyYW0gRGF2YXJpIFttYWlsdG86ZGF2YXJpQGJyb2FkY29t LmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbT5dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBE ZWNlbWJlciAyMCwgMjAxMiAxMDozNCBBTQ0KPiA+PiBUbzogTHVjeSB5b25nDQo+ID4+IENjOiBT aGFuZSBBbWFudGU7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+Ow0KPiA+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86 bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBbbXBsc10gTVBM UyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrDQo+ID4+DQo+ID4+ IE5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBtdXN0IGJlIGRpc2N1c3NlZCBhbmQgY29u c2VudGVkICBpbiBOVk8zDQo+ID4+IFdHLg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBTaGFo cmFtDQo+ID4+DQo+ID4+DQo+ID4+IE9uIERlYyAyMCwgMjAxMiwgYXQgNzozOSBBTSwgIkx1Y3kg eW9uZyIgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+ IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gSGkgU2hhbmUsDQo+ID4+Pg0KPiA+Pj4gSSB1bmRlcnN0YW5k IG9wZXJhdG9yIGNvbmNlcm4gb24gYSBuZXcgZW5jYXBzdWxhdGlvbiB0byBhbiBleGlzdGluZw0K PiA+PiBuZXR3b3JrLg0KPiA+Pj4NCj4gPj4+IEhvd2V2ZXIsIE1QTFMtaW4tVURQIGRvZXMgbm90 IGFpbSBvbiBjaGFuZ2luZyBleGlzdGluZyBTUCBJUC9NUExTDQo+ID4+IG5ldHdvcmsgYXQgYWxs Lg0KPiA+Pj4gTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVyIHRvIGJl IGRlY291cGxlZCBmcm9tIE1QTFMNCj4gPj4gc2VydmVyIGxheWVyIGFuZCB1c2UgTVBMUyBjbGll bnQgbGF5ZXIgYXMgb3ZlcmxheSBuZXR3b3JrIGFuZCBhbiBJR1AgYXMNCj4gPj4gYSB1bmRlcmx5 aW5nIG5ldHdvcmsgZm9yIHRyYW5zcG9ydC4gU3VjaCBhcHBsaWNhdGlvbiBpcyBmb3IgREMuIFlv dSBtYXkNCj4gPj4gYXJndWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBMUyBs YXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcNCj4gPj4gbmV0d29yay4gV2UgaGF2ZSBwb2ludGVk IG91dCBpbiB0aGUgZHJhZnQgdGhhdCBjdXJyZW50IHJvdXRlcnMgaW4gREMNCj4gPj4gYmFyZWx5 IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCBNUExTLWluLUdSRSBhcmUgYmFy ZWx5IHVzZWQNCj4gPj4gaW4gU1AgbmV0d29ya3MgdG9vLiBNb3N0IG9mIHJvdXRlcnMgaW4gREMg cGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkDQo+ID4+IGJhbGFuY2luZyBub3cuDQo+ID4+Pg0K PiA+Pj4gRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUgVURQIGVuY2Fwc3Vs YXRpb24gaGFzDQo+ID4+IGFkdmFudGFnZSBvdmVyIEdSRSBlbmNhcHN1bGF0aW9uIHRvby4gSW4g VURQIGVuY2Fwc3VsYXRpb24sIHRoZSBmcmFtZQ0KPiA+PiBoZWFkZXIgZGVjb3VwbGVzIHRoZSBv dmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdvcmsgY2xlYXJseSwgaS5lLiBvdXRlcg0KPiA+PiBo ZWFkZXIgYW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFkZXIsIHdo aWNoDQo+ID4+IHVuZGVybHlpbmcgbmV0d29yayB1c2VzIG9ubHkuIEhvd2V2ZXIsIEdSRSBoZWFk ZXIgaGFzIHRoZSBmaWVsZHMgZm9yDQo+ID4+IHRoZSBvdmVybGF5IG5ldHdvcmsgYW5kIHVzZXMg dGhlIGtleSBmaWVsZCBmb3IgZmxvdyBlbnRyb3B5LiBGb3IgbG9hZA0KPiA+PiBiYWxhbmNpbmcs IGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBHUkUgaGVhZGVyIHRvby4g SW4NCj4gPj4gc2hvcnQsIEdSRSB0aWVzIHRoZSBvdmVybGF5IGFuZCB1bmRlcmx5aW5nIG5ldHdv cmtzIHRvZ2V0aGVyLiBTaW5jZSBpdA0KPiA+PiBoYXMgbm90IHVzZWQgYSBsb3QsIHBlb3BsZSBh cmUgbm90IGF3YXJlIG9mIHRoZSBkaXNhZHZhbnRhZ2Ugb2Ygc3VjaA0KPiA+PiBjb3VwbGluZy4N Cj4gPj4+DQo+ID4+PiBBcyB0aGUgaW5kdXN0cnkgbW92ZXMgdG93YXJkIG5ldHdvcmsgdmlydHVh bGl6YXRpb24gb3ZlcmxheSBhbmQNCj4gPj4gZGVjb3VwbGVzIG92ZXJsYXkgbmV0d29ya3MgZnJv bSB0aGUgdW5kZXJseWluZyBuZXR3b3JrLiBBIGNsZWFyDQo+ID4+IHNlcGFyYXRpb24gb2Ygb3Zl cmxheSBoZWFkZXIgYW5kIHVuZGVybHlpbmcgaGVhZGVyIGlzIGEgIk1VU1QiIGluIG15DQo+ID4+ IG9waW5pb24uIElmIHdlIGNvdW50IEdSRSBhcyB0aGUgb3ZlcmxheSBoZWFkZXIsIHRoZW4gZm9y IElQdjQNCj4gPj4gdW5kZXJseWluZyBuZXR3b3JrLCB0aGVyZSBpcyBubyBmaWVsZCBmb3IgdGhl IGZsb3cgZW50cm9weS4gVGhpcyBpcyB0aGUNCj4gPj4gcmVhc29uIHdlIHByb3Bvc2UgdGhlIFVE UCBlbmNhcHN1bGF0aW9uOiBmb3IgYW4gSUdQIGJhc2VkIHVuZGVybHlpbmcNCj4gPj4gbmV0d29y ay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJsYXkgbmV0d29yayBiZXNpZGUgTVBM UyBjbGllbnQNCj4gPj4gbGF5ZXIgKGUuZy4gVlhMQU4sIEwyVFAtaW4tVURQLCBldGMpLg0KPiA+ Pj4NCj4gPj4+IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVEUCBpbnN0ZWFk LiBZZXMsIE1QTFMtaW4tTDJUUC0NCj4gPj4gaW4tVURQIHNjaGVtYSBhbHNvIHByb3ZpZGVzIGEg b3ZlcmxheSAoTDJUUCkgYW5kIHVuZGVybHlpbmcgKElQKQ0KPiA+PiBuZXR3b3JrIGRlY291cGxp bmcuIEwyVFAgcHJvdG9jb2wgKHJmYzM5MzEpIHByb3ZpZGVzIGdvb2Qgc2VjdXJpdHkNCj4gPj4g bWVjaGFuaXNtIGFuZCBoYXMgdGhlIGVtYmVkZGVkIGNvbnRyb2wgZnVuY3Rpb24gdG9vLiBUaGVy ZWZvcmUsDQo+IHNvbWVvbmUNCj4gPj4gY2FuIHVzZSBpdCBmb3IgTVBMUyBjbGllbnQgbGF5ZXIg b3ZlciBJbnRlcm5ldC4gVG8gaGF2ZSBNUExTIGNsaWVudA0KPiA+PiBsYXllciBvdmVyIGFuIElH UCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWluLUwyVFAtaW4tVURQIGlzIGENCj4gPj4g b3ZlcmtpbGwgYW5kIHRvbyBjb21wbGV4LiBIZXJlIHdlIG5lZWQgYSBzY2hlbWEgdG8gc3VwcG9y dCBJR1ANCj4gPj4gdW5kZXJseWluZyB0cmFuc3BvcnQgd2l0aG91dCB0b3VjaGluZyBhIG92ZXJs YXkgaGVhZGVyLiBVRFANCj4gPj4gZW5jYXBzdWxhdGlvbiBpcyB0aGUgYmVzdCBjaG9pY2UgdG8g YWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGUNCj4gPj4gY2hhbmdlcyBvbiBleGlzdGlu ZyByb3V0ZXJzLCBlLmcuIGNoYW5nZSBhdCBlZGdlIHJvdXRlcnMsIG5vIGNoYW5nZSBvbg0KPiA+ PiB0cmFuc2l0IHJvdXRlcnMuDQo+ID4+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+IEx1Y3kNCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ Pj4+IEZyb206IFh1eGlhb2h1IFttYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4 aWFvaHVAaHVhd2VpLmNvbT5dDQo+ID4+Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAy MDEyIDQ6MTQgQU0NCj4gPj4+PiBUbzogU2hhbmUgQW1hbnRlDQo+ID4+Pj4gQ2M6IFJvZ2Vycywg Sm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMtaW4tDQo+ID4+IHVkcEB0b29scy5p ZXRmLm9yZzxtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnPjsNCj4gPj4+PiBtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv Om1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6IERpc2N1c3Npb24g b24gaG93IHRvIHRyYW5zcG9ydCBNUExTIG92ZXIgVURQIHR1bm5lbHMNCj4gPj4+Pg0KPiA+Pj4+ IEhpIFNoYW5lLA0KPiA+Pj4+DQo+ID4+Pj4gVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIgY29tbWVu dHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLg0KPiA+Pj4+DQo+ID4+Pj4gTm90 ZTogSSBjaGFuZ2VkIHRoZSBzdWJqZWN0IGxpbmUgYWNjb3JkaW5nIHRvIExvYSdzIHN1Z2dlc3Rp b24uDQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+Pj4+ILeivP7Iyzog U2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0PG1haWx0bzpzaGFuZUBj YXN0bGVwb2ludC5uZXQ+XQ0KPiA+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjE5yNUgMjI6MzgN Cj4gPj4+Pj4gytW8/sjLOiBYdXhpYW9odQ0KPiA+Pj4+PiCzrcvNOiBSb2dlcnMsIEpvc2g7IFNo YWhyYW0gRGF2YXJpOyBkcmFmdC14dS1tcGxzLWluLQ0KPiA+Pj4+IHVkcEB0b29scy5pZXRmLm9y ZzxtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnPjsNCj4gPj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4gPj4+Pj4g1vfM4jogUmU6IFttcGxzXSBwb2xsIHRv IHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS0NCj4gPj4+PiBtcGxzLWlu LXVkcCBhbg0KPiA+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4NCj4g Pj4+Pj4gWGlhb2h1LA0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUw IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2Vp LmNvbT4+DQo+IHdyb3RlOg0KPiA+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4+Pj4+PiC3 orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86 c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4gPj4+Pj4+PiC3osvNyrG85DogMjAxMsTqMTLUwjE5 yNUgMTE6NTgNCj4gPj4+Pj4+PiDK1bz+yMs6IFJvZ2VycywgSm9zaA0KPiA+Pj4+Pj4+ILOty806 IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPj4+PiB1ZHBA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnVkcEB0b29scy5pZXRmLm9yZz47DQo+ID4+Pj4+Pj4gbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4gPj4+Pj4+PiDW98ziOiBS ZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1 LQ0KPiA+Pj4+IG1wbHMtaW4tdWRwDQo+ID4+Pj4+IGFuDQo+ID4+Pj4+Pj4gbXBscyB3b3JraW5n IGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIERlYyAx OCwgMjAxMiwgYXQgODo1MCBBTSwgIlJvZ2VycywgSm9zaCINCj4gPj4+PiA8am9zaC5yb2dlcnNA dHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCj4gPj4+Pj4+PiB3 cm90ZToNCj4gPj4+Pj4+Pj4gSSBzaGFyZSB5b3VyIFNQIHBlcnNwZWN0aXZlLCBhbmQgZG8gbm90 IHNlZSB0aGUgcHJvYmxlbSB0aGlzDQo+ID4+Pj4gc29sdXRpb24NCj4gPj4+Pj4+Pj4gYWRkcmVz c2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiArMS4gIFBs ZWFzZSBkbyBub3QgZGVmaW5lIHlldCBhbm90aGVyIE1QTFMtb3Zlci1JUCBlbmNhcHN1bGF0aW9u Lg0KPiA+Pj4+IFRoZQ0KPiA+Pj4+PiBJRVRGDQo+ID4+Pj4+Pj4gYWxyZWFkeSBzdGFuZGFyZGl6 ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvDQo+ID4+Pj4gc3RhbmRhcmRpemVk DQo+ID4+Pj4+IE1QTFMNCj4gPj4+Pj4+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBz ZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdA0KPiA+PiBvbmUsDQo+ID4+Pj4gdmVyeQ0K PiA+Pj4+Pj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3Vw cG9ydCBjYXJyaWFnZSBvZg0KPiA+Pj4+IEwzVlBOIG92ZXINCj4gPj4+Pj4gYW4NCj4gPj4+Pj4+ PiBJUC1vbmx5IG5ldHdvcmsuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSGkgU2hhbmUsDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gVGhhbmsgeW91IGZvciB0ZWxsaW5nIHVzIHRoZXJlIGFyZSBhY3R1YWwgZGVw bG95bWVudHMgb2YgTVBMUyBvdmVyDQo+ID4+Pj4gSVAgaW4gYXQNCj4gPj4+Pj4gbGVhc3Qgb25l LCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkNCj4g Pj4+PiB2YWx1YWJsZSB0byB0aG9zZQ0KPiA+Pj4+PiBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0 aGVyZSBpcyBubyBhcHBsaWNhdGlvbiBvZiBNUExTIG92ZXIgSVAgaW4NCj4gPj4+PiB0b2RheSdz IFNQDQo+ID4+Pj4+IG5ldHdvcmtzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBTZWU6IFJGQydzIDQ0 NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4gPj4+Pj4+PiBbTk9U RTogdGhlIGRhdGVzIHRoZSBhYm92ZSB3ZXJlIHB1Ymxpc2hlZCB3YXMgYmFjayBpbiB0aGUgMjAw Ng0KPiA+Pj4+PiB0aW1lZnJhbWUhXQ0KPiA+Pj4+Pj4+ICBSRkMgNDY2NSBmb3IgcmVxdWlyZW1l bnRzIHJlbGF0ZWQgdG8gVlBMUyB0aGF0IHNheSB0aGF0IFZQTFMNCj4gPj4+PiBtYXkgYmUNCj4g Pj4+Pj4+PiBjYXJyaWVkIG92ZXIgTDJUUHYzDQo+ID4+Pj4+Pj4gIEFuZCwgaGVyZSdzIGV2aWRl bmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcw0KPiA+Pj4+PiBpbXBsZW1l bnRlZA0KPiA+Pj4+Pj4+IElQVlBOJ3Mgb3ZlciBMMlRQdjM6DQo+ID4+IGh0dHA6Ly93d3cuY2lz Y28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRtbA0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoYW5rcyBhZ2FpbiBmb3Igc2hhcmluZyB0aGUgYWJvdmUgaW5m b3JtYXRpb24uIEFzIG1lbnRpb25lZCBpbg0KPiA+Pj4+IHRoaXMgZHJhZnQNCj4gPj4+Pj4gQU5E IG90aGVyIGRyYWZ0cywgdGhlIG1lY2hhbmlzbSBvZiBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRp b24gb24NCj4gPj4gdGhlDQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiBJRCBmaWVsZCBpbiB0aGUg TDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzDQo+ID4+ Pj4gZGVmaW5lZCBpbg0KPiA+Pj4+PiBbUkZDIDU2NDBdIGlzIG5vdCB3aWRlbHkgc3VwcG9ydGVk IGJ5IGV4aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEZXSVcs IEkgaGF2ZSBoYWQgc3VjY2VzcywgaW4gdGhlIHJlbGF0aXZlbHkgcmVjZW50IHBhc3QsIGluDQo+ ID4+Pj4gcmVxdWVzdGluZyBhIGNvcmUNCj4gPj4+Pj4gcm91dGVyIHZlbmRvciB0byBzdXBwb3J0 IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoDQo+ID4+Pj4gY2FsY3VsYXRp b25zIGluDQo+ID4+Pj4+IF9leGlzdGluZ18gaGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4 dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15DQo+ID4+Pj4gbmV0d29yay4NCj4gPj4+Pj4gRnVydGhl ciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkN Cj4gPj4gZm9sa3MNCj4gPj4+PiBhbmQNCj4gPj4+Pj4gdW5kZXJzdGFuZCB0aGUgaW50ZXJuYWwg YXJjaGl0ZWN0dXJlIG9mIHRoZWlyIEhXIGZhaXJseSB3ZWxsLiAgQXMgYQ0KPiA+Pj4+IHJlc3Vs dCwgdGhvc2UNCj4gPj4+Pj4gc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3Qg dGVjaG5pY2FsbHkgcG9zc2libGUgaW4gdGhpcw0KPiA+Pj4+IHJlZ2FyZC4NCj4gPj4+Pj4gVGh1 cywgaXQgbWF5IGJlIGEgcXVlc3Rpb24gb2YgIm1ldGhvZHMiIG5lY2Vzc2FyeSB0byBjb252aW5j ZSB0aGVpcg0KPiA+Pj4+IEhXDQo+ID4+Pj4+IHN1cHBsaWVyKHMpIHRvIG1ha2UgYXBwcm9wcmlh dGUgY2hhbmdlcyBpbiB0aGVpciBlcXVpcG1lbnQgdG8NCj4gPj4gYWNoaWV2ZQ0KPiA+Pj4+IHRo ZWlyDQo+ID4+Pj4+IGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBub3Qg ZXZlbiBiZSBuZWNlc3NhcnkgLi4uDQo+ID4+IHNlZQ0KPiA+Pj4+IGJlbG93Lg0KPiA+Pj4+DQo+ ID4+Pj4gQ291bGQgeW91IHBsZWFzZSBicmllZmx5IGV4cGxhaW4gaG93IHRvIG1ha2UgdGhlIGFi b3ZlIGNoYW5nZSBpbg0KPiA+Pj4+IEVYSVNUSU5HIGhhcmR3YXJlIG9mIGFscmVhZHkgZGVwbG95 ZWQgY29yZSByb3V0ZXJzPw0KPiA+Pj4+DQo+ID4+Pj4+PiBJbiBjb250cmFzdCwgbW9zdCBleGlz dGluZyBjb3JlIHJvdXRlcnMgYXJlIGFscmVhZHkgY2FwYWJsZSBvZg0KPiA+Pj4+IGJhbGFuY2lu ZyBJUA0KPiA+Pj4+PiB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZl LXR1cGxlIG9mIFVEUCBwYWNrZXRzLg0KPiA+PiBCeQ0KPiA+Pj4+IHVzaW5nIHRoZQ0KPiA+Pj4+ PiBNUExTLWluLVVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1i YWxhbmNpbmcNCj4gPj4+PiBjYXBhYmlsaXR5IG9mDQo+ID4+Pj4+IG1vc3QgZXhpc3RpbmcgY29y ZSByb3V0ZXJzIGNhbiBiZSBsZXZlcmFnZWQgd2l0aG91dCByZXF1aXJpbmcgYW55DQo+ID4+Pj4g Y2hhbmdlIHRvDQo+ID4+Pj4+IHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2Yg dGhpcyBkcmFmdC4NCj4gPj4+Pj4NCj4gPj4+Pj4gSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4g d2h5IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbg0KPiA+Pj4+IE1QTFMvTDJUUHYzLCB3 aGljaA0KPiA+Pj4+PiB1c2VzIFVEUC9JUCwgaW4gdGhlIGZpcnN0IHBsYWNlPw0KPiA+Pj4+DQo+ ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgeW91IHByZWZlciB0byB1c2UgTVBM Uy1pbi1MMlRQdjMtaW4tDQo+ID4+IFVEUA0KPiA+Pj4+IGluc3RlYWQgb2YgTVBMUy1pbi1VRFAs IHJpZ2h0Pw0KPiA+Pj4+DQo+ID4+Pj4+IElNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0 byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0bw0KPiA+Pj4+IFJGQyAzOTMxLA0KPiA+ Pj4+PiB3aGljaCB3b3VsZCBhbGxvdyB0aGUgY29ubmVjdGlvbiB1c2VkIGZvciBkYXRhIHBhY2tl dHMgKG5vdCBjb250cm9sDQo+ID4+Pj4gcGFja2V0cykNCj4gPj4+Pj4gdG8gdXNlIGEgdmFyeWlu ZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksDQo+ID4+IGJh c2VkDQo+ID4+Pj4gb24gYSBoYXNoDQo+ID4+Pj4+IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJl dHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nDQo+ID4+IGVxdWlwbWVudA0KPiA+Pj4+ IGluIGFuDQo+ID4+Pj4+IElQLW9ubHkgY29yZS4gIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRh dGlvbnMgd291bGQgYmUgYmV0dGVyIG9mZg0KPiA+Pj4+IGp1c3QgdXNpbmcNCj4gPj4+Pj4gdGhl ICJTZXNzaW9uIElEIiAoYW5kICJDb29raWUiKSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlwbGV4b3Ig dG8NCj4gPj4+PiBhc3NvY2lhdGUNCj4gPj4+Pj4gaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBh c3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwNCj4gPj4+PiBpdCdzIG5v dA0KPiA+Pj4+PiBjbGVhciB0byBtZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkg L2FscmVhZHkvIGRvIHRoaXMsDQo+ID4+Pj4gbWFraW5nIGFueQ0KPiA+Pj4+PiAiY2hlY2siIG9u IHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVt DQo+ID4+Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhlIGJlYXV0eSBv ZiB0aGUgYWJvdmUgYXBwcm9hY2ggaXM6DQo+ID4+Pj4+IDEpIEkgd291bGQgdGhpbmsgdGhhdCB0 aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcw0KPiA+Pj4+IGxpbWl0ZWQg dG8gdGhlDQo+ID4+Pj4+ICJjb250cm9sIGNoYW5uZWwiIChzb2Z0d2FyZSkgb2YgZXhpc3Rpbmcg TDJUUCBlbmQtc3lzdGVtDQo+ID4+Pj4gaW1wbGVtZW50YXRpb25zLg0KPiA+Pj4+PiBIZWNrLCBp dCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2Mw0K PiA+Pj4+PiBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVk IHRvIGNvbW1lbnQgb24NCj4gPj4gdGhhdCkuDQo+ID4+Pj4NCj4gPj4+PiBJTUhPLCBubyBtYXR0 ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCAgdGhlIGhhcmR3YXJlDQo+ ID4+IG9mDQo+ID4+Pj4gUEUgcm91dGVycyBuZWVkcyB0byBiZSB1cGdyYWRlZCwgZS5nLiwgaW5n cmVzcyBQRSByb3V0ZXJzIG5lZWQgdG8NCj4gPj4gZmlsbA0KPiA+Pj4+IGluIGFuIGVudHJvcHkg dmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFkZXJzLg0KPiA+Pj4+DQo+ ID4+Pj4+IDIpIFRoZXJlIGlzIGEgc3Vic3RhbnRpYWwgYWRkZWQgc2VjdXJpdHkgb25lIGdldHMg YnkgdXNpbmcgIlNlc3Npb24NCj4gPj4+PiBJRCIgYW5kDQo+ID4+Pj4+ICJDb29raWUiIGZpZWxk cyB0byBlbnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQNCj4gPj4g Zm9yDQo+ID4+Pj4gdGhlDQo+ID4+Pj4+IGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJv bSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCj4gPj4+Pj4gLS0tc25pcC0tLQ0KPiA+Pj4+PiAg TDJUUHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzIt Yml0DQo+ID4+Pj4gU2Vzc2lvbg0KPiA+Pj4+PiAgSUQgaW4gdGhlIEwyVFB2MyBkYXRhIGhlYWRl ci4gIFdoZW4gcHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWUNCj4gPj4+Pj4gIChkZXNjcmliZWQg aW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIGNoZWNrIHRvDQo+ID4+IGVu c3VyZQ0KPiA+Pj4+PiAgdGhhdCBhbiBhcnJpdmluZyBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yIHRo ZSBpZGVudGlmaWVkIHNlc3Npb24uDQo+ID4+Pj4+ICBUaHVzLCB1c2Ugb2YgYSBDb29raWUgd2l0 aCB0aGUgU2Vzc2lvbiBJRCBwcm92aWRlcyBhbiBleHRyYQ0KPiA+Pj4+IGd1YXJhbnRlZQ0KPiA+ Pj4+PiAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZvcm1lZCBwcm9wZXJseSBh bmQgdGhhdCB0aGUNCj4gPj4+Pj4gIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3QgY29ycnVwdGVk IGluIHRyYW5zaXQuDQo+ID4+Pj4+IC0tLXNuaXAtLS0NCj4gPj4+Pj4gLi4uIGluIHJlZ2FyZCB0 byB0aGlzIHF1ZXN0aW9uIGFsb25lLCBJIGtub3cgdGhlIFNlY3VyaXR5IEFyZWENCj4gPj4gZm9s a3MNCj4gPj4+PiBoYXZlLCBpbiB0aGUNCj4gPj4+Pj4gcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8g Y29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXINCj4gPj4gSVANCj4gPj4+ PiB0cmFuc3BvcnQuDQo+ID4+Pj4+IEluIGZhY3QsIHRoaXMgaXMgd2h5IHlvdSBzZWUgdGV4dCBp biBTZWN0aW9uIDcuNiwgIlNlY3VyaXR5Iiwgb2YNCj4gPj4gUkZDDQo+ID4+Pj4gNDY2NS4NCj4g Pj4+Pj4gKFRoZXJlJ3MgbGlrZWx5IHNpbWlsYXIgbGFuZ3VhZ2UgaW4gb3RoZXIgZHJhZnRzIHRo YXQgdXNlIE1QTFMgZm9yDQo+ID4+Pj4gdHJhbnNwb3J0KS4NCj4gPj4+Pj4gV2hpbGUgSSdtIG5v dCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8NCj4g Pj4+PiBkYWlseSB0cmFmZmljIG9uDQo+ID4+Pj4+IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdCwg SSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGwNCj4gPj4+PiBhcmlzZSBpZi93 aGVuIHRoaXMNCj4gPj4+Pj4gZHJhZnQgZ29lcyB0byB0aGUgSUVTRyAuLi4NCj4gPj4+Pg0KPiA+ Pj4+IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSByZWFzb24gZm9yIHlvdXIgcHJl ZmVyZW5jZSBvZg0KPiA+PiBNUExTLQ0KPiA+Pj4+IGluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBp dCBoYXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdA0KPiA+PiBpcw0KPiA+Pj4+ IHNvIGNvbmNlcm5lZCwgY2FuIHlvdSBleHBsYWluIHdoeSBNUExTLWluLUdSRSBpcyBmYXIgbW9y ZSBwb3B1bGFyDQo+ID4+IHRoYW4NCj4gPj4+PiBNUExTLWluLUwyVFAgaW4gcHJhY3RpY2U/DQo+ ID4+Pj4NCj4gPj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4gWGlhb2h1DQo+ID4+Pj4NCj4gPj4+ Pj4gMykgRmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1z IHRoYXQNCj4gPj4gaW1wbGVtZW50DQo+ID4+Pj4gTDJUUCwgZm9yDQo+ID4+Pj4+IHR1bm5lbGlu ZyBvZiBNUExTL0lQLCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG8N Cj4gPj4+PiBzdXBwb3J0DQo+ID4+Pj4+IE1QTFMvVURQIGVuY2Fwc3VsYXRpb24gaW4gdGhlaXIg cHJvZHVjdCBsaW5lcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gLXNoYW5lDQo+ID4+Pj4+DQo+ID4+Pj4+ DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+Pj4gWGlhb2h1DQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4+IElmIHRoZXJlIHdhcyBtYXJrZXQgZGVtYW5kIGZvciBNUExTIG92ZXIg SVAsIHRoZW4gY2xlYXJseSBpdA0KPiA+PiB3b3VsZA0KPiA+Pj4+IGhhdmUNCj4gPj4+Pj4gYmVl bg0KPiA+Pj4+Pj4+IG1vcmUgd2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3Jz LCB3aXRoIGVpdGhlciBNUExTDQo+ID4+Pj4gb3Zlcg0KPiA+Pj4+PiBHUkUgb3INCj4gPj4+Pj4+ PiBNUExTIG92ZXIgTDJUUHYzLiAgKFdoZXJlIHRoZXJlJ3MgYSB3aWxsLCB0aGVyZSdzIGEgd2F5 KS4gIEkNCj4gPj4gd291bGQNCj4gPj4+PiBub3RlDQo+ID4+Pj4+IHRoYXQNCj4gPj4+Pj4+PiB0 aGUgbW9zdCBsaWtlbHkgcmVhc29ucyB0aGlzIGRpZCBub3QgcGFuIG91dCB3YXMgdGhlcmUgYXJl DQo+ID4+IHNldmVyYWwsDQo+ID4+Pj4gcHJhY3RpY2FsDQo+ID4+Pj4+Pj4gb3BlcmF0aW9uYWwg YmVuZWZpdHMgb25lIGdldHMgZnJvbSBnb2luZyB3aXRoIG5hdGl2ZSBNUExTDQo+ID4+Pj4+Pj4g ZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+ ID4+Pj4+Pj4gLSBNUExTIEZhc3QgUmUtUm91dGUNCj4gPj4+Pj4+PiAtIE1QTFMgVHJhZmZpYyBF bmdpbmVlcmluZw0KPiA+Pj4+Pj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZl IHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nDQo+ID4+Pj4+IGFyZ3VtZW50cw0KPiA+Pj4+ Pj4+IHRvICd1cGdyYWRlJyBuZXR3b3JrIEhXIHRvIHN1cHBvcnQgTVBMUyBlbmNhcHN1bGF0aW9u L3N3aXRjaGluZy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IC1zaGFuZQ0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4gLUpvc2gNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNv bS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+Pg0KPiA+Pj4+PiB3cm90ZToNCj4gPj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVy IElQIGlzIGxlZ2FjeSBhbmQgdGhlcmUNCj4gPj4gaXMNCj4gPj4+PiBubyBuZWVkDQo+ID4+Pj4+ Pj4+PiB0byBpbXByb3ZlIGl0Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+ ID4+Pj4+Pj4+PiBTaGFocmFtDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ IE9uIERlYyAxNywgMjAxMiwgYXQgODowMiBQTSwgIlh1eGlhb2h1IiA8eHV4aWFvaHVAaHVhd2Vp LmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaGFocmFtLA0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4g VGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVANCj4g Pj4+PiBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9h ZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8NCj4gPj4+PiB0aG9zZQ0KPiA+Pj4+ Pj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMg YXBwbGljYXRpb24NCj4gPj4+PiB0cmFmZmljDQo+ID4+Pj4+Pj4+Pj4gYWNyb3NzIElQIG5ldHdv cmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUNCj4gPj4gYW5kDQo+ ID4+Pj4+IFZYTEFODQo+ID4+Pj4+Pj4+Pj4gZWFjaCBoYXZlIHRoZWlyIG93biBhZHZvY2F0b3Jz IGFuZCB1c2UgY2FzZXMuIElmIHlvdQ0KPiA+PiBhYnNvbHV0ZWx5DQo+ID4+Pj4gYmVsaWV2ZQ0K PiA+Pj4+Pj4+Pj4+IGl0J3MgbWVhbmluZ2xlc3Mgb2YgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGlj YXRpb24gdHJhZmZpYw0KPiA+Pj4+IGFjcm9zcyBJUA0KPiA+Pj4+Pj4+Pj4+IG5ldHdvcmtzIGFu ZCB0aGVyZWZvcmUgdGhvc2UgZXhpc3RpbmcgUkZDcyByZWxhdGVkIHRvIE1QTFMNCj4gPj4gb3Zl cg0KPiA+Pj4+IElQDQo+ID4+Pj4+Pj4+Pj4gdHVubmVsaW5nIG1lY2hhbmlzbXMgc2hvdWxkIGJl IG1vdmVkIHRvIEhpc3RvcmljIHN0YXR1cywNCj4gPj4gcGxlYXNlDQo+ID4+Pj4gc2F5DQo+ID4+ Pj4+IHNvLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gQnkgdGhlIHdheSwgaXQgc2VlbXMg dGhpcw0KPiA+Pj4+Pj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ID4+Pj4gYXJj aGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ID4+Pj4+Pj4+Pj4ganVz dCB0aGUgcmlnaHQgdGhyZWFkIHN1aXRhYmxlIGZvciB5b3UgdG8gbWFrZSB0aGUgZm9sbG93aW5n DQo+ID4+Pj4gYXJndW1lbnQNCj4gPj4+Pj4+Pj4+PiAoaS5lLiwgd2hldGhlciBvciBub3QgTVBM Uy1iYXNlZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhDQo+ID4+Pj4gY2VudGVycykuIEkNCj4g Pj4+Pj4+Pj4+PiBoYWQgdGhvdWdodCB5b3Ugd291bGQgc3BlYWsgdXAgYXQgdGhhdCB0aW1lLiBT YWRseSwNCj4gPj4+PiBzdXJwcmlzaW5nbHkgc2lsZW50DQo+ID4+Pj4+Pj4+Pj4gdGlsbCBub3cu DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5 IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBYaWFvaHUN Cj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4+Pj4+ Pj4+Pj4gt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZz5dDQo+ID4+ILT6DQo+ID4+Pj4gse0NCj4gPj4+Pj4+PiBTLg0KPiA+Pj4+Pj4+ Pj4+PiBEYXZhcmkNCj4gPj4+Pj4+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIxNcjVIDEzOjM0 DQo+ID4+Pj4+Pj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPiA+Pj4+Pj4+Pj4+PiCzrcvN OiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPjsNCj4gPj4+Pj4+Pj4+Pj4gbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+PiDW98ziOiBSZTogW21wbHNd IHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+ID4+Pj4+Pj4+Pj4+IGRy YWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+ID4+Pj4+Pj4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBk b2N1bWVudA0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBJIGRvbid0IHN1cHBvcnQgdGhp cyBkcmFmdCBzaW5jZSBpdCBoYXMgbm8gYXBwbGljYXRpb24gaW4NCj4gPj4+PiB0b2RheSdzDQo+ ID4+Pj4+Pj4+Pj4+IG1vZGVybiBtZXRybw0KPiA+Pj4+Pj4+Pj4+PiBhbmQgY29yZSwgd2hlcmUg TVBMUyBpcyBkb21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0aWNhbA0KPiA+Pj4+IGFwcGxpY2F0 aW9uDQo+ID4+Pj4+Pj4+Pj4+IGluIGluIGRhdGENCj4gPj4+Pj4+Pj4+Pj4gY2VudGVyLCB3aGlj aCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcw0KPiA+Pj4+ IE5WR1JFDQo+ID4+Pj4+IGFuZA0KPiA+Pj4+Pj4+Pj4+PiBWWExBTi4NCj4gPj4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+Pj4gSXQgc2VlbXMgdGhlIGF1dGhvcnMgYXJlIHRyeWluZyB0byBieXBhc3Mg dGhlIE5WTzMgc29sdXRpb24NCj4gPj4+PiBzZWxlY3Rpb24NCj4gPj4+Pj4+Pj4+Pj4gcHJvY2Vz cw0KPiA+Pj4+Pj4+Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+ID4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+ID4+Pj4+Pj4+Pj4+IFNoYWhyYW0N Cj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gT24gRGVjIDE0LCAy MDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gV29ya2luZyBncm91cCwN Cj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIGlzIHRvIHN0YXJ0IGEgInR3byB3 ZWVrIiBwb2xsIG9uIGFkb3B0aW5nDQo+ID4+Pj4+Pj4+Pj4+PiBkcmFmdC14dS1tcGxzLWluLXVk cC0wNiBhcyBhbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4+PiBE dWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRo DQo+ID4+Pj4gb25lIHdlZWsuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gUGxlYXNl IHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMNCj4g Pj4+Pj4gd29ya2luZw0KPiA+Pj4+Pj4+Pj4+Pj4gZ3JvdXAgbWFpbGluZyBsaXN0IChtcGxzIGF0 IGlldGYub3JnPGh0dHA6Ly9pZXRmLm9yZz4pLiBQbGVhc2UgZ2l2ZSBhbg0KPiA+Pj4+IHRlY2hu aWNhbA0KPiA+Pj4+Pj4+Pj4+Pj4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBw b3J0LCBlc3BlY2lhbGx5IGlmIHlvdQ0KPiA+Pj4+IHRoaW5rIHRoYXQNCj4gPj4+Pj4+Pj4+Pj4+ IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwDQo+ ID4+Pj4gZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBwb2xs IGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBU aGVyZSBpcyBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCAtDQo+ID4+Pj4+Pj4+ Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+ID4+Pj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gQWxsIHRoZSBhY3RpdmUgY28tYXV0aG9ycyBoYXMgc3RhdGVk IG9uIHRoZSB3b3JraW5nIGdyb3VwDQo+ID4+Pj4gbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4+ PiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWltcyB0aGFuIHRo b3NlDQo+ID4+Pj4gYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4+Pj4gZGlzY2xvc2VkLg0KPiA+Pj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEhvd2V2ZXIsIHVwIHRvIHZlcnNpb24gLTAzICh0aGUgZG9j dW1lbnQgdGhhdCB3ZSB1c2VkIGZvcg0KPiA+PiB0aGUNCj4gPj4+PiBJUFINCj4gPj4+Pj4+Pj4+ Pj4+IHBvbGwpDQo+ID4+Pj4+Pj4+Pj4+PiBNYXJzaGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMg b25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbA0KPiA+Pj4+IGhhcw0KPiA+Pj4+Pj4+Pj4+Pj4g ZGlzY29udGludWVkIGFsbCBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgSUVURiwgaW5jbHVkaW5nIHRo ZQ0KPiA+Pj4+IGF1dGhvciB0ZWFtDQo+ID4+Pj4+Pj4+Pj4+PiBvZiBkcmFmdC14dS1tcGxzLWlu LXVkcC0wNi4gVGhlIHdvcmtpbmcgZ3JvdXAgY2hhaXJzIGhhcw0KPiA+Pj4+IHRyaWVkIHRvDQo+ ID4+Pj4+Pj4+Pj4+PiBjb250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0 IGEgcmVzcG9uc2Ugb24NCj4gPj4gdGhlDQo+ID4+Pj4gSVBSDQo+ID4+Pj4+Pj4+Pj4+PiBwb2xs Lg0KPiA+Pj4+Pj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPiA+Pj4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEZyb20gdmVyc2lvbiAtMDQgdGhlIGF1dGhvcnMgZGVj aWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYQ0KPiA+Pj4+Pj4+Pj4+Pj4gY28tYXV0aG9yLg0K PiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IC9Mb2ENCj4gPj4+Pj4+Pj4+Pj4+IChtcGxz IHdnIGNvLWNoYWlyKQ0KPiA+Pj4+Pj4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOg0KPiA+Pj4+Pj4+Pj4+PiBsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbTxtYWls dG86bG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb20+DQo+ID4+Pj4+Pj4+Pj4+PiBTciBTdHJhdGVn eSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBw aS5udT4NCj4gPj4+Pj4+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAg ICAgcGhvbmU6ICs0NiAxMCA3MTcNCj4gNTINCj4gPj4gMTMNCj4gPj4+Pj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTINCj4gMTMNCj4g Pj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+Pj4gbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+PiBt cGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPj4+Pj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+ PiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGlzIEUtbWFp bCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lcg0KPiA+ Pj4+IENhYmxlDQo+ID4+Pj4+Pj4gcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHBy aXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3INCj4gPj4+PiBzdWJqZWN0IHRvDQo+ID4+Pj4+Pj4g Y29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMg aW50ZW5kZWQNCj4gPj4+PiBzb2xlbHkgZm9yDQo+ID4+Pj4+IHRoZQ0KPiA+Pj4+Pj4+IHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5 b3UNCj4gPj4+PiBhcmUgbm90IHRoZQ0KPiA+Pj4+Pj4+IGludGVuZGVkIHJlY2lwaWVudCBvZiB0 aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdA0KPiA+Pj4+IGFueQ0KPiA+ Pj4+PiBkaXNzZW1pbmF0aW9uLA0KPiA+Pj4+Pj4+IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3Ig YWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZQ0KPiA+PiBjb250ZW50cw0KPiA+Pj4+IG9m IGFuZA0KPiA+Pj4+Pj4+IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZQ0KPiA+Pj4+IHVubGF3ZnVsLiBJZiB5b3UNCj4gPj4+Pj4+PiBo YXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXINCj4gPj4+PiBpbW1lZGlhdGVseSBhbmQNCj4gPj4+Pj4+PiBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQNCj4gPj4+PiBhbnkg cHJpbnRvdXQuDQo+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBtcGxzIG1haWxpbmcg bGlzdA0KPiA+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0K PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscw0KDQo= --_000_814D9C1492114EDD8C2A564FDB7F5D78broadcomcom_ Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable
MPLS based VPN supports multicast Tree, but only when Transport is MPL= S and not IP. MPLS over IP does not support Multicast tree. 

Regards,
Shahram


On Dec 23, 2012, at 6:32 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:

 = ;

 = ;

=B7=A2=BC=FE=C8= =CB: S. Davari [mailto:da= varish@yahoo.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C222=C8=D5 = 6:40
=CA=D5=BC=FE=C8=CB: Lucy yong; Xuxiaohu; Shahram Davari
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] MPLS client layer over an IGP underlying network

 

Lucy,

I can only see China Telecom as co-author, and the Applicability section sa= ys L2VPN and L3VPN. So is China Telecom using it for their Enterprise VPN s= ervice? but your earlier emails suggests that this is not the intended usag= e rather it is for Data Center. So which one is it? Why isn't China Telecom speaking on the list and expla= ining their usage model?

[Xiaohu] Yes, the Applicability secti= on says L2VPN and L3VPN, but there is no limit that these technologies could only be used by service providers?  Enterprises themselves coul= d adopt these technologies to interconnect their multiple sites and data ce= nter operators could use them within or even across data centers as well if= they would like. Let me iterate that MPLS-based VPN over IP can be used in SP networks, enterprise networks and= even data centers and therefore MPLS-in-UDP is applicable to any of the ab= ove scenario as well.


Also regarding Multicast, this means you need to map Multicast traffic to P= 2P PW, which is inferior to other methods such as NVGRE and VXLAN since the= y natively support efficient Multicast.

[Xiaohu] First, remember that MPLS-in= -UDP is not only suitable for MPLS-based L2VPN but also suitable for L3VPN. Second, MPLS-based VPN can support both ingress replication mod= e and multicast tree mod


Thanks,
Shahram

 

 

From: Lucy= yong <lucy.yong@huawei.com&= gt;
To: S. Davari <davarish@yah= oo.com>; Xuxiaohu <xuxiaoh= u@huawei.com>; Shahram Davari <davari@broadcom.com>
Cc: "dra= ft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>; &qu= ot;mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Sent: Friday, December 21, 2012 1:55:10 PM
Subject: RE: [mpls] MPLS client layer over an IGP underlying network=



Shahram,

 

Please see inline.

 

 

Hi,

I think we are in a vicious cycle. Could you please clarify which network o= perator is asking for MPLS over UDP and what is the application. 

[Lucy] it is indicated in the draft.

Also how do you plan to address the MPLS Multicast (which is probably more= important than improving the load balancing), given that RFC4023 does not support Multicast.

[Lucy] MPLS Client Layer is responsible to map mu= lticast traffic to underlying transport, which is specified in EVPN and IP VPN. This proposal just requests ingress PE to fill the flo= w entropy into UDP source port, in which the flow can be unicast or multica= st.

 =

Regards,=

Lucy

 =



Thanks,
Shahram

 

 

From: Xuxiaohu <xuxiaohu@huawei.com>
To: Shahram Davari <davari= @broadcom.com>; Lucy yong <lucy.yong@huawei.com>
Cc: "dra= ft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>; &qu= ot;mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Sent: Thursday, December 20, 2012 5:56:23 PM
Subject: Re: [mpls] MPLS client layer over an IGP underlying network=




> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
> Shahram Davari
> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C221=C8=D5 1:31
> =CA=D5=BC=FE=C8=CB: Lucy yong
> =B3=AD=CB=CD: dr= aft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs= @tools.ietf.org;
> mpls@ietf.org > =D6=F7=CC=E2: Re: [mpls] MPLS client layer over an IGP underlying network
>
> Please don't mix up things. The MPLS protocol design I agree must be d= one by
> MPLS WG. But the question is whether your proposal meets the network > virtualization requirements.

Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over IP encap= sulation mechanisms have been discussed before?

Since MPLS-in-UDP is just intended to be used in the scenarios where MPLS-i= n-GRE/IP has been used and is to be used, MPLS-in-UDP should be discussed i= n the same WG where MPLS-in-GRE/IP has been discussed.

Xiaohu

> The NVO3 task is to document the issues, requirements and framework fo= r
> NvO3. Then if MPLS over IP looks like a suitable solution that meets t= he
> requirements such as the scale, mobility, etc, then they will ask MPLS= WG for
> protocol design.
>
> So before proceeding this draft, I think you should take it to NVO3 WG= and
> convince them this solution meets their requirements and framework. >
> We don't want IETF do design N number of solutions for the same proble= m, do
> we?
>
> -Shahram
>
>
>
> Regards,
> Shahram
>
>
> On Dec 20, 2012, at 8:56 AM, "Lucy yong" <lucy.yong@huawei.com> wro= te:
>
> > Network virtualization overlay is discussed under nvo3 WG. This d= oes not
> mean that nvo3 WG has to design a new protocol for a underlying networ= k or a
> new protocol for a overlay network. In fact, people there aim on lever= age
> standard network protocols to accomplish them. IMO: these expansions o= n an
> existing standard protocol have to be worked out in the protocol WG gr= oup, it
> should not give nvo3 WG free right to enhance these protocols. For a b= rand
> new protocol for network virtualization overlay, nvo3 WG may be the pl= ace to
> start.
> >
> > Lucy
> >
> >> -----Original Message-----
> >> From: Shahram Davari [mailto:davari@broadcom.com]
> >> Sent: Thursday, December 20, 2012 10:34 AM
> >> To: Lucy yong
> >> Cc: Shane Amante; draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
> >> mpls-chairs@tools.ietf.org
> >> Subject: Re: [mpls] MPLS client layer over an IGP underlying = network
> >>
> >> Network virtualization overlay must be discussed and consente= d  in NVO3
> >> WG.
> >>
> >> Regards,
> >> Shahram
> >>
> >>
> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
> >>
> >>> Hi Shane,
> >>>
> >>> I understand operator concern on a new encapsulation to a= n existing
> >> network.
> >>>
> >>> However, MPLS-in-UDP does not aim on changing existing SP= IP/MPLS
> >> network at all.
> >>> MPLS-in-UDP is to enable MPLS client layer to be decouple= d from MPLS
> >> server layer and use MPLS client layer as overlay network and= an IGP as
> >> a underlying network for transport. Such application is for D= C. You may
> >> argue why not use the GRE which is for MPLS layer over an IGP= underling
> >> network. We have pointed out in the draft that current router= s in DC
> >> barely support GRE based load balancing and MPLS-in-GRE are b= arely used
> >> in SP networks too. Most of routers in DC perform upd port ba= sed load
> >> balancing now.
> >>>
> >>> From the architecture perspective, the UDP encapsulation = has
> >> advantage over GRE encapsulation too. In UDP encapsulation, t= he frame
> >> header decouples the overlay and underlying network clearly, = i.e. outer
> >> header and overlay header. UDP belongs to outer header, which=
> >> underlying network uses only. However, GRE header has the fie= lds for
> >> the overlay network and uses the key field for flow entropy. = For load
> >> balancing, it requires the underlying network uses GRE header= too. In
> >> short, GRE ties the overlay and underlying networks together.= Since it
> >> has not used a lot, people are not aware of the disadvantage = of such
> >> coupling.
> >>>
> >>> As the industry moves toward network virtualization overl= ay and
> >> decouples overlay networks from the underlying network. A cle= ar
> >> separation of overlay header and underlying header is a "= ;MUST" in my
> >> opinion. If we count GRE as the overlay header, then for IPv4=
> >> underlying network, there is no field for the flow entropy. T= his is the
> >> reason we propose the UDP encapsulation: for an IGP based und= erlying
> >> network. In fact, it can support any overlay network beside M= PLS client
> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >>>
> >>> You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPL= S-in-L2TP-
> >> in-UDP schema also provides a overlay (L2TP) and underlying (= IP)
> >> network decoupling. L2TP protocol (rfc3931) provides good sec= urity
> >> mechanism and has the embedded control function too. Therefor= e,
> someone
> >> can use it for MPLS client layer over Internet. To have MPLS = client
> >> layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP= is a
> >> overkill and too complex. Here we need a schema to support IG= P
> >> underlying transport without touching a overlay header. UDP > >> encapsulation is the best choice to accomplish that and minim= ize the
> >> changes on existing routers, e.g. change at edge routers, no = change on
> >> transit routers.
> >>>
> >>> Regards,
> >>> Lucy
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> >>>> Sent: Thursday, December 20, 2012 4:14 AM
> >>>> To: Shane Amante
> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in- > >> udp@t= ools.ietf.org;
> >>>> mp= ls@ietf.org; mpls-chairs@tools.ietf.org
> >>>> Subject: Discussion on how to transport MPLS over UDP= tunnels
> >>>>
> >>>> Hi Shane,
> >>>>
> >>>> Thanks for your further comments and please see my re= sponse inline.
> >>>>
> >>>> Note: I changed the subject line according to Loa's s= uggestion.
> >>>>
> >>>>> -----=D3=CA=BC= =FE=D4=AD=BC=FE-----
> >>>>> =B7=A2=BC=FE= =C8=CB: Shane Amante [mailto:shane@castlepoint.net] > >>>>> =B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 22:38
> >>>>> =CA=D5=BC=FE= =C8=CB: Xuxiaohu
> >>>>> =B3=AD=CB=CD: Rogers, Josh; Shahram Davari; draft-xu-mpl= s-in-
> >>>> udp@tools.ietf.org;
> >>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support = to make draft-xu-
> >>>> mpls-in-udp an
> >>>>> mpls working group document
> >>>>>
> >>>>> Xiaohu,
> >>>>>
> >>>>> On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com&= gt;
> wrote:
> >>>>> -----=D3=CA=BC= =FE=D4=AD=BC=FE-----
> >>>>>>> =B7=A2= =BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net]
> >>>>>>> =B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
> >>>>>>> =CA=D5= =BC=FE=C8=CB: Rogers, Josh
> >>>>>>> =B3=AD= =CB=CD: Shahram Davari; Xuxiaohu; draft-xu= -mpls-in-
> >>>> udp@tools.ietf.org;
> >>>>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>>>>> =D6=F7= =CC=E2: Re: [mpls] poll to see if we have = support to make draft-xu-
> >>>> mpls-in-udp
> >>>>> an
> >>>>>>> mpls working group document
> >>>>>>>
> >>>>>>>
> >>>>>>> On Dec 18, 2012, at 8:50 AM, "Rogers= , Josh"
> >>>> <josh.rogers@twcable.com>
> >>>>>>> wrote:
> >>>>>>>> I share your SP perspective, and do n= ot see the problem this
> >>>> solution
> >>>>>>>> addresses in practice any longer.
> >>>>>>>
> >>>>>>> +1.  Please do not define yet an= other MPLS-over-IP encapsulation.
> >>>> The
> >>>>> IETF
> >>>>>>> already standardized MPLS over GRE. = The IETF has also
> >>>> standardized
> >>>>> MPLS
> >>>>>>> over L2TPv3/UDP/IP, which had seen some d= eployment in at least
> >> one,
> >>>> very
> >>>>>>> large operator network that I'm aware of = to support carriage of
> >>>> L3VPN over
> >>>>> an
> >>>>>>> IP-only network.
> >>>>>>
> >>>>>> Hi Shane,
> >>>>>>
> >>>>>> Thank you for telling us there are actual dep= loyments of MPLS over
> >>>> IP in at
> >>>>> least one, very large operator network. This fact= must be very
> >>>> valuable to those
> >>>>> people who had believed there is no application o= f MPLS over IP in
> >>>> today's SP
> >>>>> networks.
> >>>>>>
> >>>>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE= 3 over L2TPv3
> >>>>>>> [NOTE: the dates the above were published= was back in the 2006
> >>>>> timeframe!]
> >>>>>>>  RFC 4665 for requirements related t= o VPLS that say that VPLS
> >>>> may be
> >>>>>>> carried over L2TPv3
> >>>>>>>  And, here's evidence showing that a= t least one vendor has
> >>>>> implemented
> >>>>>>> IPVPN's over L2TPv3:
> >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html <= br> > >>>>>>
> >>>>>> Thanks again for sharing the above informatio= n. As mentioned in
> >>>> this draft
> >>>>> AND other drafts, the mechanism of performing has= h calculation on
> >> the
> >>>> Session
> >>>>> ID field in the L2TPv3 header or the Key field in= the GRE header as
> >>>> defined in
> >>>>> [RFC 5640] is not widely supported by existing co= re routers so far.
> >>>>>
> >>>>> FWIW, I have had success, in the relatively recen= t past, in
> >>>> requesting a core
> >>>>> router vendor to support changes to the input-key= s used in hash
> >>>> calculations in
> >>>>> _existing_ hardware, already deployed (extensivel= y) throughout my
> >>>> network.
> >>>>> Further, I suspect that most large network operat= ors are savvy
> >> folks
> >>>> and
> >>>>> understand the internal architecture of their HW = fairly well.  As a
> >>>> result, those
> >>>>> same operators know what is and is not technicall= y possible in this
> >>>> regard.
> >>>>> Thus, it may be a question of "methods"= necessary to convince their
> >>>> HW
> >>>>> supplier(s) to make appropriate changes in their = equipment to
> >> achieve
> >>>> their
> >>>>> business goals.  :-)  However, this may= not even be necessary ...
> >> see
> >>>> below.
> >>>>
> >>>> Could you please briefly explain how to make the abov= e change in
> >>>> EXISTING hardware of already deployed core routers? > >>>>
> >>>>>> In contrast, most existing core routers are a= lready capable of
> >>>> balancing IP
> >>>>> traffic flows based on the hash of the five-tuple= of UDP packets.
> >> By
> >>>> using the
> >>>>> MPLS-in-UDP encapsulation, the already available = load-balancing
> >>>> capability of
> >>>>> most existing core routers can be leveraged witho= ut requiring any
> >>>> change to
> >>>>> them. That is the major motivation of this draft.=
> >>>>>
> >>>>> If this is a concern, then why not encapsulate th= e traffic in
> >>>> MPLS/L2TPv3, which
> >>>>> uses UDP/IP, in the first place?
> >>>>
> >>>> If I understand it correctly, you prefer to use MPLS-= in-L2TPv3-in-
> >> UDP
> >>>> instead of MPLS-in-UDP, right?
> >>>>
> >>>>> IMHO, a better proposal may be to consider a [min= or] (?) change to
> >>>> RFC 3931,
> >>>>> which would allow the connection used for data pa= ckets (not control
> >>>> packets)
> >>>>> to use a varying set of source ports (or, source = IP addresses),
> >> based
> >>>> on a hash
> >>>>> calculation, to achieve better load-balancing ove= r existing
> >> equipment
> >>>> in an
> >>>>> IP-only core.  L2TP end-system implementatio= ns would be better off
> >>>> just using
> >>>>> the "Session ID" (and "Cookie"= ;) fields as the demultiplexor to
> >>>> associate
> >>>>> incoming packets with the associated L2TP Control= Channel.  In fact,
> >>>> it's not
> >>>>> clear to me that existing implementations may /al= ready/ do this,
> >>>> making any
> >>>>> "check" on the incoming source port unn= ecessary for L2TP end-system
> >>>>> implementations.
> >>>>>
> >>>>> The beauty of the above approach is:
> >>>>> 1) I would think that the above is most likely a = change that is
> >>>> limited to the
> >>>>> "control channel" (software) of existin= g L2TP end-system
> >>>> implementations.
> >>>>> Heck, it may even be backwards compatible with ex= isting L2TPv3
> >>>>> implementations.  (L2TPv3 implementors would= need to comment on
> >> that).
> >>>>
> >>>> IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,=   the hardware
> >> of
> >>>> PE routers needs to be upgraded, e.g., ingress PE rou= ters need to
> >> fill
> >>>> in an entropy value in the source port field of UDP h= eaders.
> >>>>
> >>>>> 2) There is a substantial added security one gets= by using "Session
> >>>> ID" and
> >>>>> "Cookie" fields to ensure the received = L2TPv3 packet is intended
> >> for
> >>>> the
> >>>>> identified session.  Quoting from Section 8.= 2 of RFC 3931:
> >>>>> ---snip---
> >>>>>  L2TPv3 provides traffic separation for its = VPNs via a 32-bit
> >>>> Session
> >>>>>  ID in the L2TPv3 data header.  When pr= esent, the L2TPv3 Cookie
> >>>>>  (described in Section 4.1), provides an add= itional check to
> >> ensure
> >>>>>  that an arriving packet is intended for the= identified session.
> >>>>>  Thus, use of a Cookie with the Session ID p= rovides an extra
> >>>> guarantee
> >>>>>  that the Session ID lookup was performed pr= operly and that the
> >>>>>  Session ID itself was not corrupted in tran= sit.
> >>>>> ---snip---
> >>>>> ... in regard to this question alone, I know the = Security Area
> >> folks
> >>>> have, in the
> >>>>> past, had /substantial/ concerns about encapsulat= ion of MPLS over
> >> IP
> >>>> transport.
> >>>>> In fact, this is why you see text in Section 7.6,= "Security", of
> >> RFC
> >>>> 4665.
> >>>>> (There's likely similar language in other drafts = that use MPLS for
> >>>> transport).
> >>>>> While I'm not sure that Security Area folks pay m= uch attention to
> >>>> daily traffic on
> >>>>> the MPLS WG mailing list, I'm fairly confident th= is concern will
> >>>> arise if/when this
> >>>>> draft goes to the IESG ...
> >>>>
> >>>> If I understand it correctly, the reason for your pre= ference of
> >> MPLS-
> >>>> in-L2TPv3-in-UDP is that it has an added security fea= ture. If that
> >> is
> >>>> so concerned, can you explain why MPLS-in-GRE is far = more popular
> >> than
> >>>> MPLS-in-L2TP in practice?
> >>>>
> >>>> Best regards,
> >>>> Xiaohu
> >>>>
> >>>>> 3) Finally, this approach only affects the end-sy= stems that
> >> implement
> >>>> L2TP, for
> >>>>> tunneling of MPLS/IP, and does not require an ent= ire industry to
> >>>> support
> >>>>> MPLS/UDP encapsulation in their product lines. > >>>>>
> >>>>> -shane
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Xiaohu
> >>>>>>
> >>>>>>> If there was market demand for MPLS over = IP, then clearly it
> >> would
> >>>> have
> >>>>> been
> >>>>>>> more widely implemented by equipment vend= ors, with either MPLS
> >>>> over
> >>>>> GRE or
> >>>>>>> MPLS over L2TPv3.  (Where there's a = will, there's a way).  I
> >> would
> >>>> note
> >>>>> that
> >>>>>>> the most likely reasons this did not pan = out was there are
> >> several,
> >>>> practical
> >>>>>>> operational benefits one gets from going = with native MPLS
> >>>>>>> encapsulation/switching within the data p= lane, namely:
> >>>>>>> - MPLS Fast Re-Route
> >>>>>>> - MPLS Traffic Engineering
> >>>>>>> ... to name, but a few.  Those have = tended to be quite compelling
> >>>>> arguments
> >>>>>>> to 'upgrade' network HW to support MPLS e= ncapsulation/switching.
> >>>>>>>
> >>>>>>> -shane
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Josh
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/18/12 12:31 AM, "Shahram D= avari" <da= vari@broadcom.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> For service provider domain, MPLS= over IP is legacy and there
> >> is
> >>>> no need
> >>>>>>>>> to improve it.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Shahram
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 17, 2012, at 8:02 PM, &quo= t;Xuxiaohu" <xuxiaohu@huawei.com>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Shahram,
> >>>>>>>>>>
> >>>>>>>>>> This draft is ONLY intended t= o provide a MPLS-over-IP
> >>>> encapsulation
> >>>>>>>>>> method with a better load-bal= ancing applicability so far to
> >>>> those
> >>>>>>>>>> operators who happen to requi= re transporting MPLS application
> >>>> traffic
> >>>>>>>>>> across IP networks. I believe= MPLS-based VPN over IP, NVGRE
> >> and
> >>>>> VXLAN
> >>>>>>>>>> each have their own advocator= s and use cases. If you
> >> absolutely
> >>>> believe
> >>>>>>>>>> it's meaningless of transport= ing MPLS application traffic
> >>>> across IP
> >>>>>>>>>> networks and therefore those = existing RFCs related to MPLS
> >> over
> >>>> IP
> >>>>>>>>>> tunneling mechanisms should b= e moved to Historic status,
> >> please
> >>>> say
> >>>>> so.
> >>>>>>>>>>
> >>>>>>>>>> By the way, it seems this
> >>>>>>>>>> (http://www.ietf.org/mail-
> >>>> archive/web/nvo3/current/msg01864.html) is
> >>>>>>>>>> just the right thread suitabl= e for you to make the following
> >>>> argument
> >>>>>>>>>> (i.e., whether or not MPLS-ba= sed VPN is applicable to data
> >>>> centers). I
> >>>>>>>>>> had thought you would speak u= p at that time. Sadly,
> >>>> surprisingly silent
> >>>>>>>>>> till now.
> >>>>>>>>>>
> >>>>>>>>>> Sigh, I didn't intend to say = the above otherwise.
> >>>>>>>>>>
> >>>>>>>>>> Xiaohu
> >>>>>>>>>>
> >>>>>>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
> >>>>>>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org]
> >> =B4=FA
> >>>> =B1=ED
> >>>>>>> S.
> >>>>>>>>>>> Davari
> >>>>>>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12<= /span>=D4=C2= 15=C8=D5 13:34
> >>>>>>>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersso= n
> >>>>>>>>>>> =B3=AD=CB=CD: dr= aft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
> >>>>>>>>>>> mpls-chairs@tools.ietf.org
> >>>>>>>>>>> =D6=F7=CC=E2: Re: [mpls] poll to= see if we have support to make
> >>>>>>>>>>> draft-xu-mpls-in-udp an > >>>>>>>>>>> mpls working group docume= nt
> >>>>>>>>>>>
> >>>>>>>>>>> I don't support this draf= t since it has no application in
> >>>> today's
> >>>>>>>>>>> modern metro
> >>>>>>>>>>> and core, where MPLS is d= ominant, and its only practical
> >>>> application
> >>>>>>>>>>> in in data
> >>>>>>>>>>> center, which already is = crowded with other solutions such as
> >>>> NVGRE
> >>>>> and
> >>>>>>>>>>> VXLAN.
> >>>>>>>>>>>
> >>>>>>>>>>> It seems the authors are = trying to bypass the NVO3 solution
> >>>> selection
> >>>>>>>>>>> process
> >>>>>>>>>>> by advancing the draft in= MPLS WG.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Shahram
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 14, 2012, at 1:01 = AM, Loa Andersson <loa@pi= .nu> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Working group,
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is to start a &q= uot;two week" poll on adopting
> >>>>>>>>>>>> draft-xu-mpls-in-udp-= 06 as an MPLS working group document.
> >>>>>>>>>>>> Due to the holiday se= ason this poll has been extended with
> >>>> one week.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please send your comm= ents (support/not support) to the mpls
> >>>>> working
> >>>>>>>>>>>> group mailing list (m= pls at ietf.org). Please give an
> >>>> technical
> >>>>>>>>>>>> motivation for your s= upport/not support, especially if you
> >>>> think that
> >>>>>>>>>>>> the document should n= ot be adopted as a working group
> >>>> document.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This poll ends Januar= y 07, 2013.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There is one IPR clai= m against this document -
> >>>>>>>>>>>> https://datatracker.ietf.or= g/ipr/1941/ .
> >>>>>>>>>>>>
> >>>>>>>>>>>> All the active co-aut= hors has stated on the working group
> >>>> mailing list
> >>>>>>>>>>>> that they are not awa= re of any other IPR claims than those
> >>>> already
> >>>>>>>>>>>> disclosed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> However, up to versio= n -03 (the document that we used for
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll)
> >>>>>>>>>>>> Marshall Eubanks was = listed as one of the authors. Marshall
> >>>> has
> >>>>>>>>>>>> discontinued all inte= ractions with the IETF, including the
> >>>> author team
> >>>>>>>>>>>> of draft-xu-mpls-in-u= dp-06. The working group chairs has
> >>>> tried to
> >>>>>>>>>>>> contact Marshall by o= ther means, to try get a response on
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll.
> >>>>>>>>>>>> We have had no succes= s in this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> From version -04 the = authors decided to remove Marshall as a
> >>>>>>>>>>>> co-author.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Loa
> >>>>>>>>>>>> (mpls wg co-chair) > >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Loa Andersson  &= nbsp;                    = email:
> >>>>>>>>>>> loa.andersson@ericsson.com
> >>>>>>>>>>>> Sr Strategy and Stand= ards Manager            loa@pi.nu
> >>>>>>>>>>>> Ericsson Inc  &n= bsp;                     =   phone: +46 10 717
> 52
> >> 13
> >>>>>>>>>>>>      &= nbsp;                    =             +46 767 72 92
> 13
> >>>>>>>>>>>> _____________________= __________________________
> >>>>>>>>>>>> mpls mailing list
> >>>>>>>>>>>> mpls@ietf.org
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>>> _________________________= ______________________
> >>>>>>>>>>> mpls mailing list
> >>>>>>>>>>> mpls@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>> _____________________________= __________________
> >>>>>>>>>> mpls mailing list
> >>>>>>>>>> mpls@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>> _________________________________= ______________
> >>>>>>>>> mpls mailing list
> >>>>>>>>> mpls@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This E-mail and any of its attachment= s may contain Time Warner
> >>>> Cable
> >>>>>>> proprietary information, which is privile= ged, confidential, or
> >>>> subject to
> >>>>>>> copyright belonging to Time Warner Cable.= This E-mail is intended
> >>>> solely for
> >>>>> the
> >>>>>>> use of the individual or entity to which = it is addressed. If you
> >>>> are not the
> >>>>>>> intended recipient of this E-mail, you ar= e hereby notified that
> >>>> any
> >>>>> dissemination,
> >>>>>>> distribution, copying, or action taken in= relation to the
> >> contents
> >>>> of and
> >>>>>>> attachments to this E-mail is strictly pr= ohibited and may be
> >>>> unlawful. If you
> >>>>>>> have received this E-mail in error, pleas= e notify the sender
> >>>> immediately and
> >>>>>>> permanently delete the original and any c= opy of this E-mail and
> >>>> any printout.
> >>>>>>>> _____________________________________= __________
> >>>>>>>> mpls mailing list
> >>>>>>>> mpls@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/m= pls
> >>>
> >>> _______________________________________________
> >>> mpls mailing list
> >>> mpls@i= etf.org
> >>> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_814D9C1492114EDD8C2A564FDB7F5D78broadcomcom_-- From xuxiaohu@huawei.com Sun Dec 23 18:53:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EF621F842B for ; Sun, 23 Dec 2012 18:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.884, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfJ8K9uaseRa for ; Sun, 23 Dec 2012 18:53:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9072121F8425 for ; Sun, 23 Dec 2012 18:53:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOC58005; Mon, 24 Dec 2012 02:53:53 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 02:53:37 +0000 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 10:53:51 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Mon, 24 Dec 2012 10:53:40 +0800 From: Xuxiaohu To: "Andrew G. Malis" , Lucy yong Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3Olzo1M6JwDPXkycxIud0O1KBJgeLvSAgADLHACAAKzhwIAABiEAgANl/ICAAA9vAIAAByGAgAQcN6A= Date: Mon, 24 Dec 2012 02:53:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9B6@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> 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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9B6szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:53:59 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9B6szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KQXMgZGlzY3Vzc2VkIGJlZm9yZSwgobBwZXJmb3JtaW5nIGhhc2ggY2FsY3Vs YXRpb24gb24gdGhlICJsb2FkLWJhbGFuY2luZyIgZmllbGQgY29udGFpbmVkIGluIHRoZSB0dW5u ZWwgZW5jYXBzdWxhdGlvbiBoZWFkZXJzIChpLmUuLCB0aGUgU2Vzc2lvbiBJRCBmaWVsZCBpbiB0 aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyKSBtZWFu cyBhIG5vbi10cml2aWFsIGNoYW5nZSB0byB0aGUgZGF0ZSBwbGFuZSBvZiBtYW55IGV4aXN0aW5n IGNvcmUgcm91dGVycyBhbmQgdGhlcmVmb3JlIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IG1vc3Qg ZXhpc3RpbmcgY29yZSByb3V0ZXJzIHlldC6hsQ0KDQpCeSB0aGUgd2F5LCB5b3UgbWF5IGhhcyBt aXNzZWQgYSBwcmV2aW91cyBjb21tZW50IG1hZGUgYnkgQ2FybG9zIChzZWUgaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21wbHMvY3VycmVudC9tc2cwOTI1OC5odG1sKSwgaXQg c2FpZCChsFlvdSBtZW50aW9uIFJGQyAzOTMxIC0tIEwyVFB2MyBkZWZpbmVzIEwyVFAgZGlyZWN0 bHkgb3ZlciBJUCAoSVAgUHJvdG9jb2wgbnVtYmVyIDExNSkgYXMgYSBNVVNULCBhbmQgTDJUUCBv dmVyIFVEUCBhcyBhIFNIT1VMRC4gSW1wbGVtZW50YXRpb25zIG1pZ2h0IG5vdCBzdXBwb3J0IEwy VFB2MyBvdmVyIFVEUC6hsQ0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBtcGxz LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQW5k cmV3IEcuIE1hbGlzDQq3osvNyrG85DogMjAxMsTqMTLUwjIyyNUgMzo1Mw0KytW8/sjLOiBMdWN5 IHlvbmcNCrOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSBwb2xs IHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBh biBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCg0KTHVjeSwNClN1cmUsIGJ1dCBpdCBjb3Vs ZCBiZSBzYXRpc2ZpZWQgYnkgTVBMUyBvdmVyIEwyVFAgb3ZlciBVRFAsIG9yIGhhc2hpbmcgb24g dGhlIEdSRSBrZXkgZm9yIE1QTFMgb3ZlciBHUkUuDQpDaGVlcnMsDQpBbmR5DQoNCk9uIEZyaSwg RGVjIDIxLCAyMDEyIGF0IDI6MjcgUE0sIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQpBbmR5LA0KDQpIZXJlIGlzIHRo ZSB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1udm8zLWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0 DQoNCiAgMy4zLjIuMS4gTEFHIGFuZCBFQ01QDQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVh c29ucywgbXVsdGlwYXRoIG92ZXIgTEFHIGFuZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAg IHN1cHBvcnRlZC4NCg0KICAgICAgIExBRyAoTGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUg ODAyLjFBWC0yMDA4XSBhbmQgRUNNUCAoRXF1YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFy ZSBjb21tb25seSB1c2VkIHRlY2huaXF1ZXMgdG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFu Y2luZyBvZiBtaWNyb2Zsb3dzIG92ZXIgYSBzZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIg YXQNCiAgICAgICBMYXllci0yIChMQUcpIG9yIExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBs b3llZCBoYXJkd2FyZQ0KICAgICAgIGltcGxlbWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNl cyBhIGhhc2ggb2YgdmFyaW91cyBmaWVsZHMgaW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24g KG91dGVybW9zdCkgaGVhZGVyKHMpIChlLmcuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQog ICAgICAgYWRkcmVzc2VzIGZvciBub24tSVAgdHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlv biBJUCBhZGRyZXNzZXMsDQogICAgICAgTDQgcHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGlu YXRpb24gcG9ydCBudW1iZXJzLCBldGMpLg0KICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBk ZXBsb3llZCBmb3IgdGhlIHVuZGVybGF5IG5ldHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qg b2Z0ZW4gdW5hd2FyZSBvZiB0aGUgY2FycmllZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBw YWNrZXRzDQogICAgICAgdHJhbnNtaXR0ZWQgYnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBw ZXJmb3JtIGZpbmUtZ3JhaW5lZCBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQg RUNNUCBwYXRocyBpbiB0aGUgdW5kZXJseWluZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1 bGF0aW9uIE1VU1QgcmVzdWx0IGluIHN1ZmZpY2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwN CiAgICAgICBwYXRocyB0aHJvdWdoIHNldmVyYWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkg aW5mb3JtYXRpb24gTUFZIGJlDQogICAgICAgaW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5 IGhlYWRlciBvciB1bmRlcmxheSBoZWFkZXIuDQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZh bmNlZCBzb2x1dGlvbiBpbiB0aGlzIHNwYWNlLg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEFuZHJldyBHLiBNYWxpcw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMjozMiBQ TQ0KVG86IFNoYW5lIEFtYW50ZQ0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIHBv bGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRw IGFuIG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBlYXJsaWVy IG9uIHRoaXMgZHJhZnQsIGFuZCBsaWtlIFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCBvZiBp dHMgdXRpbGl0eS4gSSBzdGlsbCBkb24ndCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkgYXQgYWxs IGZvciBjb3JlIGJhY2tib25lIG5ldHdvcmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMsIG9yIGlm IHlvdSBtdXN0IHR1bm5lbCBNUExTIG92ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVuY2Fwc3Vs YXRpb25zLiBSZWdhcmRpbmcgZGF0YSBjZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNzIEkgY291 bGQgYmUgY29udmluY2VkLCBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1c3RpZmlj YXRpb24gaW4gdGhlIGZvcm0gb2YgcmVxdWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNvdWxkIG9u bHkgYmUgbWV0IGJ5IHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2VkLCBEZWMg MTksIDIwMTIgYXQgOTozOCBBTSwgU2hhbmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2ludC5uZXQ8 bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpPbiBEZWMg MTgsIDIwMTIsIGF0IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWls dG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3 orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86 c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1 OA0KPj4gytW8/sjLOiBSb2dlcnMsIEpvc2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhp YW9odTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1 LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+DQo+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdl IGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUw IEFNLCAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gu cm9nZXJzQHR3Y2FibGUuY29tPj4NCj4+IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJz cGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0KPj4+IGFk ZHJlc3NlcyBpbiBwcmFjdGljZSBhbnkgbG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNlIGRvIG5v dCBkZWZpbmUgeWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBUaGUgSUVU Rg0KPj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBh bHNvIHN0YW5kYXJkaXplZCBNUExTDQo+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBz ZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdlIG9wZXJh dG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZiBMM1ZQ TiBvdmVyIGFuDQo+PiBJUC1vbmx5IG5ldHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0KPiBUaGFu ayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExT IG92ZXIgSVAgaW4gYXQgbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRo aXMgZmFjdCBtdXN0IGJlIHZlcnkgdmFsdWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBoYWQgYmVs aWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRvZGF5J3Mg U1AgbmV0d29ya3MuDQo+DQo+PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9y IFBXRTMgb3ZlciBMMlRQdjMNCj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVi bGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZDIDQ2NjUg Zm9yIHJlcXVpcmVtZW50cyByZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBi ZQ0KPj4gY2FycmllZCBvdmVyIEwyVFB2Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNo b3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4gSVBWUE4n cyBvdmVyIEwyVFB2MzoNCj4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEy XzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHNo YXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBB TkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxh dGlvbiBvbiB0aGUgU2Vzc2lvbiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUg S2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQwXSBpcyBu b3Qgd2lkZWx5IHN1cHBvcnRlZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFyLg0KRldJ VywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4g cmVxdWVzdGluZyBhIGNvcmUgcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhl IGlucHV0LWtleXMgdXNlZCBpbiBoYXNoIGNhbGN1bGF0aW9ucyBpbiBfZXhpc3RpbmdfIGhhcmR3 YXJlLCBhbHJlYWR5IGRlcGxveWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBuZXR3b3Jr LiAgRnVydGhlciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBh cmUgc2F2dnkgZm9sa3MgYW5kIHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBv ZiB0aGVpciBIVyBmYWlybHkgd2VsbC4gIEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9wZXJhdG9y cyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzIHJl Z2FyZC4gIFRodXMsIGl0IG1heSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3Nhcnkg dG8gY29udmluY2UgdGhlaXIgSFcgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFu Z2VzIGluIHRoZWlyIGVxdWlwbWVudCB0byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdvYWxzLiAg Oi0pICBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxv dy4NCg0KDQo+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxy ZWFkeSBjYXBhYmxlIG9mIGJhbGFuY2luZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBo YXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUgTVBMUy1p bi1VRFAgZW5jYXBzdWxhdGlvbiwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5n IGNhcGFiaWxpdHkgb2YgbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdl ZCB3aXRob3V0IHJlcXVpcmluZyBhbnkgY2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhlIG1ham9y IG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdo eSBub3QgZW5jYXBzdWxhdGUgdGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoIHVzZXMg VURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1h eSBiZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwgd2hpY2gg d291bGQgYWxsb3cgdGhlIGNvbm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29u dHJvbCBwYWNrZXRzKSB0byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBz b3VyY2UgSVAgYWRkcmVzc2VzKSwgYmFzZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0byBhY2hp ZXZlIGJldHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbiBJ UC1vbmx5IGNvcmUuICBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJl dHRlciBvZmYganVzdCB1c2luZyB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxk cyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0cyB3aXRo IHRoZSBhc3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQncyBub3Qg Y2xlYXIgdG8gbWUgdGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBk byB0aGlzLCBtYWtpbmcgYW55ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVu bmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpUaGUgYmVh dXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUg YWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRoZSAiY29u dHJvbCBjaGFubmVsIiAoc29mdHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbSBpbXBs ZW1lbnRhdGlvbnMuICBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3 aXRoIGV4aXN0aW5nIEwyVFB2MyBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9y cyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQgb24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1YnN0YW50 aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBhbmQgIkNv b2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRl bmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDgu MiBvZiBSRkMgMzkzMToNCi0tLXNuaXAtLS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFmZmljIHNl cGFyYXRpb24gZm9yIGl0cyBWUE5zIHZpYSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBpbiB0aGUg TDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KICAg KGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sg dG8gZW5zdXJlDQogICB0aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhl IGlkZW50aWZpZWQgc2Vzc2lvbi4NCiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBT ZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUgU2Vzc2lv biBJRCBsb29rdXAgd2FzIHBlcmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAgIFNlc3Np b24gSUQgaXRzZWxmIHdhcyBub3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlwLS0tDQou Li4gaW4gcmVnYXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkg QXJlYSBmb2xrcyBoYXZlLCBpbiB0aGUgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMg YWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4gZmFjdCwg dGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBS RkMgNDY2NS4gIChUaGVyZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0 cyB0aGF0IHVzZSBNUExTIGZvciB0cmFuc3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQg U2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBv biB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29u Y2VybiB3aWxsIGFyaXNlIGlmL3doZW4gdGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0K MykgRmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRo YXQgaW1wbGVtZW50IEwyVFAsIGZvciB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90 IHJlcXVpcmUgYW4gZW50aXJlIGluZHVzdHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5jYXBzdWxh dGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJlc3QgcmVn YXJkcywNCj4gWGlhb2h1DQo+DQo+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBM UyBvdmVyIElQLCB0aGVuIGNsZWFybHkgaXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3JlIHdpZGVs eSBpbXBsZW1lbnRlZCBieSBlcXVpcG1lbnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBMUyBvdmVy IEdSRSBvcg0KPj4gTVBMUyBvdmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhl cmUncyBhIHdheSkuICBJIHdvdWxkIG5vdGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNv bnMgdGhpcyBkaWQgbm90IHBhbiBvdXQgd2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFjdGljYWwN Cj4+IG9wZXJhdGlvbmFsIGJlbmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBuYXRpdmUg TVBMUw0KPj4gZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBu YW1lbHk6DQo+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMgRW5naW5l ZXJpbmcNCj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBi ZSBxdWl0ZSBjb21wZWxsaW5nIGFyZ3VtZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcg dG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1zaGFuZQ0K Pj4NCj4+DQo+Pj4gLUpvc2gNCj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJT aGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNv bS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1Q TFMgb3ZlciBJUCBpcyBsZWdhY3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8gaW1wcm92 ZSBpdC4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+Pg0KPj4+ PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdl aS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFNo YWhyYW0sDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3Zp ZGUgYSBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0 ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+Pj4+IG9w ZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRp b24gdHJhZmZpYw0KPj4+Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNl ZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5kIFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3du IGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj4+ Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFm ZmljIGFjcm9zcyBJUA0KPj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGlu ZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNt cyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNvLg0KPj4+ Pj4NCj4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+ Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBm b2xsb3dpbmcgYXJndW1lbnQNCj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2Vk IFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0aG91Z2h0 IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2ls ZW50DQo+Pj4+PiB0aWxsIG5vdy4NCj4+Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQg dG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+Pj4+Pg0K Pj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBTLg0KPj4+ Pj4+IERhdmFyaQ0KPj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4+Pj4+ IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRw QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9y Zz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+ Pj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBt YWtlDQo+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQNCj4+Pj4+Pg0KPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0 IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9kZXJuIG1l dHJvDQo+Pj4+Pj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25s eSBwcmFjdGljYWwgYXBwbGljYXRpb24NCj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4gY2VudGVy LCB3aGljaCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBO VkdSRSBhbmQNCj4+Pj4+PiBWWExBTi4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRo b3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPj4+ Pj4+IHByb2Nlc3MNCj4+Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+ Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+Pj4+DQo+ Pj4+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGku bnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtpbmcgZ3Jv dXAsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwg b24gYWRvcHRpbmcNCj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3 b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29u IHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0 aGUgbXBscyB3b3JraW5nDQo+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRm Lm9yZzxodHRwOi8vaWV0Zi5vcmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+Pj4+Pj4+ IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5 b3UgdGhpbmsgdGhhdA0KPj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVk IGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBwb2xs IGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQ UiBjbGFpbSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZl IGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QN Cj4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMg dGhhbiB0aG9zZSBhbHJlYWR5DQo+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g SG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9y IHRoZSBJUFINCj4+Pj4+Pj4gcG9sbCkNCj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlz dGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRpc2NvbnRp bnVlZCBhbGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9y IHRlYW0NCj4+Pj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdy b3VwIGNoYWlycyBoYXMgdHJpZWQgdG8NCj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhl ciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbC4N Cj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBGcm9tIHZlcnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxs IGFzIGENCj4+Pj4+Pj4gY28tYXV0aG9yLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+ IChtcGxzIHdnIGNvLWNoYWlyKQ0KPj4+Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+Pj4+IGxv YS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNv bT4NCj4+Pj4+Pj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAg bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAg ICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2JTIwMTAl MjA3MTclMjA1MiUyMDEzPg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5MiUyMDEz Pg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPg0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYu b3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QgdG8NCj4+IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg dGhlDQo+PiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24sIGNvcHlp bmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kDQo+ PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIElmIHlvdQ0KPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4gcGVybWFu ZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5k IGFueSBwcmludG91dC4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21wbHMNCj4+DQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN Cg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9B6szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

As discuss= ed before, =A1=B0performing hash calculation on= the "load-balancing" field contained in the tunnel encapsulation headers (i.e., the Session ID field in the L2TPv3 header or the Key field = in the GRE header) means a non-trivial change to the date plane of many exi= sting core routers and therefore not widely supported by most existing core= routers yet.=A1=B1

 = ;

By the way= , you may has missed a previous comment made by Carlos (see http://www.ietf= .org/mail-archive/web/mpls/current/msg09258.html), it said =A1=B0You mention RFC 3931 -- L2TPv3 defines L= 2TP directly over IP (IP Protocol number 115) as a MUST, and L2TP over UDP = as a SHOULD. Implementations might not support L2TPv3 over UDP.=A1=B1<= /o:p>

 

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED Andrew G. Malis
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C222=C8=D5 = 3:53
=CA=D5=BC=FE=C8=CB: Lucy yong
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; mpls@iet= f.org
=D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an= mpls working group document

 

= Lucy,

= Sure, but it could be satisfied by MPLS over L2TP over UDP, or hashing on t= he GRE key for MPLS over GRE.

Cheers,

Andy

=  

On Fri, Dec 21, 2012 at 2:27 PM= , Lucy yong <l= ucy.yong@huawei.com> wrote:

Andy,

 

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 

  3.3.2.1. LAG and ECMP 

 

       For performance reasons, mult= ipath over LAG and ECMP paths SHOULD be

       supported.

 

       LAG (Link Aggregation Group) = [IEEE 802.1AX-2008] and ECMP (Equal

       Cost Multi Path) are com= monly used techniques to perform load-

       balancing of microflows over = a set of a parallel links either at

       Layer-2 (LAG) or Layer-3= (ECMP). Existing deployed hardware

       implementations of LAG a= nd ECMP uses a hash of various fields in the

        encapsulation (out= ermost) header(s) (e.g. source and destination MAC

       addresses for non-IP tra= ffic, source and destination IP addresses,

       L4 protocol, L4 source a= nd destination port numbers, etc).

       Furthermore, hardware de= ployed for the underlay network(s) will be

       most often unaware of th= e carried, innermost L2 frames or L3 packets

       transmitted by the TS. T= hus, in order to perform fine-grained load-

       balancing over LAG and ECMP p= aths in the underlying network, the

       encapsulation MUST resul= t in sufficient entropy to exercise all

       paths through several LA= G/ECMP hops. The entropy information MAY be

       inferred from the NVO3 o= verlay header or underlay header.

 

Our draft provides an advanced solution in this space.

 

Lucy

 

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document=

 

I've commented earlier on this draft, and lik= e Shane, I remain unconvinced of its utility. I still don't think it has an= y utility at all for core backbone networks - just use native MPLS, or if you must tunnel MPLS over IP, the GRE or L2T= Pv3 encapsulations. Regarding data center applications, I guess I could be = convinced, but I would like to see a clear justification in the form of req= uirements from nvo3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante= <shane@castl= epoint.net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlep= oint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012= =C4=EA12=D4=C219=C8= =D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.c= om>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively r= ecent past, in requesting a core router vendor to support changes to the in= put-keys used in hash calculations in _existing_ hardware, already deployed (extensively) throughout my network.=  Further, I suspect that most large network operators are savvy folks= and understand the internal architecture of their HW fairly well.  As= a result, those same operators know what is and is not technically possible in this regard.  Thus, it may be a= question of "methods" necessary to convince their HW supplier(s)= to make appropriate changes in their equipment to achieve their business g= oals.  :-)  However, this may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulat= e the traffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com&g= t; wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
>>>>>> mpls-chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpl= s@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9B6szxeml525mbschi_-- From xuxiaohu@huawei.com Sun Dec 23 19:12:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982E721F8BD6 for ; Sun, 23 Dec 2012 19:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLjTg7sNBemf for ; Sun, 23 Dec 2012 19:12:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 724A221F8722 for ; Sun, 23 Dec 2012 19:12:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT71397; Mon, 24 Dec 2012 03:12:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 03:11:55 +0000 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 03:12:18 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Mon, 24 Dec 2012 11:12:06 +0800 From: Xuxiaohu To: Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sszh5eWXqDbZUC4MEZ17BejhpghW8uAgAAGHQCAAAntgIABD+5A///lsoCAAOaJAIAADKCAgAPjKKD//4ZbAIAAiFrg Date: Mon, 24 Dec 2012 03:12:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9DB@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com>, <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A98A@szxeml525-mbs.china.huawei.com> <814D9C14-9211-4EDD-8C2A-564FDB7F5D78@broadcom.com> In-Reply-To: <814D9C14-9211-4EDD-8C2A-564FDB7F5D78@broadcom.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.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9DBszxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 03:12:30 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9DBszxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhhdCB5b3UgYXJlIHN0cnVnZ2xpbmcgdG8gZmlnaHQgYWdhaW5zdCBhbnkgTVBM UyBvdmVyIElQIGVuY2Fwc3VsYXRpb24gbWV0aG9kLCBidXQgbm90IGp1c3QgTVBMUy1pbi1VRFAu IElmIHlvdSBkbyBiZWxpZXZlIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIGFueSBNUExTIG92 ZXIgSVAgZW5jYXBzdWxhdGlvbiBtZXRob2QsIHRoZSBiZXN0IHRoaW5nIHRvIGRvIGlzIHRvIHJl cXVlc3QgbW92aW5nIGFsbCBleGlzdGluZyBNUExTIG92ZXIgSVAgcmVsYXRlZCBSRkNzIHRvIEhp c3RvcmljIHN0YXR1cy4NCg0KWGlhb2h1DQoNCreivP7IyzogU2hhaHJhbSBEYXZhcmkgW21haWx0 bzpkYXZhcmlAYnJvYWRjb20uY29tXQ0Kt6LLzcqxvOQ6IDIwMTLE6jEy1MIyNMjVIDEwOjQ3DQrK 1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBTLiBEYXZhcmk7IEx1Y3kgeW9uZzsgZHJhZnQteHUtbXBs cy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQ IHVuZGVybHlpbmcgbmV0d29yaw0KDQpNUExTIGJhc2VkIFZQTiBzdXBwb3J0cyBtdWx0aWNhc3Qg VHJlZSwgYnV0IG9ubHkgd2hlbiBUcmFuc3BvcnQgaXMgTVBMUyBhbmQgbm90IElQLiBNUExTIG92 ZXIgSVAgZG9lcyBub3Qgc3VwcG9ydCBNdWx0aWNhc3QgdHJlZS4NCg0KUmVnYXJkcywNClNoYWhy YW0NCg0KDQpPbiBEZWMgMjMsIDIwMTIsIGF0IDY6MzIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1 QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCg0KDQq3orz+ yMs6IFMuIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNoQHlhaG9vLmNvbV0NCreiy83KsbzkOiAyMDEy xOoxMtTCMjLI1SA2OjQwDQrK1bz+yMs6IEx1Y3kgeW9uZzsgWHV4aWFvaHU7IFNoYWhyYW0gRGF2 YXJpDQqzrcvNOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hh aXJzQHRvb2xzLmlldGYub3JnPg0K1vfM4jogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBv dmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCg0KTHVjeSwNCg0KSSBjYW4gb25seSBzZWUg Q2hpbmEgVGVsZWNvbSBhcyBjby1hdXRob3IsIGFuZCB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9u IHNheXMgTDJWUE4gYW5kIEwzVlBOLiBTbyBpcyBDaGluYSBUZWxlY29tIHVzaW5nIGl0IGZvciB0 aGVpciBFbnRlcnByaXNlIFZQTiBzZXJ2aWNlPyBidXQgeW91ciBlYXJsaWVyIGVtYWlscyBzdWdn ZXN0cyB0aGF0IHRoaXMgaXMgbm90IHRoZSBpbnRlbmRlZCB1c2FnZSByYXRoZXIgaXQgaXMgZm9y IERhdGEgQ2VudGVyLiBTbyB3aGljaCBvbmUgaXMgaXQ/IFdoeSBpc24ndCBDaGluYSBUZWxlY29t IHNwZWFraW5nIG9uIHRoZSBsaXN0IGFuZCBleHBsYWluaW5nIHRoZWlyIHVzYWdlIG1vZGVsPw0K DQoNCltYaWFvaHVdIFllcywgdGhlIEFwcGxpY2FiaWxpdHkgc2VjdGlvbiBzYXlzIEwyVlBOIGFu ZCBMM1ZQTiwgYnV0IHRoZXJlIGlzIG5vIGxpbWl0IHRoYXQgdGhlc2UgdGVjaG5vbG9naWVzIGNv dWxkIG9ubHkgYmUgdXNlZCBieSBzZXJ2aWNlIHByb3ZpZGVycz8gIEVudGVycHJpc2VzIHRoZW1z ZWx2ZXMgY291bGQgYWRvcHQgdGhlc2UgdGVjaG5vbG9naWVzIHRvIGludGVyY29ubmVjdCB0aGVp ciBtdWx0aXBsZSBzaXRlcyBhbmQgZGF0YSBjZW50ZXIgb3BlcmF0b3JzIGNvdWxkIHVzZSB0aGVt IHdpdGhpbiBvciBldmVuIGFjcm9zcyBkYXRhIGNlbnRlcnMgYXMgd2VsbCBpZiB0aGV5IHdvdWxk IGxpa2UuIExldCBtZSBpdGVyYXRlIHRoYXQgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCBjYW4gYmUg dXNlZCBpbiBTUCBuZXR3b3JrcywgZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgZXZlbiBkYXRhIGNl bnRlcnMgYW5kIHRoZXJlZm9yZSBNUExTLWluLVVEUCBpcyBhcHBsaWNhYmxlIHRvIGFueSBvZiB0 aGUgYWJvdmUgc2NlbmFyaW8gYXMgd2VsbC4NCg0KQWxzbyByZWdhcmRpbmcgTXVsdGljYXN0LCB0 aGlzIG1lYW5zIHlvdSBuZWVkIHRvIG1hcCBNdWx0aWNhc3QgdHJhZmZpYyB0byBQMlAgUFcsIHdo aWNoIGlzIGluZmVyaW9yIHRvIG90aGVyIG1ldGhvZHMgc3VjaCBhcyBOVkdSRSBhbmQgVlhMQU4g c2luY2UgdGhleSBuYXRpdmVseSBzdXBwb3J0IGVmZmljaWVudCBNdWx0aWNhc3QuDQoNCg0KW1hp YW9odV0gRmlyc3QsIHJlbWVtYmVyIHRoYXQgTVBMUy1pbi1VRFAgaXMgbm90IG9ubHkgc3VpdGFi bGUgZm9yIE1QTFMtYmFzZWQgTDJWUE4gYnV0IGFsc28gc3VpdGFibGUgZm9yIEwzVlBOLiBTZWNv bmQsIE1QTFMtYmFzZWQgVlBOIGNhbiBzdXBwb3J0IGJvdGggaW5ncmVzcyByZXBsaWNhdGlvbiBt b2RlIGFuZCBtdWx0aWNhc3QgdHJlZSBtb2QNCg0KVGhhbmtzLA0KU2hhaHJhbQ0KDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTHVjeSB5b25nIDxsdWN5Lnlv bmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KVG86IFMuIERhdmFy aSA8ZGF2YXJpc2hAeWFob28uY29tPG1haWx0bzpkYXZhcmlzaEB5YWhvby5jb20+PjsgWHV4aWFv aHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PjsgU2hh aHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5j b20+Pg0KQ2M6ICJkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJh ZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQteHUtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn Pj47ICJtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+PjsgIm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0 bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4iIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y ZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+Pg0KU2VudDogRnJpZGF5LCBEZWNl bWJlciAyMSwgMjAxMiAxOjU1OjEwIFBNDQpTdWJqZWN0OiBSRTogW21wbHNdIE1QTFMgY2xpZW50 IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KDQoNCg0KU2hhaHJhbSwNCg0K UGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IFMuIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNoQHlh aG9vLmNvbV0NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjEsIDIwMTIgMjoxMCBBTQ0KVG86IFh1 eGlhb2h1OyBTaGFocmFtIERhdmFyaTsgTHVjeSB5b25nDQpDYzogZHJhZnQteHUtbXBscy1pbi11 ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYu b3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3 b3JrDQoNCkhpLA0KDQpJIHRoaW5rIHdlIGFyZSBpbiBhIHZpY2lvdXMgY3ljbGUuIENvdWxkIHlv dSBwbGVhc2UgY2xhcmlmeSB3aGljaCBuZXR3b3JrIG9wZXJhdG9yIGlzIGFza2luZyBmb3IgTVBM UyBvdmVyIFVEUCBhbmQgd2hhdCBpcyB0aGUgYXBwbGljYXRpb24uDQpbTHVjeV0gaXQgaXMgaW5k aWNhdGVkIGluIHRoZSBkcmFmdC4NCkFsc28gaG93IGRvIHlvdSBwbGFuIHRvIGFkZHJlc3MgdGhl IE1QTFMgTXVsdGljYXN0ICh3aGljaCBpcyBwcm9iYWJseSBtb3JlIGltcG9ydGFudCB0aGFuIGlt cHJvdmluZyB0aGUgbG9hZCBiYWxhbmNpbmcpLCBnaXZlbiB0aGF0IFJGQzQwMjMgZG9lcyBub3Qg c3VwcG9ydCBNdWx0aWNhc3QuDQpbTHVjeV0gTVBMUyBDbGllbnQgTGF5ZXIgaXMgcmVzcG9uc2li bGUgdG8gbWFwIG11bHRpY2FzdCB0cmFmZmljIHRvIHVuZGVybHlpbmcgdHJhbnNwb3J0LCB3aGlj aCBpcyBzcGVjaWZpZWQgaW4gRVZQTiBhbmQgSVAgVlBOLiBUaGlzIHByb3Bvc2FsIGp1c3QgcmVx dWVzdHMgaW5ncmVzcyBQRSB0byBmaWxsIHRoZSBmbG93IGVudHJvcHkgaW50byBVRFAgc291cmNl IHBvcnQsIGluIHdoaWNoIHRoZSBmbG93IGNhbiBiZSB1bmljYXN0IG9yIG11bHRpY2FzdC4NCg0K UmVnYXJkcywNCkx1Y3kNCg0KDQoNClRoYW5rcywNClNoYWhyYW0NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208 bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+Pg0KVG86IFNoYWhyYW0gRGF2YXJpIDxkYXZhcmlA YnJvYWRjb20uY29tPG1haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tPj47IEx1Y3kgeW9uZyA8bHVj eS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCkNjOiAiZHJh ZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4t dWRwQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz4+OyAibXBsc0BpZXRm Lm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPj47ICJtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+IiA8bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPj4NClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAx MiA1OjU2OjIzIFBNDQpTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIg YW4gSUdQIHVuZGVybHlpbmcgbmV0d29yaw0KDQoNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZz5dILT6se0NCj4gU2hhaHJhbSBEYXZhcmkNCj4gt6LLzcqxvOQ6IDIwMTLE6jEy1MIyMcjV IDE6MzENCj4gytW8/sjLOiBMdWN5IHlvbmcNCj4gs63LzTogZHJhZnQteHUtbXBscy1pbi11ZHBA dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn PjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnPjsNCj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4g1vfM4jog UmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdv cmsNCj4NCj4gUGxlYXNlIGRvbid0IG1peCB1cCB0aGluZ3MuIFRoZSBNUExTIHByb3RvY29sIGRl c2lnbiBJIGFncmVlIG11c3QgYmUgZG9uZSBieQ0KPiBNUExTIFdHLiBCdXQgdGhlIHF1ZXN0aW9u IGlzIHdoZXRoZXIgeW91ciBwcm9wb3NhbCBtZWV0cyB0aGUgbmV0d29yaw0KPiB2aXJ0dWFsaXph dGlvbiByZXF1aXJlbWVudHMuDQoNCkNhbiB5b3UgdGVsbCB1cyB3aGVyZSBNUExTLWluLUdSRS9J UCBbUkZDNDAyM10gYW5kIG90aGVyIE1QTFMgb3ZlciBJUCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlz bXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmU/DQoNClNpbmNlIE1QTFMtaW4tVURQIGlzIGp1 c3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiB0aGUgc2NlbmFyaW9zIHdoZXJlIE1QTFMtaW4tR1JF L0lQIGhhcyBiZWVuIHVzZWQgYW5kIGlzIHRvIGJlIHVzZWQsIE1QTFMtaW4tVURQIHNob3VsZCBi ZSBkaXNjdXNzZWQgaW4gdGhlIHNhbWUgV0cgd2hlcmUgTVBMUy1pbi1HUkUvSVAgaGFzIGJlZW4g ZGlzY3Vzc2VkLg0KDQpYaWFvaHUNCg0KPiBUaGUgTlZPMyB0YXNrIGlzIHRvIGRvY3VtZW50IHRo ZSBpc3N1ZXMsIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrIGZvcg0KPiBOdk8zLiBUaGVuIGlm IE1QTFMgb3ZlciBJUCBsb29rcyBsaWtlIGEgc3VpdGFibGUgc29sdXRpb24gdGhhdCBtZWV0cyB0 aGUNCj4gcmVxdWlyZW1lbnRzIHN1Y2ggYXMgdGhlIHNjYWxlLCBtb2JpbGl0eSwgZXRjLCB0aGVu IHRoZXkgd2lsbCBhc2sgTVBMUyBXRyBmb3INCj4gcHJvdG9jb2wgZGVzaWduLg0KPg0KPiBTbyBi ZWZvcmUgcHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJIHRoaW5rIHlvdSBzaG91bGQgdGFrZSBpdCB0 byBOVk8zIFdHIGFuZA0KPiBjb252aW5jZSB0aGVtIHRoaXMgc29sdXRpb24gbWVldHMgdGhlaXIg cmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsuDQo+DQo+IFdlIGRvbid0IHdhbnQgSUVURiBkbyBk ZXNpZ24gTiBudW1iZXIgb2Ygc29sdXRpb25zIGZvciB0aGUgc2FtZSBwcm9ibGVtLCBkbw0KPiB3 ZT8NCj4NCj4gLVNoYWhyYW0NCj4NCj4NCj4NCj4gUmVnYXJkcywNCj4gU2hhaHJhbQ0KPg0KPg0K PiBPbiBEZWMgMjAsIDIwMTIsIGF0IDg6NTYgQU0sICJMdWN5IHlvbmciIDxsdWN5LnlvbmdAaHVh d2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gPiBOZXR3 b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgaXMgZGlzY3Vzc2VkIHVuZGVyIG52bzMgV0cuIFRo aXMgZG9lcyBub3QNCj4gbWVhbiB0aGF0IG52bzMgV0cgaGFzIHRvIGRlc2lnbiBhIG5ldyBwcm90 b2NvbCBmb3IgYSB1bmRlcmx5aW5nIG5ldHdvcmsgb3IgYQ0KPiBuZXcgcHJvdG9jb2wgZm9yIGEg b3ZlcmxheSBuZXR3b3JrLiBJbiBmYWN0LCBwZW9wbGUgdGhlcmUgYWltIG9uIGxldmVyYWdlDQo+ IHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29tcGxpc2ggdGhlbS4gSU1POiB0aGVz ZSBleHBhbnNpb25zIG9uIGFuDQo+IGV4aXN0aW5nIHN0YW5kYXJkIHByb3RvY29sIGhhdmUgdG8g YmUgd29ya2VkIG91dCBpbiB0aGUgcHJvdG9jb2wgV0cgZ3JvdXAsIGl0DQo+IHNob3VsZCBub3Qg Z2l2ZSBudm8zIFdHIGZyZWUgcmlnaHQgdG8gZW5oYW5jZSB0aGVzZSBwcm90b2NvbHMuIEZvciBh IGJyYW5kDQo+IG5ldyBwcm90b2NvbCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5 LCBudm8zIFdHIG1heSBiZSB0aGUgcGxhY2UgdG8NCj4gc3RhcnQuDQo+ID4NCj4gPiBMdWN5DQo+ ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogU2hhaHJhbSBE YXZhcmkgW21haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tPG1haWx0bzpkYXZhcmlAYnJvYWRjb20u Y29tPl0NCj4gPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDEwOjM0IEFNDQo+ ID4+IFRvOiBMdWN5IHlvbmcNCj4gPj4gQ2M6IFNoYW5lIEFtYW50ZTsgZHJhZnQteHUtbXBscy1p bi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmll dGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47DQo+ID4+IG1wbHMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4N Cj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1 bmRlcmx5aW5nIG5ldHdvcmsNCj4gPj4NCj4gPj4gTmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVy bGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBjb25zZW50ZWQgIGluIE5WTzMNCj4gPj4gV0cuDQo+ ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFNoYWhyYW0NCj4gPj4NCj4gPj4NCj4gPj4gT24gRGVj IDIwLCAyMDEyLCBhdCA3OjM5IEFNLCAiTHVjeSB5b25nIiA8bHVjeS55b25nQGh1YXdlaS5jb208 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6DQo+ID4+DQo+ID4+PiBIaSBTaGFu ZSwNCj4gPj4+DQo+ID4+PiBJIHVuZGVyc3RhbmQgb3BlcmF0b3IgY29uY2VybiBvbiBhIG5ldyBl bmNhcHN1bGF0aW9uIHRvIGFuIGV4aXN0aW5nDQo+ID4+IG5ldHdvcmsuDQo+ID4+Pg0KPiA+Pj4g SG93ZXZlciwgTVBMUy1pbi1VRFAgZG9lcyBub3QgYWltIG9uIGNoYW5naW5nIGV4aXN0aW5nIFNQ IElQL01QTFMNCj4gPj4gbmV0d29yayBhdCBhbGwuDQo+ID4+PiBNUExTLWluLVVEUCBpcyB0byBl bmFibGUgTVBMUyBjbGllbnQgbGF5ZXIgdG8gYmUgZGVjb3VwbGVkIGZyb20gTVBMUw0KPiA+PiBz ZXJ2ZXIgbGF5ZXIgYW5kIHVzZSBNUExTIGNsaWVudCBsYXllciBhcyBvdmVybGF5IG5ldHdvcmsg YW5kIGFuIElHUCBhcw0KPiA+PiBhIHVuZGVybHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBT dWNoIGFwcGxpY2F0aW9uIGlzIGZvciBEQy4gWW91IG1heQ0KPiA+PiBhcmd1ZSB3aHkgbm90IHVz ZSB0aGUgR1JFIHdoaWNoIGlzIGZvciBNUExTIGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybGluZw0K PiA+PiBuZXR3b3JrLiBXZSBoYXZlIHBvaW50ZWQgb3V0IGluIHRoZSBkcmFmdCB0aGF0IGN1cnJl bnQgcm91dGVycyBpbiBEQw0KPiA+PiBiYXJlbHkgc3VwcG9ydCBHUkUgYmFzZWQgbG9hZCBiYWxh bmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkgdXNlZA0KPiA+PiBpbiBTUCBuZXR3b3Jr cyB0b28uIE1vc3Qgb2Ygcm91dGVycyBpbiBEQyBwZXJmb3JtIHVwZCBwb3J0IGJhc2VkIGxvYWQN Cj4gPj4gYmFsYW5jaW5nIG5vdy4NCj4gPj4+DQo+ID4+PiBGcm9tIHRoZSBhcmNoaXRlY3R1cmUg cGVyc3BlY3RpdmUsIHRoZSBVRFAgZW5jYXBzdWxhdGlvbiBoYXMNCj4gPj4gYWR2YW50YWdlIG92 ZXIgR1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5jYXBzdWxhdGlvbiwgdGhlIGZyYW1l DQo+ID4+IGhlYWRlciBkZWNvdXBsZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29y ayBjbGVhcmx5LCBpLmUuIG91dGVyDQo+ID4+IGhlYWRlciBhbmQgb3ZlcmxheSBoZWFkZXIuIFVE UCBiZWxvbmdzIHRvIG91dGVyIGhlYWRlciwgd2hpY2gNCj4gPj4gdW5kZXJseWluZyBuZXR3b3Jr IHVzZXMgb25seS4gSG93ZXZlciwgR1JFIGhlYWRlciBoYXMgdGhlIGZpZWxkcyBmb3INCj4gPj4g dGhlIG92ZXJsYXkgbmV0d29yayBhbmQgdXNlcyB0aGUga2V5IGZpZWxkIGZvciBmbG93IGVudHJv cHkuIEZvciBsb2FkDQo+ID4+IGJhbGFuY2luZywgaXQgcmVxdWlyZXMgdGhlIHVuZGVybHlpbmcg bmV0d29yayB1c2VzIEdSRSBoZWFkZXIgdG9vLiBJbg0KPiA+PiBzaG9ydCwgR1JFIHRpZXMgdGhl IG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29ya3MgdG9nZXRoZXIuIFNpbmNlIGl0DQo+ID4+ IGhhcyBub3QgdXNlZCBhIGxvdCwgcGVvcGxlIGFyZSBub3QgYXdhcmUgb2YgdGhlIGRpc2FkdmFu dGFnZSBvZiBzdWNoDQo+ID4+IGNvdXBsaW5nLg0KPiA+Pj4NCj4gPj4+IEFzIHRoZSBpbmR1c3Ry eSBtb3ZlcyB0b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IGFuZA0KPiA+PiBk ZWNvdXBsZXMgb3ZlcmxheSBuZXR3b3JrcyBmcm9tIHRoZSB1bmRlcmx5aW5nIG5ldHdvcmsuIEEg Y2xlYXINCj4gPj4gc2VwYXJhdGlvbiBvZiBvdmVybGF5IGhlYWRlciBhbmQgdW5kZXJseWluZyBo ZWFkZXIgaXMgYSAiTVVTVCIgaW4gbXkNCj4gPj4gb3Bpbmlvbi4gSWYgd2UgY291bnQgR1JFIGFz IHRoZSBvdmVybGF5IGhlYWRlciwgdGhlbiBmb3IgSVB2NA0KPiA+PiB1bmRlcmx5aW5nIG5ldHdv cmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUgZmxvdyBlbnRyb3B5LiBUaGlzIGlzIHRoZQ0K PiA+PiByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVuY2Fwc3VsYXRpb246IGZvciBhbiBJR1Ag YmFzZWQgdW5kZXJseWluZw0KPiA+PiBuZXR3b3JrLiBJbiBmYWN0LCBpdCBjYW4gc3VwcG9ydCBh bnkgb3ZlcmxheSBuZXR3b3JrIGJlc2lkZSBNUExTIGNsaWVudA0KPiA+PiBsYXllciAoZS5nLiBW WExBTiwgTDJUUC1pbi1VRFAsIGV0YykuDQo+ID4+Pg0KPiA+Pj4gWW91IHBvaW50IG91dCB1c2lu ZyBNUExTLWluLUwyVFAtaW4tVURQIGluc3RlYWQuIFllcywgTVBMUy1pbi1MMlRQLQ0KPiA+PiBp bi1VRFAgc2NoZW1hIGFsc28gcHJvdmlkZXMgYSBvdmVybGF5IChMMlRQKSBhbmQgdW5kZXJseWlu ZyAoSVApDQo+ID4+IG5ldHdvcmsgZGVjb3VwbGluZy4gTDJUUCBwcm90b2NvbCAocmZjMzkzMSkg cHJvdmlkZXMgZ29vZCBzZWN1cml0eQ0KPiA+PiBtZWNoYW5pc20gYW5kIGhhcyB0aGUgZW1iZWRk ZWQgY29udHJvbCBmdW5jdGlvbiB0b28uIFRoZXJlZm9yZSwNCj4gc29tZW9uZQ0KPiA+PiBjYW4g dXNlIGl0IGZvciBNUExTIGNsaWVudCBsYXllciBvdmVyIEludGVybmV0LiBUbyBoYXZlIE1QTFMg Y2xpZW50DQo+ID4+IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybGluZyBuZXR3b3JrLCBJTU86IE1Q TFMtaW4tTDJUUC1pbi1VRFAgaXMgYQ0KPiA+PiBvdmVya2lsbCBhbmQgdG9vIGNvbXBsZXguIEhl cmUgd2UgbmVlZCBhIHNjaGVtYSB0byBzdXBwb3J0IElHUA0KPiA+PiB1bmRlcmx5aW5nIHRyYW5z cG9ydCB3aXRob3V0IHRvdWNoaW5nIGEgb3ZlcmxheSBoZWFkZXIuIFVEUA0KPiA+PiBlbmNhcHN1 bGF0aW9uIGlzIHRoZSBiZXN0IGNob2ljZSB0byBhY2NvbXBsaXNoIHRoYXQgYW5kIG1pbmltaXpl IHRoZQ0KPiA+PiBjaGFuZ2VzIG9uIGV4aXN0aW5nIHJvdXRlcnMsIGUuZy4gY2hhbmdlIGF0IGVk Z2Ugcm91dGVycywgbm8gY2hhbmdlIG9uDQo+ID4+IHRyYW5zaXQgcm91dGVycy4NCj4gPj4+DQo+ ID4+PiBSZWdhcmRzLA0KPiA+Pj4gTHVjeQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPl0NCj4gPj4+PiBT ZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNDoxNCBBTQ0KPiA+Pj4+IFRvOiBTaGFu ZSBBbWFudGUNCj4gPj4+PiBDYzogUm9nZXJzLCBKb3NoOyBTaGFocmFtIERhdmFyaTsgZHJhZnQt eHUtbXBscy1pbi0NCj4gPj4gdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzp1ZHBAdG9vbHMuaWV0 Zi5vcmc+Ow0KPiA+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+ DQo+ID4+Pj4gU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cgdG8gdHJhbnNwb3J0IE1QTFMgb3Zl ciBVRFAgdHVubmVscw0KPiA+Pj4+DQo+ID4+Pj4gSGkgU2hhbmUsDQo+ID4+Pj4NCj4gPj4+PiBU aGFua3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBhbmQgcGxlYXNlIHNlZSBteSByZXNwb25z ZSBpbmxpbmUuDQo+ID4+Pj4NCj4gPj4+PiBOb3RlOiBJIGNoYW5nZWQgdGhlIHN1YmplY3QgbGlu ZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi4NCj4gPj4+Pg0KPiA+Pj4+PiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4gPj4+Pj4gt6K8/sjLOiBTaGFuZSBBbWFudGUgW21haWx0bzpzaGFuZUBj YXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldD5dDQo+ID4+Pj4+ILei y83KsbzkOiAyMDEyxOoxMtTCMTnI1SAyMjozOA0KPiA+Pj4+PiDK1bz+yMs6IFh1eGlhb2h1DQo+ ID4+Pj4+ILOty806IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1wbHMt aW4tDQo+ID4+Pj4gdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmc+ Ow0KPiA+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgbXBscy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KPiA+ Pj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBt YWtlIGRyYWZ0LXh1LQ0KPiA+Pj4+IG1wbHMtaW4tdWRwIGFuDQo+ID4+Pj4+IG1wbHMgd29ya2lu ZyBncm91cCBkb2N1bWVudA0KPiA+Pj4+Pg0KPiA+Pj4+PiBYaWFvaHUsDQo+ID4+Pj4+DQo+ID4+ Pj4+IE9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3 ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4NCj4gd3JvdGU6DQo+ID4+Pj4+IC0t LS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+Pj4+ILeivP7IyzogU2hhbmUgQW1hbnRlIFttYWlsdG86 c2hhbmVAY2FzdGxlcG9pbnQubmV0PG1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQ+XQ0KPiA+ Pj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KPiA+Pj4+Pj4+IMrVvP7Iyzog Um9nZXJzLCBKb3NoDQo+ID4+Pj4+Pj4gs63LzTogU2hhaHJhbSBEYXZhcmk7IFh1eGlhb2h1OyBk cmFmdC14dS1tcGxzLWluLQ0KPiA+Pj4+IHVkcEB0b29scy5pZXRmLm9yZzxtYWlsdG86dWRwQHRv b2xzLmlldGYub3JnPjsNCj4gPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPjsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnPg0KPiA+Pj4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2Ug aGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+Pj4gbXBscy1pbi11ZHANCj4gPj4+ Pj4gYW4NCj4gPj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJz LCBKb3NoIg0KPiA+Pj4+IDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9zaC5yb2dl cnNAdHdjYWJsZS5jb20+Pg0KPiA+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBJIHNoYXJlIHlv dXIgU1AgcGVyc3BlY3RpdmUsIGFuZCBkbyBub3Qgc2VlIHRoZSBwcm9ibGVtIHRoaXMNCj4gPj4+ PiBzb2x1dGlvbg0KPiA+Pj4+Pj4+PiBhZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxvbmdlci4N Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFub3Ro ZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uDQo+ID4+Pj4gVGhlDQo+ID4+Pj4+IElFVEYN Cj4gPj4+Pj4+PiBhbHJlYWR5IHN0YW5kYXJkaXplZCBNUExTIG92ZXIgR1JFLiAgVGhlIElFVEYg aGFzIGFsc28NCj4gPj4+PiBzdGFuZGFyZGl6ZWQNCj4gPj4+Pj4gTVBMUw0KPiA+Pj4+Pj4+IG92 ZXIgTDJUUHYzL1VEUC9JUCwgd2hpY2ggaGFkIHNlZW4gc29tZSBkZXBsb3ltZW50IGluIGF0IGxl YXN0DQo+ID4+IG9uZSwNCj4gPj4+PiB2ZXJ5DQo+ID4+Pj4+Pj4gbGFyZ2Ugb3BlcmF0b3IgbmV0 d29yayB0aGF0IEknbSBhd2FyZSBvZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mDQo+ID4+Pj4gTDNW UE4gb3Zlcg0KPiA+Pj4+PiBhbg0KPiA+Pj4+Pj4+IElQLW9ubHkgbmV0d29yay4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBIaSBTaGFuZSwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFuayB5b3UgZm9yIHRl bGxpbmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXINCj4gPj4+ PiBJUCBpbiBhdA0KPiA+Pj4+PiBsZWFzdCBvbmUsIHZlcnkgbGFyZ2Ugb3BlcmF0b3IgbmV0d29y ay4gVGhpcyBmYWN0IG11c3QgYmUgdmVyeQ0KPiA+Pj4+IHZhbHVhYmxlIHRvIHRob3NlDQo+ID4+ Pj4+IHBlb3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9uIG9mIE1Q TFMgb3ZlciBJUCBpbg0KPiA+Pj4+IHRvZGF5J3MgU1ANCj4gPj4+Pj4gbmV0d29ya3MuDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4+IFNlZTogUkZDJ3MgNDQ1NCwgNDcxOSwgNDU5MSwgNDM0OSBmb3IgUFdF MyBvdmVyIEwyVFB2Mw0KPiA+Pj4+Pj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUg cHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2DQo+ID4+Pj4+IHRpbWVmcmFtZSFdDQo+ID4+ Pj4+Pj4gIFJGQyA0NjY1IGZvciByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBWUExTIHRoYXQgc2F5 IHRoYXQgVlBMUw0KPiA+Pj4+IG1heSBiZQ0KPiA+Pj4+Pj4+IGNhcnJpZWQgb3ZlciBMMlRQdjMN Cj4gPj4+Pj4+PiAgQW5kLCBoZXJlJ3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0IG9u ZSB2ZW5kb3IgaGFzDQo+ID4+Pj4+IGltcGxlbWVudGVkDQo+ID4+Pj4+Pj4gSVBWUE4ncyBvdmVy IEwyVFB2MzoNCj4gPj4gaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3MvMTJfMHMv ZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzIGFn YWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlvbmVkIGluDQo+ ID4+Pj4gdGhpcyBkcmFmdA0KPiA+Pj4+PiBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNt IG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbg0KPiA+PiB0aGUNCj4gPj4+PiBTZXNz aW9uDQo+ID4+Pj4+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBLZXkgZmll bGQgaW4gdGhlIEdSRSBoZWFkZXIgYXMNCj4gPj4+PiBkZWZpbmVkIGluDQo+ID4+Pj4+IFtSRkMg NTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHNv IGZhci4NCj4gPj4+Pj4NCj4gPj4+Pj4gRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUg cmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4NCj4gPj4+PiByZXF1ZXN0aW5nIGEgY29yZQ0KPiA+ Pj4+PiByb3V0ZXIgdmVuZG9yIHRvIHN1cHBvcnQgY2hhbmdlcyB0byB0aGUgaW5wdXQta2V5cyB1 c2VkIGluIGhhc2gNCj4gPj4+PiBjYWxjdWxhdGlvbnMgaW4NCj4gPj4+Pj4gX2V4aXN0aW5nXyBo YXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQgbXkNCj4g Pj4+PiBuZXR3b3JrLg0KPiA+Pj4+PiBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdl IG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBzYXZ2eQ0KPiA+PiBmb2xrcw0KPiA+Pj4+IGFuZA0KPiA+ Pj4+PiB1bmRlcnN0YW5kIHRoZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFp cmx5IHdlbGwuICBBcyBhDQo+ID4+Pj4gcmVzdWx0LCB0aG9zZQ0KPiA+Pj4+PiBzYW1lIG9wZXJh dG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlz DQo+ID4+Pj4gcmVnYXJkLg0KPiA+Pj4+PiBUaHVzLCBpdCBtYXkgYmUgYSBxdWVzdGlvbiBvZiAi bWV0aG9kcyIgbmVjZXNzYXJ5IHRvIGNvbnZpbmNlIHRoZWlyDQo+ID4+Pj4gSFcNCj4gPj4+Pj4g c3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVu dCB0bw0KPiA+PiBhY2hpZXZlDQo+ID4+Pj4gdGhlaXINCj4gPj4+Pj4gYnVzaW5lc3MgZ29hbHMu ICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJlIG5lY2Vzc2FyeSAuLi4NCj4gPj4g c2VlDQo+ID4+Pj4gYmVsb3cuDQo+ID4+Pj4NCj4gPj4+PiBDb3VsZCB5b3UgcGxlYXNlIGJyaWVm bHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJvdmUgY2hhbmdlIGluDQo+ID4+Pj4gRVhJU1RJ TkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/DQo+ID4+Pj4NCj4g Pj4+Pj4+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFk eSBjYXBhYmxlIG9mDQo+ID4+Pj4gYmFsYW5jaW5nIElQDQo+ID4+Pj4+IHRyYWZmaWMgZmxvd3Mg YmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUtdHVwbGUgb2YgVURQIHBhY2tldHMuDQo+ID4+ IEJ5DQo+ID4+Pj4gdXNpbmcgdGhlDQo+ID4+Pj4+IE1QTFMtaW4tVURQIGVuY2Fwc3VsYXRpb24s IHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJhbGFuY2luZw0KPiA+Pj4+IGNhcGFiaWxpdHkg b2YNCj4gPj4+Pj4gbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3 aXRob3V0IHJlcXVpcmluZyBhbnkNCj4gPj4+PiBjaGFuZ2UgdG8NCj4gPj4+Pj4gdGhlbS4gVGhh dCBpcyB0aGUgbWFqb3IgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBJZiB0aGlzIGlzIGEgY29uY2VybiwgdGhlbiB3aHkgbm90IGVuY2Fwc3VsYXRlIHRoZSB0cmFm ZmljIGluDQo+ID4+Pj4gTVBMUy9MMlRQdjMsIHdoaWNoDQo+ID4+Pj4+IHVzZXMgVURQL0lQLCBp biB0aGUgZmlyc3QgcGxhY2U/DQo+ID4+Pj4NCj4gPj4+PiBJZiBJIHVuZGVyc3RhbmQgaXQgY29y cmVjdGx5LCB5b3UgcHJlZmVyIHRvIHVzZSBNUExTLWluLUwyVFB2My1pbi0NCj4gPj4gVURQDQo+ ID4+Pj4gaW5zdGVhZCBvZiBNUExTLWluLVVEUCwgcmlnaHQ/DQo+ID4+Pj4NCj4gPj4+Pj4gSU1I TywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAoPykgY2hh bmdlIHRvDQo+ID4+Pj4gUkZDIDM5MzEsDQo+ID4+Pj4+IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBj b25uZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFja2V0cyAobm90IGNvbnRyb2wNCj4gPj4+PiBwYWNr ZXRzKQ0KPiA+Pj4+PiB0byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBz b3VyY2UgSVAgYWRkcmVzc2VzKSwNCj4gPj4gYmFzZWQNCj4gPj4+PiBvbiBhIGhhc2gNCj4gPj4+ Pj4gY2FsY3VsYXRpb24sIHRvIGFjaGlldmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92ZXIgZXhp c3RpbmcNCj4gPj4gZXF1aXBtZW50DQo+ID4+Pj4gaW4gYW4NCj4gPj4+Pj4gSVAtb25seSBjb3Jl LiAgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIgb2ZmDQo+ ID4+Pj4ganVzdCB1c2luZw0KPiA+Pj4+PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIp IGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0bw0KPiA+Pj4+IGFzc29jaWF0ZQ0KPiA+Pj4+ PiBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9sIENoYW5u ZWwuICBJbiBmYWN0LA0KPiA+Pj4+IGl0J3Mgbm90DQo+ID4+Pj4+IGNsZWFyIHRvIG1lIHRoYXQg ZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG1heSAvYWxyZWFkeS8gZG8gdGhpcywNCj4gPj4+PiBt YWtpbmcgYW55DQo+ID4+Pj4+ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVu bmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+Pj4gaW1wbGVtZW50YXRpb25zLg0K PiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCj4g Pj4+Pj4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2VseSBhIGNo YW5nZSB0aGF0IGlzDQo+ID4+Pj4gbGltaXRlZCB0byB0aGUNCj4gPj4+Pj4gImNvbnRyb2wgY2hh bm5lbCIgKHNvZnR3YXJlKSBvZiBleGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+PiBpbXBs ZW1lbnRhdGlvbnMuDQo+ID4+Pj4+IEhlY2ssIGl0IG1heSBldmVuIGJlIGJhY2t3YXJkcyBjb21w YXRpYmxlIHdpdGggZXhpc3RpbmcgTDJUUHYzDQo+ID4+Pj4+IGltcGxlbWVudGF0aW9ucy4gIChM MlRQdjMgaW1wbGVtZW50b3JzIHdvdWxkIG5lZWQgdG8gY29tbWVudCBvbg0KPiA+PiB0aGF0KS4N Cj4gPj4+Pg0KPiA+Pj4+IElNSE8sIG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1VRFAgb3Ig TVBMUy1pbi1VRFAsICB0aGUgaGFyZHdhcmUNCj4gPj4gb2YNCj4gPj4+PiBQRSByb3V0ZXJzIG5l ZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdyZXNzIFBFIHJvdXRlcnMgbmVlZCB0bw0KPiA+ PiBmaWxsDQo+ID4+Pj4gaW4gYW4gZW50cm9weSB2YWx1ZSBpbiB0aGUgc291cmNlIHBvcnQgZmll bGQgb2YgVURQIGhlYWRlcnMuDQo+ID4+Pj4NCj4gPj4+Pj4gMikgVGhlcmUgaXMgYSBzdWJzdGFu dGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBieSB1c2luZyAiU2Vzc2lvbg0KPiA+Pj4+IElE IiBhbmQNCj4gPj4+Pj4gIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJU UHYzIHBhY2tldCBpcyBpbnRlbmRlZA0KPiA+PiBmb3INCj4gPj4+PiB0aGUNCj4gPj4+Pj4gaWRl bnRpZmllZCBzZXNzaW9uLiAgUXVvdGluZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOg0K PiA+Pj4+PiAtLS1zbmlwLS0tDQo+ID4+Pj4+ICBMMlRQdjMgcHJvdmlkZXMgdHJhZmZpYyBzZXBh cmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAzMi1iaXQNCj4gPj4+PiBTZXNzaW9uDQo+ID4+Pj4+ ICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYz IENvb2tpZQ0KPiA+Pj4+PiAgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFu IGFkZGl0aW9uYWwgY2hlY2sgdG8NCj4gPj4gZW5zdXJlDQo+ID4+Pj4+ICB0aGF0IGFuIGFycml2 aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4NCj4gPj4+ Pj4gIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFu IGV4dHJhDQo+ID4+Pj4gZ3VhcmFudGVlDQo+ID4+Pj4+ICB0aGF0IHRoZSBTZXNzaW9uIElEIGxv b2t1cCB3YXMgcGVyZm9ybWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZQ0KPiA+Pj4+PiAgU2Vzc2lv biBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC4NCj4gPj4+Pj4gLS0tc25p cC0tLQ0KPiA+Pj4+PiAuLi4gaW4gcmVnYXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25v dyB0aGUgU2VjdXJpdHkgQXJlYQ0KPiA+PiBmb2xrcw0KPiA+Pj4+IGhhdmUsIGluIHRoZQ0KPiA+ Pj4+PiBwYXN0LCBoYWQgL3N1YnN0YW50aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1bGF0aW9u IG9mIE1QTFMgb3Zlcg0KPiA+PiBJUA0KPiA+Pj4+IHRyYW5zcG9ydC4NCj4gPj4+Pj4gSW4gZmFj dCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBv Zg0KPiA+PiBSRkMNCj4gPj4+PiA0NjY1Lg0KPiA+Pj4+PiAoVGhlcmUncyBsaWtlbHkgc2ltaWxh ciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhhdCB1c2UgTVBMUyBmb3INCj4gPj4+PiB0cmFu c3BvcnQpLg0KPiA+Pj4+PiBXaGlsZSBJJ20gbm90IHN1cmUgdGhhdCBTZWN1cml0eSBBcmVhIGZv bGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0KPiA+Pj4+IGRhaWx5IHRyYWZmaWMgb24NCj4gPj4+ Pj4gdGhlIE1QTFMgV0cgbWFpbGluZyBsaXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0aGlzIGNv bmNlcm4gd2lsbA0KPiA+Pj4+IGFyaXNlIGlmL3doZW4gdGhpcw0KPiA+Pj4+PiBkcmFmdCBnb2Vz IHRvIHRoZSBJRVNHIC4uLg0KPiA+Pj4+DQo+ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJl Y3RseSwgdGhlIHJlYXNvbiBmb3IgeW91ciBwcmVmZXJlbmNlIG9mDQo+ID4+IE1QTFMtDQo+ID4+ Pj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0eSBmZWF0 dXJlLiBJZiB0aGF0DQo+ID4+IGlzDQo+ID4+Pj4gc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxh aW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXINCj4gPj4gdGhhbg0KPiA+Pj4+ IE1QTFMtaW4tTDJUUCBpbiBwcmFjdGljZT8NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVnYXJkcywN Cj4gPj4+PiBYaWFvaHUNCj4gPj4+Pg0KPiA+Pj4+PiAzKSBGaW5hbGx5LCB0aGlzIGFwcHJvYWNo IG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5c3RlbXMgdGhhdA0KPiA+PiBpbXBsZW1lbnQNCj4gPj4+ PiBMMlRQLCBmb3INCj4gPj4+Pj4gdHVubmVsaW5nIG9mIE1QTFMvSVAsIGFuZCBkb2VzIG5vdCBy ZXF1aXJlIGFuIGVudGlyZSBpbmR1c3RyeSB0bw0KPiA+Pj4+IHN1cHBvcnQNCj4gPj4+Pj4gTVBM Uy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLg0KPiA+Pj4+Pg0KPiA+ Pj4+PiAtc2hhbmUNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCZXN0IHJl Z2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgdGhlcmUgd2Fz IG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0DQo+ID4+IHdv dWxkDQo+ID4+Pj4gaGF2ZQ0KPiA+Pj4+PiBiZWVuDQo+ID4+Pj4+Pj4gbW9yZSB3aWRlbHkgaW1w bGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMsIHdpdGggZWl0aGVyIE1QTFMNCj4gPj4+PiBv dmVyDQo+ID4+Pj4+IEdSRSBvcg0KPiA+Pj4+Pj4+IE1QTFMgb3ZlciBMMlRQdjMuICAoV2hlcmUg dGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSQ0KPiA+PiB3b3VsZA0KPiA+Pj4+IG5v dGUNCj4gPj4+Pj4gdGhhdA0KPiA+Pj4+Pj4+IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMg ZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmUNCj4gPj4gc2V2ZXJhbCwNCj4gPj4+PiBwcmFj dGljYWwNCj4gPj4+Pj4+PiBvcGVyYXRpb25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdvaW5n IHdpdGggbmF0aXZlIE1QTFMNCj4gPj4+Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGluZyB3aXRo aW4gdGhlIGRhdGEgcGxhbmUsIG5hbWVseToNCj4gPj4+Pj4+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0 ZQ0KPiA+Pj4+Pj4+IC0gTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nDQo+ID4+Pj4+Pj4gLi4uIHRv IG5hbWUsIGJ1dCBhIGZldy4gIFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNvbXBlbGxp bmcNCj4gPj4+Pj4gYXJndW1lbnRzDQo+ID4+Pj4+Pj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcg dG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4gLXNoYW5lDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtSm9zaA0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBPbiAxMi8xOC8xMiAxMjozMSBBTSwgIlNo YWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJyb2FkY29t LmNvbT4+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9yIHNlcnZp Y2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0aGVyZQ0KPiA+ PiBpcw0KPiA+Pj4+IG5vIG5lZWQNCj4gPj4+Pj4+Pj4+IHRvIGltcHJvdmUgaXQuDQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+IFNoYWhyYW0NCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDEyLCBhdCA4OjAyIFBN LCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWku Y29tPj4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFNoYWhyYW0s DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQg dG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUA0KPiA+Pj4+IGVuY2Fwc3VsYXRpb24NCj4gPj4+Pj4+ Pj4+PiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2FkLWJhbGFuY2luZyBhcHBsaWNhYmlsaXR5IHNv IGZhciB0bw0KPiA+Pj4+IHRob3NlDQo+ID4+Pj4+Pj4+Pj4gb3BlcmF0b3JzIHdobyBoYXBwZW4g dG8gcmVxdWlyZSB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbg0KPiA+Pj4+IHRyYWZmaWMN Cj4gPj4+Pj4+Pj4+PiBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQ TiBvdmVyIElQLCBOVkdSRQ0KPiA+PiBhbmQNCj4gPj4+Pj4gVlhMQU4NCj4gPj4+Pj4+Pj4+PiBl YWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91DQo+ID4+ IGFic29sdXRlbHkNCj4gPj4+PiBiZWxpZXZlDQo+ID4+Pj4+Pj4+Pj4gaXQncyBtZWFuaW5nbGVz cyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+ID4+Pj4gYWNyb3Nz IElQDQo+ID4+Pj4+Pj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBS RkNzIHJlbGF0ZWQgdG8gTVBMUw0KPiA+PiBvdmVyDQo+ID4+Pj4gSVANCj4gPj4+Pj4+Pj4+PiB0 dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLA0K PiA+PiBwbGVhc2UNCj4gPj4+PiBzYXkNCj4gPj4+Pj4gc28uDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+PiBCeSB0aGUgd2F5LCBpdCBzZWVtcyB0aGlzDQo+ID4+Pj4+Pj4+Pj4gKGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC0NCj4gPj4+PiBhcmNoaXZlL3dlYi9udm8zL2N1cnJlbnQvbXNnMDE4 NjQuaHRtbCkgaXMNCj4gPj4+Pj4+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUg Zm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcNCj4gPj4+PiBhcmd1bWVudA0KPiA+Pj4+Pj4+ Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRv IGRhdGENCj4gPj4+PiBjZW50ZXJzKS4gSQ0KPiA+Pj4+Pj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3 b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LA0KPiA+Pj4+IHN1cnByaXNpbmdseSBz aWxlbnQNCj4gPj4+Pj4+Pj4+PiB0aWxsIG5vdy4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lzZS4NCj4gPj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFhpYW9odQ0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+ IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+Pj4+Pj4+PiC3orz+yMs6IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0NCj4gPj4gtPoNCj4gPj4+ PiCx7Q0KPiA+Pj4+Pj4+IFMuDQo+ID4+Pj4+Pj4+Pj4+IERhdmFyaQ0KPiA+Pj4+Pj4+Pj4+PiC3 osvNyrG85DogMjAxMsTqMTLUwjE1yNUgMTM6MzQNCj4gPj4+Pj4+Pj4+Pj4gytW8/sjLOiBMb2Eg QW5kZXJzc29uDQo+ID4+Pj4+Pj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+Pj4+PiBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ ID4+Pj4+Pj4+Pj4+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBzdXBw b3J0IHRvIG1ha2UNCj4gPj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4gPj4+ Pj4+Pj4+Pj4gbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBs aWNhdGlvbiBpbg0KPiA+Pj4+IHRvZGF5J3MNCj4gPj4+Pj4+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+ ID4+Pj4+Pj4+Pj4+IGFuZCBjb3JlLCB3aGVyZSBNUExTIGlzIGRvbWluYW50LCBhbmQgaXRzIG9u bHkgcHJhY3RpY2FsDQo+ID4+Pj4gYXBwbGljYXRpb24NCj4gPj4+Pj4+Pj4+Pj4gaW4gaW4gZGF0 YQ0KPiA+Pj4+Pj4+Pj4+PiBjZW50ZXIsIHdoaWNoIGFscmVhZHkgaXMgY3Jvd2RlZCB3aXRoIG90 aGVyIHNvbHV0aW9ucyBzdWNoIGFzDQo+ID4+Pj4gTlZHUkUNCj4gPj4+Pj4gYW5kDQo+ID4+Pj4+ Pj4+Pj4+IFZYTEFOLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBJdCBzZWVtcyB0aGUg YXV0aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBzb2x1dGlvbg0KPiA+Pj4+IHNl bGVjdGlvbg0KPiA+Pj4+Pj4+Pj4+PiBwcm9jZXNzDQo+ID4+Pj4+Pj4+Pj4+IGJ5IGFkdmFuY2lu ZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gUmVn YXJkcywNCj4gPj4+Pj4+Pj4+Pj4gU2hhaHJhbQ0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+PiBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEgQU0sIExvYSBBbmRlcnNz b24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+PiBXb3JraW5nIGdyb3VwLA0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4gPj4+ Pj4+Pj4+Pj4+IGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2IGFzIGFuIE1QTFMgd29ya2luZyBncm91 cCBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhp cyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdpdGgNCj4gPj4+PiBvbmUgd2Vlay4NCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0 L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscw0KPiA+Pj4+PiB3b3JraW5nDQo+ID4+Pj4+Pj4+Pj4+ PiBncm91cCBtYWlsaW5nIGxpc3QgKG1wbHMgYXQgaWV0Zi5vcmc8aHR0cDovL2lldGYub3JnPiku IFBsZWFzZSBnaXZlIGFuDQo+ID4+Pj4gdGVjaG5pY2FsDQo+ID4+Pj4+Pj4+Pj4+PiBtb3RpdmF0 aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91DQo+ID4+ Pj4gdGhpbmsgdGhhdA0KPiA+Pj4+Pj4+Pj4+Pj4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUg YWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gPj4+PiBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3LCAyMDEzLg0KPiA+ Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0gYWdhaW5z dCB0aGlzIGRvY3VtZW50IC0NCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvaXByLzE5NDEvIC4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBBbGwgdGhl IGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXANCj4gPj4+ PiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9m IGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UNCj4gPj4+PiBhbHJlYWR5DQo+ID4+Pj4+ Pj4+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gSG93ZXZl ciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yDQo+ID4+ IHRoZQ0KPiA+Pj4+IElQUg0KPiA+Pj4+Pj4+Pj4+Pj4gcG9sbCkNCj4gPj4+Pj4+Pj4+Pj4+IE1h cnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2YgdGhlIGF1dGhvcnMuIE1hcnNoYWxs DQo+ID4+Pj4gaGFzDQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjb250aW51ZWQgYWxsIGludGVyYWN0aW9u cyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+ID4+Pj4gYXV0aG9yIHRlYW0NCj4gPj4+ Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29ya2luZyBncm91cCBj aGFpcnMgaGFzDQo+ID4+Pj4gdHJpZWQgdG8NCj4gPj4+Pj4+Pj4+Pj4+IGNvbnRhY3QgTWFyc2hh bGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbg0KPiA+PiB0aGUNCj4g Pj4+PiBJUFINCj4gPj4+Pj4+Pj4+Pj4+IHBvbGwuDQo+ID4+Pj4+Pj4+Pj4+PiBXZSBoYXZlIGhh ZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gRnJv bSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBNYXJzaGFsbCBhcyBh DQo+ID4+Pj4+Pj4+Pj4+PiBjby1hdXRob3IuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ Pj4gL0xvYQ0KPiA+Pj4+Pj4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+ID4+Pj4+Pj4+Pj4+ PiAtLQ0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBMb2Eg QW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQo+ID4+Pj4+Pj4+Pj4+IGxv YS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNv bT4NCj4gPj4+Pj4+Pj4+Pj4+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMgTWFuYWdlciAgICAg ICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KPiA+Pj4+Pj4+Pj4+Pj4gRXJpY3Nz b24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEwIDcxNw0KPiA1Mg0K PiA+PiAxMw0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKzQ2IDc2NyA3MiA5Mg0KPiAxMw0KPiA+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+Pj4+IG1wbHMgbWFp bGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPg0KPiA+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQo+ID4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+ Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+ Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzpt cGxzQGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIFRpbWUgV2FybmVyDQo+ID4+Pj4gQ2FibGUNCj4gPj4+Pj4+PiBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvcg0K PiA+Pj4+IHN1YmplY3QgdG8NCj4gPj4+Pj4+PiBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPiA+Pj4+IHNvbGVseSBmb3IN Cj4gPj4+Pj4gdGhlDQo+ID4+Pj4+Pj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPiA+Pj4+IGFyZSBub3QgdGhlDQo+ID4+ Pj4+Pj4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBu b3RpZmllZCB0aGF0DQo+ID4+Pj4gYW55DQo+ID4+Pj4+IGRpc3NlbWluYXRpb24sDQo+ID4+Pj4+ Pj4gZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8g dGhlDQo+ID4+IGNvbnRlbnRzDQo+ID4+Pj4gb2YgYW5kDQo+ID4+Pj4+Pj4gYXR0YWNobWVudHMg dG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlDQo+ID4+Pj4g dW5sYXdmdWwuIElmIHlvdQ0KPiA+Pj4+Pj4+IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+Pj4+IGltbWVkaWF0ZWx5IGFuZA0K PiA+Pj4+Pj4+IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9m IHRoaXMgRS1tYWlsIGFuZA0KPiA+Pj4+IGFueSBwcmludG91dC4NCj4gPj4+Pj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4gbXBs cyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4NCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+PiBtcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPg0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9DBszxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

It seems t= hat you are struggling to fight against any MPLS over IP encapsulation meth= od, but not just MPLS-in-UDP. If you do believe there is no application of any MPLS over IP encapsulation method, the best thing to do= is to request moving all existing MPLS over IP related RFCs to Historic st= atus.

 = ;

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: Shahram Davari [mailto:davari@broadcom.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C224=C8=D5 = 10:47
=CA=D5=BC=FE=C8=CB: Xuxiaohu
=B3=AD=CB=CD: S. Davari; Lucy yong; draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;= mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] MPLS client layer over an IGP underlying network

 

MPLS based VPN supports multica= st Tree, but only when Transport is MPLS and not IP. MPLS over IP does not = support Multicast tree. 

Regards,

Shahram

 

=
On Dec 23, 2012, at 6:32 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:

 

 

=B7=A2=BC=FE=C8= =CB: S. Davari [mailto:da= varish@yahoo.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C222=C8=D5 = 6:40
=CA=D5=BC=FE=C8=CB: Lucy yong; Xuxiaohu; Shahram Davari
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org; mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: Re: [mpls] MPLS client layer over an IGP underlying network=

 

Lucy,

I can only see China Telecom as co-author, and the Applicability section sa= ys L2VPN and L3VPN. So is China Telecom using it for their Enterprise VPN s= ervice? but your earlier emails suggests that this is not the intended usag= e rather it is for Data Center. So which one is it? Why isn't China Telecom speaking on the list and expla= ining their usage model?


[Xiaohu] Yes, the Applicability secti= on says L2VPN and L3VPN, but there is no limit that these technologies could only be used by service providers?  Enterprises themselves coul= d adopt these technologies to interconnect their multiple sites and data ce= nter operators could use them within or even across data centers as well if= they would like. Let me iterate that MPLS-based VPN over IP can be used in SP networks, enterprise networks and= even data centers and therefore MPLS-in-UDP is applicable to any of the ab= ove scenario as well.


Also regarding Multicast, this means you need to map Multicast traffic to P= 2P PW, which is inferior to other methods such as NVGRE and VXLAN since the= y natively support efficient Multicast.


[Xiaohu] First, remember that MPLS-in= -UDP is not only suitable for MPLS-based L2VPN but also suitable for L3VPN. Second, MPLS-based VPN can support both ingress replication mod= e and multicast tree mod


Thanks,
Shahram


 

 

From: Lucy= yong <lucy.yong@huawei.com&= gt;
To: S. Davari <davarish@yah= oo.com>; Xuxiaohu <xuxiaoh= u@huawei.com>; Shahram Davari <davari@broadcom.com>
Cc: "dra= ft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>; &qu= ot;mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Sent: Friday, December 21, 2012 1:55:10 PM
Subject: RE: [mpls] MPLS client layer over an IGP underlying network=




Shahram,<= /p>

 

Please see inline.

 

 

Hi,

I think we are in a vicious cycle. Could you please clarify which network o= perator is asking for MPLS over UDP and what is the application. 

[Lucy] it is indicated in the draft.

Also how do you plan to address the MPLS Multicast (which is probably more= important than improving the load balancing), given that RFC4023 does not support Multicast.<= /p>

[Lucy] MPLS Client Layer is responsible to map mu= lticast traffic to underlying transport, which is specified in EVPN and IP VPN. This proposal just requests ingress PE to fill the flo= w entropy into UDP source port, in which the flow can be unicast or multica= st.

 

Regards,=

Lucy

 



Thanks,
Shahram

 

 

From: Xuxiaohu <xuxiaohu@huawei.com>
To: Shahram Davari <davari= @broadcom.com>; Lucy yong <lucy.yong@huawei.com>
Cc: "dra= ft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>; &qu= ot;mpls@ietf.org" <mpls@ietf.org>; "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Sent: Thursday, December 20, 2012 5:56:23 PM
Subject: Re: [mpls] MPLS client layer over an IGP underlying network=




> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
> Shahram Davari
> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C221=C8=D5 1:31
> =CA=D5=BC=FE=C8=CB: Lucy yong
> =B3=AD=CB=CD: dr= aft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs= @tools.ietf.org;
> mpls@ietf.org > =D6=F7=CC=E2: Re: [mpls] MPLS client layer over an IGP underlying network
>
> Please don't mix up things. The MPLS protocol design I agree must be d= one by
> MPLS WG. But the question is whether your proposal meets the network > virtualization requirements.

Can you tell us where MPLS-in-GRE/IP [RFC4023] and other MPLS over IP encap= sulation mechanisms have been discussed before?

Since MPLS-in-UDP is just intended to be used in the scenarios where MPLS-i= n-GRE/IP has been used and is to be used, MPLS-in-UDP should be discussed i= n the same WG where MPLS-in-GRE/IP has been discussed.

Xiaohu

> The NVO3 task is to document the issues, requirements and framework fo= r
> NvO3. Then if MPLS over IP looks like a suitable solution that meets t= he
> requirements such as the scale, mobility, etc, then they will ask MPLS= WG for
> protocol design.
>
> So before proceeding this draft, I think you should take it to NVO3 WG= and
> convince them this solution meets their requirements and framework. >
> We don't want IETF do design N number of solutions for the same proble= m, do
> we?
>
> -Shahram
>
>
>
> Regards,
> Shahram
>
>
> On Dec 20, 2012, at 8:56 AM, "Lucy yong" <lucy.yong@huawei.com> wro= te:
>
> > Network virtualization overlay is discussed under nvo3 WG. This d= oes not
> mean that nvo3 WG has to design a new protocol for a underlying networ= k or a
> new protocol for a overlay network. In fact, people there aim on lever= age
> standard network protocols to accomplish them. IMO: these expansions o= n an
> existing standard protocol have to be worked out in the protocol WG gr= oup, it
> should not give nvo3 WG free right to enhance these protocols. For a b= rand
> new protocol for network virtualization overlay, nvo3 WG may be the pl= ace to
> start.
> >
> > Lucy
> >
> >> -----Original Message-----
> >> From: Shahram Davari [mailto:davari@broadcom.com]
> >> Sent: Thursday, December 20, 2012 10:34 AM
> >> To: Lucy yong
> >> Cc: Shane Amante; draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
> >> mpls-chairs@tools.ietf.org
> >> Subject: Re: [mpls] MPLS client layer over an IGP underlying = network
> >>
> >> Network virtualization overlay must be discussed and consente= d  in NVO3
> >> WG.
> >>
> >> Regards,
> >> Shahram
> >>
> >>
> >> On Dec 20, 2012, at 7:39 AM, "Lucy yong" <lucy.yong@huawei.com> wrote:
> >>
> >>> Hi Shane,
> >>>
> >>> I understand operator concern on a new encapsulation to a= n existing
> >> network.
> >>>
> >>> However, MPLS-in-UDP does not aim on changing existing SP= IP/MPLS
> >> network at all.
> >>> MPLS-in-UDP is to enable MPLS client layer to be decouple= d from MPLS
> >> server layer and use MPLS client layer as overlay network and= an IGP as
> >> a underlying network for transport. Such application is for D= C. You may
> >> argue why not use the GRE which is for MPLS layer over an IGP= underling
> >> network. We have pointed out in the draft that current router= s in DC
> >> barely support GRE based load balancing and MPLS-in-GRE are b= arely used
> >> in SP networks too. Most of routers in DC perform upd port ba= sed load
> >> balancing now.
> >>>
> >>> From the architecture perspective, the UDP encapsulation = has
> >> advantage over GRE encapsulation too. In UDP encapsulation, t= he frame
> >> header decouples the overlay and underlying network clearly, = i.e. outer
> >> header and overlay header. UDP belongs to outer header, which=
> >> underlying network uses only. However, GRE header has the fie= lds for
> >> the overlay network and uses the key field for flow entropy. = For load
> >> balancing, it requires the underlying network uses GRE header= too. In
> >> short, GRE ties the overlay and underlying networks together.= Since it
> >> has not used a lot, people are not aware of the disadvantage = of such
> >> coupling.
> >>>
> >>> As the industry moves toward network virtualization overl= ay and
> >> decouples overlay networks from the underlying network. A cle= ar
> >> separation of overlay header and underlying header is a "= ;MUST" in my
> >> opinion. If we count GRE as the overlay header, then for IPv4=
> >> underlying network, there is no field for the flow entropy. T= his is the
> >> reason we propose the UDP encapsulation: for an IGP based und= erlying
> >> network. In fact, it can support any overlay network beside M= PLS client
> >> layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >>>
> >>> You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPL= S-in-L2TP-
> >> in-UDP schema also provides a overlay (L2TP) and underlying (= IP)
> >> network decoupling. L2TP protocol (rfc3931) provides good sec= urity
> >> mechanism and has the embedded control function too. Therefor= e,
> someone
> >> can use it for MPLS client layer over Internet. To have MPLS = client
> >> layer over an IGP underling network, IMO: MPLS-in-L2TP-in-UDP= is a
> >> overkill and too complex. Here we need a schema to support IG= P
> >> underlying transport without touching a overlay header. UDP > >> encapsulation is the best choice to accomplish that and minim= ize the
> >> changes on existing routers, e.g. change at edge routers, no = change on
> >> transit routers.
> >>>
> >>> Regards,
> >>> Lucy
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> >>>> Sent: Thursday, December 20, 2012 4:14 AM
> >>>> To: Shane Amante
> >>>> Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in- > >> udp@t= ools.ietf.org;
> >>>> mp= ls@ietf.org; mpls-chairs@tools.ietf.org
> >>>> Subject: Discussion on how to transport MPLS over UDP= tunnels
> >>>>
> >>>> Hi Shane,
> >>>>
> >>>> Thanks for your further comments and please see my re= sponse inline.
> >>>>
> >>>> Note: I changed the subject line according to Loa's s= uggestion.
> >>>>
> >>>>> -----=D3=CA=BC= =FE=D4=AD=BC=FE-----
> >>>>> =B7=A2=BC=FE= =C8=CB: Shane Amante [mailto:shane@castlepoint.net] > >>>>> =B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 22:38
> >>>>> =CA=D5=BC=FE= =C8=CB: Xuxiaohu
> >>>>> =B3=AD=CB=CD: Rogers, Josh; Shahram Davari; draft-xu-mpl= s-in-
> >>>> udp@tools.ietf.org;
> >>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>>> =D6=F7=CC=E2: Re: [mpls] poll to see if we have support = to make draft-xu-
> >>>> mpls-in-udp an
> >>>>> mpls working group document
> >>>>>
> >>>>> Xiaohu,
> >>>>>
> >>>>> On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com&= gt;
> wrote:
> >>>>> -----=D3=CA=BC= =FE=D4=AD=BC=FE-----
> >>>>>>> =B7=A2= =BC=FE=C8=CB: Shane Amante [mailto:shane@castlepoint.net]
> >>>>>>> =B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
> >>>>>>> =CA=D5= =BC=FE=C8=CB: Rogers, Josh
> >>>>>>> =B3=AD= =CB=CD: Shahram Davari; Xuxiaohu; draft-xu= -mpls-in-
> >>>> udp@tools.ietf.org;
> >>>>>>> mpls@ietf.org; mpls-chairs@tools.ietf.org
> >>>>>>> =D6=F7= =CC=E2: Re: [mpls] poll to see if we have = support to make draft-xu-
> >>>> mpls-in-udp
> >>>>> an
> >>>>>>> mpls working group document
> >>>>>>>
> >>>>>>>
> >>>>>>> On Dec 18, 2012, at 8:50 AM, "Rogers= , Josh"
> >>>> <josh.rogers@twcable.com>
> >>>>>>> wrote:
> >>>>>>>> I share your SP perspective, and do n= ot see the problem this
> >>>> solution
> >>>>>>>> addresses in practice any longer.
> >>>>>>>
> >>>>>>> +1.  Please do not define yet an= other MPLS-over-IP encapsulation.
> >>>> The
> >>>>> IETF
> >>>>>>> already standardized MPLS over GRE. = The IETF has also
> >>>> standardized
> >>>>> MPLS
> >>>>>>> over L2TPv3/UDP/IP, which had seen some d= eployment in at least
> >> one,
> >>>> very
> >>>>>>> large operator network that I'm aware of = to support carriage of
> >>>> L3VPN over
> >>>>> an
> >>>>>>> IP-only network.
> >>>>>>
> >>>>>> Hi Shane,
> >>>>>>
> >>>>>> Thank you for telling us there are actual dep= loyments of MPLS over
> >>>> IP in at
> >>>>> least one, very large operator network. This fact= must be very
> >>>> valuable to those
> >>>>> people who had believed there is no application o= f MPLS over IP in
> >>>> today's SP
> >>>>> networks.
> >>>>>>
> >>>>>>> See: RFC's 4454, 4719, 4591, 4349 for PWE= 3 over L2TPv3
> >>>>>>> [NOTE: the dates the above were published= was back in the 2006
> >>>>> timeframe!]
> >>>>>>>  RFC 4665 for requirements related t= o VPLS that say that VPLS
> >>>> may be
> >>>>>>> carried over L2TPv3
> >>>>>>>  And, here's evidence showing that a= t least one vendor has
> >>>>> implemented
> >>>>>>> IPVPN's over L2TPv3:
> >> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html <= br> > >>>>>>
> >>>>>> Thanks again for sharing the above informatio= n. As mentioned in
> >>>> this draft
> >>>>> AND other drafts, the mechanism of performing has= h calculation on
> >> the
> >>>> Session
> >>>>> ID field in the L2TPv3 header or the Key field in= the GRE header as
> >>>> defined in
> >>>>> [RFC 5640] is not widely supported by existing co= re routers so far.
> >>>>>
> >>>>> FWIW, I have had success, in the relatively recen= t past, in
> >>>> requesting a core
> >>>>> router vendor to support changes to the input-key= s used in hash
> >>>> calculations in
> >>>>> _existing_ hardware, already deployed (extensivel= y) throughout my
> >>>> network.
> >>>>> Further, I suspect that most large network operat= ors are savvy
> >> folks
> >>>> and
> >>>>> understand the internal architecture of their HW = fairly well.  As a
> >>>> result, those
> >>>>> same operators know what is and is not technicall= y possible in this
> >>>> regard.
> >>>>> Thus, it may be a question of "methods"= necessary to convince their
> >>>> HW
> >>>>> supplier(s) to make appropriate changes in their = equipment to
> >> achieve
> >>>> their
> >>>>> business goals.  :-)  However, this may= not even be necessary ...
> >> see
> >>>> below.
> >>>>
> >>>> Could you please briefly explain how to make the abov= e change in
> >>>> EXISTING hardware of already deployed core routers? > >>>>
> >>>>>> In contrast, most existing core routers are a= lready capable of
> >>>> balancing IP
> >>>>> traffic flows based on the hash of the five-tuple= of UDP packets.
> >> By
> >>>> using the
> >>>>> MPLS-in-UDP encapsulation, the already available = load-balancing
> >>>> capability of
> >>>>> most existing core routers can be leveraged witho= ut requiring any
> >>>> change to
> >>>>> them. That is the major motivation of this draft.=
> >>>>>
> >>>>> If this is a concern, then why not encapsulate th= e traffic in
> >>>> MPLS/L2TPv3, which
> >>>>> uses UDP/IP, in the first place?
> >>>>
> >>>> If I understand it correctly, you prefer to use MPLS-= in-L2TPv3-in-
> >> UDP
> >>>> instead of MPLS-in-UDP, right?
> >>>>
> >>>>> IMHO, a better proposal may be to consider a [min= or] (?) change to
> >>>> RFC 3931,
> >>>>> which would allow the connection used for data pa= ckets (not control
> >>>> packets)
> >>>>> to use a varying set of source ports (or, source = IP addresses),
> >> based
> >>>> on a hash
> >>>>> calculation, to achieve better load-balancing ove= r existing
> >> equipment
> >>>> in an
> >>>>> IP-only core.  L2TP end-system implementatio= ns would be better off
> >>>> just using
> >>>>> the "Session ID" (and "Cookie"= ;) fields as the demultiplexor to
> >>>> associate
> >>>>> incoming packets with the associated L2TP Control= Channel.  In fact,
> >>>> it's not
> >>>>> clear to me that existing implementations may /al= ready/ do this,
> >>>> making any
> >>>>> "check" on the incoming source port unn= ecessary for L2TP end-system
> >>>>> implementations.
> >>>>>
> >>>>> The beauty of the above approach is:
> >>>>> 1) I would think that the above is most likely a = change that is
> >>>> limited to the
> >>>>> "control channel" (software) of existin= g L2TP end-system
> >>>> implementations.
> >>>>> Heck, it may even be backwards compatible with ex= isting L2TPv3
> >>>>> implementations.  (L2TPv3 implementors would= need to comment on
> >> that).
> >>>>
> >>>> IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP,=   the hardware
> >> of
> >>>> PE routers needs to be upgraded, e.g., ingress PE rou= ters need to
> >> fill
> >>>> in an entropy value in the source port field of UDP h= eaders.
> >>>>
> >>>>> 2) There is a substantial added security one gets= by using "Session
> >>>> ID" and
> >>>>> "Cookie" fields to ensure the received = L2TPv3 packet is intended
> >> for
> >>>> the
> >>>>> identified session.  Quoting from Section 8.= 2 of RFC 3931:
> >>>>> ---snip---
> >>>>>  L2TPv3 provides traffic separation for its = VPNs via a 32-bit
> >>>> Session
> >>>>>  ID in the L2TPv3 data header.  When pr= esent, the L2TPv3 Cookie
> >>>>>  (described in Section 4.1), provides an add= itional check to
> >> ensure
> >>>>>  that an arriving packet is intended for the= identified session.
> >>>>>  Thus, use of a Cookie with the Session ID p= rovides an extra
> >>>> guarantee
> >>>>>  that the Session ID lookup was performed pr= operly and that the
> >>>>>  Session ID itself was not corrupted in tran= sit.
> >>>>> ---snip---
> >>>>> ... in regard to this question alone, I know the = Security Area
> >> folks
> >>>> have, in the
> >>>>> past, had /substantial/ concerns about encapsulat= ion of MPLS over
> >> IP
> >>>> transport.
> >>>>> In fact, this is why you see text in Section 7.6,= "Security", of
> >> RFC
> >>>> 4665.
> >>>>> (There's likely similar language in other drafts = that use MPLS for
> >>>> transport).
> >>>>> While I'm not sure that Security Area folks pay m= uch attention to
> >>>> daily traffic on
> >>>>> the MPLS WG mailing list, I'm fairly confident th= is concern will
> >>>> arise if/when this
> >>>>> draft goes to the IESG ...
> >>>>
> >>>> If I understand it correctly, the reason for your pre= ference of
> >> MPLS-
> >>>> in-L2TPv3-in-UDP is that it has an added security fea= ture. If that
> >> is
> >>>> so concerned, can you explain why MPLS-in-GRE is far = more popular
> >> than
> >>>> MPLS-in-L2TP in practice?
> >>>>
> >>>> Best regards,
> >>>> Xiaohu
> >>>>
> >>>>> 3) Finally, this approach only affects the end-sy= stems that
> >> implement
> >>>> L2TP, for
> >>>>> tunneling of MPLS/IP, and does not require an ent= ire industry to
> >>>> support
> >>>>> MPLS/UDP encapsulation in their product lines. > >>>>>
> >>>>> -shane
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Xiaohu
> >>>>>>
> >>>>>>> If there was market demand for MPLS over = IP, then clearly it
> >> would
> >>>> have
> >>>>> been
> >>>>>>> more widely implemented by equipment vend= ors, with either MPLS
> >>>> over
> >>>>> GRE or
> >>>>>>> MPLS over L2TPv3.  (Where there's a = will, there's a way).  I
> >> would
> >>>> note
> >>>>> that
> >>>>>>> the most likely reasons this did not pan = out was there are
> >> several,
> >>>> practical
> >>>>>>> operational benefits one gets from going = with native MPLS
> >>>>>>> encapsulation/switching within the data p= lane, namely:
> >>>>>>> - MPLS Fast Re-Route
> >>>>>>> - MPLS Traffic Engineering
> >>>>>>> ... to name, but a few.  Those have = tended to be quite compelling
> >>>>> arguments
> >>>>>>> to 'upgrade' network HW to support MPLS e= ncapsulation/switching.
> >>>>>>>
> >>>>>>> -shane
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Josh
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/18/12 12:31 AM, "Shahram D= avari" <da= vari@broadcom.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> For service provider domain, MPLS= over IP is legacy and there
> >> is
> >>>> no need
> >>>>>>>>> to improve it.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Shahram
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Dec 17, 2012, at 8:02 PM, &quo= t;Xuxiaohu" <xuxiaohu@huawei.com>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Shahram,
> >>>>>>>>>>
> >>>>>>>>>> This draft is ONLY intended t= o provide a MPLS-over-IP
> >>>> encapsulation
> >>>>>>>>>> method with a better load-bal= ancing applicability so far to
> >>>> those
> >>>>>>>>>> operators who happen to requi= re transporting MPLS application
> >>>> traffic
> >>>>>>>>>> across IP networks. I believe= MPLS-based VPN over IP, NVGRE
> >> and
> >>>>> VXLAN
> >>>>>>>>>> each have their own advocator= s and use cases. If you
> >> absolutely
> >>>> believe
> >>>>>>>>>> it's meaningless of transport= ing MPLS application traffic
> >>>> across IP
> >>>>>>>>>> networks and therefore those = existing RFCs related to MPLS
> >> over
> >>>> IP
> >>>>>>>>>> tunneling mechanisms should b= e moved to Historic status,
> >> please
> >>>> say
> >>>>> so.
> >>>>>>>>>>
> >>>>>>>>>> By the way, it seems this
> >>>>>>>>>> (http://www.ietf.org/mail-
> >>>> archive/web/nvo3/current/msg01864.html) is
> >>>>>>>>>> just the right thread suitabl= e for you to make the following
> >>>> argument
> >>>>>>>>>> (i.e., whether or not MPLS-ba= sed VPN is applicable to data
> >>>> centers). I
> >>>>>>>>>> had thought you would speak u= p at that time. Sadly,
> >>>> surprisingly silent
> >>>>>>>>>> till now.
> >>>>>>>>>>
> >>>>>>>>>> Sigh, I didn't intend to say = the above otherwise.
> >>>>>>>>>>
> >>>>>>>>>> Xiaohu
> >>>>>>>>>>
> >>>>>>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
> >>>>>>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org]
> >> =B4=FA
> >>>> =B1=ED
> >>>>>>> S.
> >>>>>>>>>>> Davari
> >>>>>>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12<= /span>=D4=C2= 15=C8=D5 13:34
> >>>>>>>>>>> =CA=D5=BC=FE=C8=CB: Loa Andersso= n
> >>>>>>>>>>> =B3=AD=CB=CD: dr= aft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
> >>>>>>>>>>> mpls-chairs@tools.ietf.org
> >>>>>>>>>>> =D6=F7=CC=E2: Re: [mpls] poll to= see if we have support to make
> >>>>>>>>>>> draft-xu-mpls-in-udp an > >>>>>>>>>>> mpls working group docume= nt
> >>>>>>>>>>>
> >>>>>>>>>>> I don't support this draf= t since it has no application in
> >>>> today's
> >>>>>>>>>>> modern metro
> >>>>>>>>>>> and core, where MPLS is d= ominant, and its only practical
> >>>> application
> >>>>>>>>>>> in in data
> >>>>>>>>>>> center, which already is = crowded with other solutions such as
> >>>> NVGRE
> >>>>> and
> >>>>>>>>>>> VXLAN.
> >>>>>>>>>>>
> >>>>>>>>>>> It seems the authors are = trying to bypass the NVO3 solution
> >>>> selection
> >>>>>>>>>>> process
> >>>>>>>>>>> by advancing the draft in= MPLS WG.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Shahram
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 14, 2012, at 1:01 = AM, Loa Andersson <loa@pi= .nu> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Working group,
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is to start a &q= uot;two week" poll on adopting
> >>>>>>>>>>>> draft-xu-mpls-in-udp-= 06 as an MPLS working group document.
> >>>>>>>>>>>> Due to the holiday se= ason this poll has been extended with
> >>>> one week.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please send your comm= ents (support/not support) to the mpls
> >>>>> working
> >>>>>>>>>>>> group mailing list (m= pls at ietf.org). Please give an
> >>>> technical
> >>>>>>>>>>>> motivation for your s= upport/not support, especially if you
> >>>> think that
> >>>>>>>>>>>> the document should n= ot be adopted as a working group
> >>>> document.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This poll ends Januar= y 07, 2013.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There is one IPR clai= m against this document -
> >>>>>>>>>>>> https://datatracker.ietf.or= g/ipr/1941/ .
> >>>>>>>>>>>>
> >>>>>>>>>>>> All the active co-aut= hors has stated on the working group
> >>>> mailing list
> >>>>>>>>>>>> that they are not awa= re of any other IPR claims than those
> >>>> already
> >>>>>>>>>>>> disclosed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> However, up to versio= n -03 (the document that we used for
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll)
> >>>>>>>>>>>> Marshall Eubanks was = listed as one of the authors. Marshall
> >>>> has
> >>>>>>>>>>>> discontinued all inte= ractions with the IETF, including the
> >>>> author team
> >>>>>>>>>>>> of draft-xu-mpls-in-u= dp-06. The working group chairs has
> >>>> tried to
> >>>>>>>>>>>> contact Marshall by o= ther means, to try get a response on
> >> the
> >>>> IPR
> >>>>>>>>>>>> poll.
> >>>>>>>>>>>> We have had no succes= s in this.
> >>>>>>>>>>>>
> >>>>>>>>>>>> From version -04 the = authors decided to remove Marshall as a
> >>>>>>>>>>>> co-author.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Loa
> >>>>>>>>>>>> (mpls wg co-chair) > >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Loa Andersson  &= nbsp;                    = email:
> >>>>>>>>>>> loa.andersson@ericsson.com
> >>>>>>>>>>>> Sr Strategy and Stand= ards Manager            loa@pi.nu
> >>>>>>>>>>>> Ericsson Inc  &n= bsp;                     =   phone: +46 10 717
> 52
> >> 13
> >>>>>>>>>>>>      &= nbsp;                    =             +46 767 72 92
> 13
> >>>>>>>>>>>> _____________________= __________________________
> >>>>>>>>>>>> mpls mailing list
> >>>>>>>>>>>> mpls@ietf.org
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>>> _________________________= ______________________
> >>>>>>>>>>> mpls mailing list
> >>>>>>>>>>> mpls@ietf.org
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>>> _____________________________= __________________
> >>>>>>>>>> mpls mailing list
> >>>>>>>>>> mpls@ietf.org
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>> _________________________________= ______________
> >>>>>>>>> mpls mailing list
> >>>>>>>>> mpls@ietf.org
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This E-mail and any of its attachment= s may contain Time Warner
> >>>> Cable
> >>>>>>> proprietary information, which is privile= ged, confidential, or
> >>>> subject to
> >>>>>>> copyright belonging to Time Warner Cable.= This E-mail is intended
> >>>> solely for
> >>>>> the
> >>>>>>> use of the individual or entity to which = it is addressed. If you
> >>>> are not the
> >>>>>>> intended recipient of this E-mail, you ar= e hereby notified that
> >>>> any
> >>>>> dissemination,
> >>>>>>> distribution, copying, or action taken in= relation to the
> >> contents
> >>>> of and
> >>>>>>> attachments to this E-mail is strictly pr= ohibited and may be
> >>>> unlawful. If you
> >>>>>>> have received this E-mail in error, pleas= e notify the sender
> >>>> immediately and
> >>>>>>> permanently delete the original and any c= opy of this E-mail and
> >>>> any printout.
> >>>>>>>> _____________________________________= __________
> >>>>>>>> mpls mailing list
> >>>>>>>> mpls@ietf.org
> >>>>>>>> https://www.ietf.org/mailman/listinfo/m= pls
> >>>
> >>> _______________________________________________
> >>> mpls mailing list
> >>> mpls@i= etf.org
> >>> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 <= /p>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A9DBszxeml525mbschi_-- From xuxiaohu@huawei.com Mon Dec 24 02:18:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C64921F8BCD for ; Mon, 24 Dec 2012 02:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4fx3nyuSgDR for ; Mon, 24 Dec 2012 02:18:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7739A21F8BC4 for ; Mon, 24 Dec 2012 02:18:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT96913; Mon, 24 Dec 2012 10:18:17 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 10:18:00 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Dec 2012 10:18:16 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.003; Mon, 24 Dec 2012 18:17:52 +0800 From: Xuxiaohu To: Xuxiaohu , "Andrew G. Malis" , Lucy yong Thread-Topic: MPLS over L2TP over UDP//re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3Olzo1M6JwDPXkycxIud0O1KBJgeLvSAgADLHACAAKzhwIAABiEAgANl/ICAAA9vAIAAByGAgAQcN6CAAH11QA== Date: Mon, 24 Dec 2012 10:17:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758CA81@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758CA81szxeml525mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS over L2TP over UDP//re: poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 10:18:22 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758CA81szxeml525mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KQnkgdGhlIHdheSwgYWNjb3JkaW5nIHRvIHRoZSBmb2xsb3dpbmcgc3RhdGVt ZW50IHF1b3RlZCBmcm9tIEwyVFB2MyBzcGVjaWZpY2F0aW9uIFtSRkMzOTMxXSwgaXQgc2VlbXMg dGhhdCB0aGUgVURQIHBvcnRzIGluIHRoZSBNUExTIG92ZXIgTDJUUCBvdmVyIFVEUCBjYXNlIGFy ZSBub3Qgc3VmZmljaWVudCBmb3IgZmluZS1ncmFpbmVkIGxvYWQtYmFsYW5jaW5nLg0KNC4xLjIu MjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzOTMxI3NlY3Rpb24tNC4xLjIuMj4uICBV RFAgUG9ydCBTZWxlY3Rpb24NCg0KDQogICBUaGUgbWV0aG9kIGZvciBVRFAgUG9ydCBTZWxlY3Rp b24gZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24gaXMNCiAgIGlkZW50aWNhbCB0byB0aGF0IGRlZmlu ZWQgZm9yIEwyVFB2MiBbUkZDMjY2MTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyNjYx Pl0uDQoNCiAgIFdoZW4gbmVnb3RpYXRpbmcgYSBjb250cm9sIGNvbm5lY3Rpb24gb3ZlciBVRFAs IGNvbnRyb2wgbWVzc2FnZXMgTVVTVA0KICAgYmUgc2VudCBhcyBVRFAgZGF0YWdyYW1zIHVzaW5n IHRoZSByZWdpc3RlcmVkIFVEUCBwb3J0IDE3MDENCiAgIFtSRkMxNzAwPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzE3MDA+XS4gIFRoZSBpbml0aWF0b3Igb2YgYW4gTDJUUCBjb250cm9s IGNvbm5lY3Rpb24gcGlja3MgYW4NCiAgIGF2YWlsYWJsZSBzb3VyY2UgVURQIHBvcnQgKHdoaWNo IG1heSBvciBtYXkgbm90IGJlIDE3MDEpIGFuZCBzZW5kcyB0bw0KICAgdGhlIGRlc2lyZWQgZGVz dGluYXRpb24gYWRkcmVzcyBhdCBwb3J0IDE3MDEuICBUaGUgcmVjaXBpZW50IHBpY2tzIGENCiAg IGZyZWUgcG9ydCBvbiBpdHMgb3duIHN5c3RlbSAod2hpY2ggbWF5IG9yIG1heSBub3QgYmUgMTcw MSkgYW5kIHNlbmRzDQogICBpdHMgcmVwbHkgdG8gdGhlIGluaXRpYXRvcidzIFVEUCBwb3J0IGFu ZCBhZGRyZXNzLCBzZXR0aW5nIGl0cyBvd24NCiAgIHNvdXJjZSBwb3J0IHRvIHRoZSBmcmVlIHBv cnQgaXQgZm91bmQuDQoNCg0KDQpMYXUsIGV0IGFsLiAgICAgICAgICAgICAgICAgU3RhbmRhcmRz IFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxOV0NCjxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmMzOTMxI3BhZ2UtMjA+DQpSRkMgMzkzMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMzOTMxPiAgICAgICAgICAgICAgICAgICAgICAgICBMMlRQdjMgICAgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDUNCg0KDQogICBBbnkgc3Vic2VxdWVudCB0cmFmZmljIGFzc29j aWF0ZWQgd2l0aCB0aGlzIGNvbnRyb2wgY29ubmVjdGlvbg0KICAgKGVpdGhlciBjb250cm9sIHRy YWZmaWMgb3IgZGF0YSB0cmFmZmljIGZyb20gYSBzZXNzaW9uIGVzdGFibGlzaGVkDQogICB0aHJv dWdoIHRoaXMgY29udHJvbCBjb25uZWN0aW9uKSBtdXN0IHVzZSB0aGVzZSBzYW1lIFVEUCBwb3J0 cy4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBYdXhpYW9odQ0Kt6LLzcqx vOQ6IDIwMTLE6jEy1MIyNMjVIDEwOjUzDQrK1bz+yMs6ICdBbmRyZXcgRy4gTWFsaXMnOyBMdWN5 IHlvbmcNCrOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZw0K1vfM4jogcmU6IFttcGxzXSBwb2xs IHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBh biBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCg0KSGkgQW5keSwNCg0KQXMgZGlzY3Vzc2Vk IGJlZm9yZSwgobBwZXJmb3JtaW5nIGhhc2ggY2FsY3VsYXRpb24gb24gdGhlICJsb2FkLWJhbGFu Y2luZyIgZmllbGQgY29udGFpbmVkIGluIHRoZSB0dW5uZWwgZW5jYXBzdWxhdGlvbiBoZWFkZXJz IChpLmUuLCB0aGUgU2Vzc2lvbiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUg S2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyKSBtZWFucyBhIG5vbi10cml2aWFsIGNoYW5nZSB0 byB0aGUgZGF0ZSBwbGFuZSBvZiBtYW55IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhbmQgdGhlcmVm b3JlIG5vdCB3aWRlbHkgc3VwcG9ydGVkIGJ5IG1vc3QgZXhpc3RpbmcgY29yZSByb3V0ZXJzIHll dC6hsQ0KDQpCeSB0aGUgd2F5LCB5b3UgbWF5IGhhcyBtaXNzZWQgYSBwcmV2aW91cyBjb21tZW50 IG1hZGUgYnkgQ2FybG9zIChzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L21wbHMvY3VycmVudC9tc2cwOTI1OC5odG1sKSwgaXQgc2FpZCChsFlvdSBtZW50aW9uIFJGQyAz OTMxIC0tIEwyVFB2MyBkZWZpbmVzIEwyVFAgZGlyZWN0bHkgb3ZlciBJUCAoSVAgUHJvdG9jb2wg bnVtYmVyIDExNSkgYXMgYSBNVVNULCBhbmQgTDJUUCBvdmVyIFVEUCBhcyBhIFNIT1VMRC4gSW1w bGVtZW50YXRpb25zIG1pZ2h0IG5vdCBzdXBwb3J0IEwyVFB2MyBvdmVyIFVEUC6hsQ0KDQpCZXN0 IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQW5kcmV3IEcuIE1hbGlzDQq3osvNyrG85Dog MjAxMsTqMTLUwjIyyNUgMzo1Mw0KytW8/sjLOiBMdWN5IHlvbmcNCrOty806IGRyYWZ0LXh1LW1w bHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgbXBs c0BpZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBv cnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9j dW1lbnQNCg0KTHVjeSwNClN1cmUsIGJ1dCBpdCBjb3VsZCBiZSBzYXRpc2ZpZWQgYnkgTVBMUyBv dmVyIEwyVFAgb3ZlciBVRFAsIG9yIGhhc2hpbmcgb24gdGhlIEdSRSBrZXkgZm9yIE1QTFMgb3Zl ciBHUkUuDQpDaGVlcnMsDQpBbmR5DQoNCk9uIEZyaSwgRGVjIDIxLCAyMDEyIGF0IDI6MjcgUE0s IEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWku Y29tPj4gd3JvdGU6DQpBbmR5LA0KDQpIZXJlIGlzIHRoZSB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1u dm8zLWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0DQoNCiAgMy4zLjIuMS4gTEFHIGFuZCBF Q01QDQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVhc29ucywgbXVsdGlwYXRoIG92ZXIgTEFH IGFuZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAgIHN1cHBvcnRlZC4NCg0KICAgICAgIExB RyAoTGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUgODAyLjFBWC0yMDA4XSBhbmQgRUNNUCAo RXF1YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFyZSBjb21tb25seSB1c2VkIHRlY2huaXF1 ZXMgdG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvZiBtaWNyb2Zsb3dzIG92ZXIg YSBzZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIgYXQNCiAgICAgICBMYXllci0yIChMQUcp IG9yIExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBsb3llZCBoYXJkd2FyZQ0KICAgICAgIGlt cGxlbWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNlcyBhIGhhc2ggb2YgdmFyaW91cyBmaWVs ZHMgaW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24gKG91dGVybW9zdCkgaGVhZGVyKHMpIChl LmcuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQogICAgICAgYWRkcmVzc2VzIGZvciBub24t SVAgdHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzZXMsDQogICAgICAg TDQgcHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBldGMp Lg0KICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBkZXBsb3llZCBmb3IgdGhlIHVuZGVybGF5 IG5ldHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qgb2Z0ZW4gdW5hd2FyZSBvZiB0aGUgY2Fy cmllZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBwYWNrZXRzDQogICAgICAgdHJhbnNtaXR0 ZWQgYnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBwZXJmb3JtIGZpbmUtZ3JhaW5lZCBsb2Fk LQ0KICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQgRUNNUCBwYXRocyBpbiB0aGUgdW5kZXJs eWluZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1bGF0aW9uIE1VU1QgcmVzdWx0IGluIHN1 ZmZpY2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwNCiAgICAgICBwYXRocyB0aHJvdWdoIHNl dmVyYWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkgaW5mb3JtYXRpb24gTUFZIGJlDQogICAg ICAgaW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5IGhlYWRlciBvciB1bmRlcmxheSBoZWFk ZXIuDQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZhbmNlZCBzb2x1dGlvbiBpbiB0aGlzIHNw YWNlLg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDog RnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAxMjozMiBQTQ0KVG86IFNoYW5lIEFtYW50ZQ0KQ2M6 IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxz LWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3Vw cG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuIG1wbHMgd29ya2luZyBncm91cCBk b2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBlYXJsaWVyIG9uIHRoaXMgZHJhZnQsIGFuZCBsaWtl IFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNlZCBvZiBpdHMgdXRpbGl0eS4gSSBzdGlsbCBkb24n dCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkgYXQgYWxsIGZvciBjb3JlIGJhY2tib25lIG5ldHdv cmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMsIG9yIGlmIHlvdSBtdXN0IHR1bm5lbCBNUExTIG92 ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVuY2Fwc3VsYXRpb25zLiBSZWdhcmRpbmcgZGF0YSBj ZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNzIEkgY291bGQgYmUgY29udmluY2VkLCBidXQgSSB3 b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1c3RpZmljYXRpb24gaW4gdGhlIGZvcm0gb2YgcmVx dWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNvdWxkIG9ubHkgYmUgbWV0IGJ5IHRoaXMgZHJhZnQu DQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2VkLCBEZWMgMTksIDIwMTIgYXQgOTozOCBBTSwgU2hh bmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2ludC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50 Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpPbiBEZWMgMTgsIDIwMTIsIGF0IDExOjUwIFBNLCBY dXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+ IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFp bHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0N Cj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI1SAxMTo1OA0KPj4gytW8/sjLOiBSb2dlcnMsIEpv c2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi11 ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYu b3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+PiDW 98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRy YWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+ DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIiA8am9z aC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCj4+ IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUg dGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0KPj4+IGFkZHJlc3NlcyBpbiBwcmFjdGljZSBhbnkg bG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0IGFub3RoZXIgTVBM Uy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBUaGUgSUVURg0KPj4gYWxyZWFkeSBzdGFuZGFyZGl6 ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRGIGhhcyBhbHNvIHN0YW5kYXJkaXplZCBNUExTDQo+ PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNoIGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBh dCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdh cmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBvZiBMM1ZQTiBvdmVyIGFuDQo+PiBJUC1vbmx5IG5l dHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0KPiBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhl cmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXIgSVAgaW4gYXQgbGVhc3Qgb25l LCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdvcmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkgdmFs dWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBoYWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGlj YXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRvZGF5J3MgU1AgbmV0d29ya3MuDQo+DQo+PiBTZWU6 IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQzNDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4+IFtO T1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAy MDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZDIDQ2NjUgZm9yIHJlcXVpcmVtZW50cyByZWxhdGVk IHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExTIG1heSBiZQ0KPj4gY2FycmllZCBvdmVyIEwyVFB2 Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRlbmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUg dmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4gSVBWUE4ncyBvdmVyIEwyVFB2MzoNCj4+IGh0dHA6 Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3MvaW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2 cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4gZm9yIHNoYXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0 aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBkcmFmdCBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVj aGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbiB0aGUgU2Vzc2lvbiBJRCBm aWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBvciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVh ZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQwXSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRlZCBieSBl eGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFyLg0KRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBp biB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4gcmVxdWVzdGluZyBhIGNvcmUgcm91dGVy IHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMgdG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNo IGNhbGN1bGF0aW9ucyBpbiBfZXhpc3RpbmdfIGhhcmR3YXJlLCBhbHJlYWR5IGRlcGxveWVkIChl eHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBuZXR3b3JrLiAgRnVydGhlciwgSSBzdXNwZWN0IHRo YXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgc2F2dnkgZm9sa3MgYW5kIHVuZGVy c3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVjdHVyZSBvZiB0aGVpciBIVyBmYWlybHkgd2VsbC4g IEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5v dCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0aGlzIHJlZ2FyZC4gIFRodXMsIGl0IG1heSBiZSBh IHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNlc3NhcnkgdG8gY29udmluY2UgdGhlaXIgSFcgc3Vw cGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0 byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdvYWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBu b3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNlZSBiZWxvdy4NCg0KDQo+IEluIGNvbnRyYXN0LCBt b3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUgYWxyZWFkeSBjYXBhYmxlIG9mIGJhbGFuY2lu ZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9m IFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUgTVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiwgdGhl IGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFsYW5jaW5nIGNhcGFiaWxpdHkgb2YgbW9zdCBleGlz dGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkg Y2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFm dC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0aGVuIHdoeSBub3QgZW5jYXBzdWxhdGUgdGhlIHRy YWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNoIHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3QgcGxh Y2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bvc2FsIG1heSBiZSB0byBjb25zaWRlciBhIFttaW5v cl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwgd2hpY2ggd291bGQgYWxsb3cgdGhlIGNvbm5lY3Rp b24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbCBwYWNrZXRzKSB0byB1c2UgYSB2 YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMgKG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwgYmFz ZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJldHRlciBsb2FkLWJhbGFuY2lu ZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBpbiBhbiBJUC1vbmx5IGNvcmUuICBMMlRQIGVuZC1z eXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGJldHRlciBvZmYganVzdCB1c2luZyB0aGUg IlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0 byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwyVFAgQ29u dHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJlYWR5LyBkbyB0aGlzLCBtYWtpbmcgYW55ICJjaGVj ayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBwb3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1z eXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2Fj aCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBj aGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRoZSAiY29udHJvbCBjaGFubmVsIiAoc29mdHdhcmUp IG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3RlbSBpbXBsZW1lbnRhdGlvbnMuICBIZWNrLCBpdCBt YXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2MyBpbXBs ZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxlbWVudG9ycyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQg b24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBn ZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBhbmQgIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0 aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQg c2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0aW9uIDguMiBvZiBSRkMgMzkzMToNCi0tLXNuaXAt LS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFmZmljIHNlcGFyYXRpb24gZm9yIGl0cyBWUE5zIHZp YSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hl biBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tpZQ0KICAgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu MSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8gZW5zdXJlDQogICB0aGF0IGFuIGFy cml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4NCiAg IFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4 dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUgU2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZvcm1l ZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAgIFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3QgY29y cnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlwLS0tDQouLi4gaW4gcmVnYXJkIHRvIHRoaXMgcXVl c3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYSBmb2xrcyBoYXZlLCBpbiB0aGUg cGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29uY2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBN UExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0 IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHkiLCBvZiBSRkMgNDY2NS4gIChUaGVyZSdzIGxpa2Vs eSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVyIGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZvciB0cmFu c3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJlIHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkg bXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJhZmZpYyBvbiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxp c3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRoaXMgY29uY2VybiB3aWxsIGFyaXNlIGlmL3doZW4g dGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KMykgRmluYWxseSwgdGhpcyBhcHByb2Fj aCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQgaW1wbGVtZW50IEwyVFAsIGZvciB0 dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRvZXMgbm90IHJlcXVpcmUgYW4gZW50aXJlIGluZHVz dHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxp bmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+PiBJ ZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBmb3IgTVBMUyBvdmVyIElQLCB0aGVuIGNsZWFybHkg aXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3JlIHdpZGVseSBpbXBsZW1lbnRlZCBieSBlcXVpcG1l bnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBMUyBvdmVyIEdSRSBvcg0KPj4gTVBMUyBvdmVyIEwy VFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2lsbCwgdGhlcmUncyBhIHdheSkuICBJIHdvdWxkIG5v dGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBhbiBvdXQg d2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFjdGljYWwNCj4+IG9wZXJhdGlvbmFsIGJlbmVmaXRz IG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBuYXRpdmUgTVBMUw0KPj4gZW5jYXBzdWxhdGlvbi9z d2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6DQo+PiAtIE1QTFMgRmFzdCBS ZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcNCj4+IC4uLiB0byBuYW1lLCBi dXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRlZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nIGFyZ3Vt ZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdvcmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3Vs YXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1zaGFuZQ0KPj4NCj4+DQo+Pj4gLUpvc2gNCj4+Pg0K Pj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEgQU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBi cm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBicm9hZGNvbS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+ PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21haW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdhY3kgYW5k IHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8gaW1wcm92ZSBpdC4NCj4+Pj4NCj4+Pj4gUmVnYXJk cywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6 MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1 YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IFNoYWhyYW0sDQo+Pj4+Pg0KPj4+Pj4gVGhp cyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRvIHByb3ZpZGUgYSBNUExTLW92ZXItSVAgZW5jYXBz dWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGggYSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGlj YWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJl cXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb24gdHJhZmZpYw0KPj4+Pj4gYWNyb3Nz IElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBMUy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5k IFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNl cy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2ZQ0KPj4+Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0 cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljIGFjcm9zcyBJUA0KPj4+Pj4gbmV0 d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBv dmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlz dG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNvLg0KPj4+Pj4NCj4+Pj4+IEJ5IHRoZSB3YXksIGl0 IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzDQo+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJl YWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgYXJndW1lbnQNCj4+Pj4+ IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRh dGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0 aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5nbHkgc2lsZW50DQo+Pj4+PiB0aWxsIG5vdy4NCj4+ Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBpbnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndp c2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+Pj4+Pg0KPj4+Pj4+IC0tLS0t08q8/tStvP4tLS0t LQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBTLg0KPj4+Pj4+IERhdmFyaQ0KPj4+Pj4+ILeiy83K sbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0KPj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0K Pj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0 bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4+Pj4+PiDW98ziOiBSZTogW21wbHNdIHBv bGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlDQo+Pj4+Pj4gZHJhZnQteHUtbXBs cy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+Pj4+Pg0K Pj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlzIGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNh dGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9kZXJuIG1ldHJvDQo+Pj4+Pj4gYW5kIGNvcmUsIHdo ZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwgYXBwbGljYXRpb24N Cj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4gY2VudGVyLCB3aGljaCBhbHJlYWR5IGlzIGNyb3dk ZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhcyBOVkdSRSBhbmQNCj4+Pj4+PiBWWExBTi4N Cj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNz IHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlvbg0KPj4+Pj4+IHByb2Nlc3MNCj4+Pj4+PiBieSBh ZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMgV0cuDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0K Pj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gRGVjIDE0LCAyMDEyLCBh dCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdy b3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRo aXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsiIHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+Pj4gZHJh ZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0K Pj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkgc2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRl bmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNv bW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nDQo+Pj4+Pj4+ IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+KS4g UGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3Vw cG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPj4+Pj4+PiB0 aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1 bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRoaXMgZG9j dW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAu DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUgYWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBv biB0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBu b3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5DQo+Pj4+ Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAt MDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbCkN Cj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9y cy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRpc2NvbnRpbnVlZCBhbGwgaW50ZXJhY3Rpb25zIHdp dGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUgYXV0aG9yIHRlYW0NCj4+Pj4+Pj4gb2YgZHJhZnQt eHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8N Cj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBieSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJl c3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbC4NCj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8g c3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGcm9tIHZlcnNpb24gLTA0IHRoZSBh dXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1hcnNoYWxsIGFzIGENCj4+Pj4+Pj4gY28tYXV0aG9y Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPj4+ Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAg ICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29t PG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNzc29uLmNvbT4NCj4+Pj4+Pj4gU3IgU3RyYXRlZ3kg YW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6 ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2JTIwMTAlMjA3MTclMjA1MiUyMDEzPg0KPj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIg MTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5MiUyMDEzPg0KPj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBtcGxzIG1haWxpbmcg bGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG1wbHMg bWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4N Cj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBt cGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9y Zz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBt cGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pg0K Pj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBp cyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8NCj4+IGNvcHlyaWdodCBi ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNv bGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlDQo+PiBpbnRlbmRlZCByZWNpcGll bnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3Nl bWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiBy ZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kDQo+PiBhdHRhY2htZW50cyB0byB0aGlzIEUt bWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdQ0K Pj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4gcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG1wbHMgbWFp bGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+DQo+DQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758CA81szxeml525mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

By the way= , according to the following statement quoted from L2TPv3 specification [RF= C3931], it seems that the UDP ports in the MPLS over L2TP over UDP case are not sufficient for fine-grained load-balancing.

4.1.2.2.&n= bsp; UDP Port Selection

 

 

   The method for UDP Port Selection = defined in this section is

   identical to that defined for L2TP= v2 [RFC2661].

 

   When negotiating a control connect= ion over UDP, control messages MUST

   be sent as UDP datagrams using the= registered UDP port 1701

   [RFC1700].  Th= e initiator of an L2TP control connection picks an

   available source UDP port (which m= ay or may not be 1701) and sends to

   the desired destination address at= port 1701.  The recipient picks a

   free port on its own system (which= may or may not be 1701) and sends

   its reply to the initiator's UDP p= ort and address, setting its own

   source port to the free port it fo= und.

 

 

 

Lau, et al.      =            Standards Trac= k            &n= bsp;       [Page 19]

= RFC 3931          &nb= sp;             = ; L2TPv3          &n= bsp;            Marc= h 2005

 

 

   Any subsequent traffic associated = with this control connection

   (either control traffic or data tr= affic from a session established

   through this control connection) m= ust use these same UDP ports.

 

 

Best regards,=

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: Xuxiaohu
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C224=C8=D5 = 10:53
=CA=D5=BC=FE=C8=CB: 'Andrew G. Malis'; Lucy yong
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; mpls@iet= f.org
=D6=F7=CC=E2: re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an= mpls working group document

 

Hi Andy,

 = ;

As discuss= ed before, =A1=B0performing hash calculation on= the "load-balancing" field contained in the tunnel encapsulation headers (i.e., the Session ID field in the L2TPv3 header or the Key field = in the GRE header) means a non-trivial change to the date plane of many exi= sting core routers and therefore not widely supported by most existing core= routers yet.=A1=B1

 = ;

By the way= , you may has missed a previous comment made by Carlos (see http://www.ietf= .org/mail-archive/web/mpls/current/msg09258.html), it said =A1=B0You mention RFC 3931 -- L2TPv3 defines L= 2TP directly over IP (IP Protocol number 115) as a MUST, and L2TP over UDP = as a SHOULD. Implementations might not support L2TPv3 over UDP.=A1= =B1

 

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8= =CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED Andrew G. Malis
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C222=C8=D5 = 3:53
=CA=D5=BC=FE=C8=CB: Lucy yong
=B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls-chairs@tools.ietf.org; mpls@iet= f.org
=D6=F7=CC=E2: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an= mpls working group document

 

= Lucy,

= Sure, but it could be satisfied by MPLS over L2TP over UDP, or hashing on t= he GRE key for MPLS over GRE.

Cheers,

Andy

=  

On Fri, Dec 21, 2012 at 2:27 PM= , Lucy yong <l= ucy.yong@huawei.com> wrote:

Andy,

 

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 

  3.3.2.1. LAG and ECMP 

 

       For performance reasons, mult= ipath over LAG and ECMP paths SHOULD be

       supported.

 

       LAG (Link Aggregation Group) = [IEEE 802.1AX-2008] and ECMP (Equal

       Cost Multi Path) are com= monly used techniques to perform load-

       balancing of microflows over = a set of a parallel links either at

       Layer-2 (LAG) or Layer-3= (ECMP). Existing deployed hardware

       implementations of LAG a= nd ECMP uses a hash of various fields in the

        encapsulation (out= ermost) header(s) (e.g. source and destination MAC

       addresses for non-IP tra= ffic, source and destination IP addresses,

       L4 protocol, L4 source a= nd destination port numbers, etc).

       Furthermore, hardware de= ployed for the underlay network(s) will be

       most often unaware of th= e carried, innermost L2 frames or L3 packets

       transmitted by the TS. T= hus, in order to perform fine-grained load-

       balancing over LAG and ECMP p= aths in the underlying network, the

       encapsulation MUST resul= t in sufficient entropy to exercise all

       paths through several LA= G/ECMP hops. The entropy information MAY be

       inferred from the NVO3 o= verlay header or underlay header.

 

Our draft provides an advanced solution in this space.

 

Lucy

 

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document=

 

I've commented earlier on this draft, and lik= e Shane, I remain unconvinced of its utility. I still don't think it has an= y utility at all for core backbone networks - just use native MPLS, or if you must tunnel MPLS over IP, the GRE or L2T= Pv3 encapsulations. Regarding data center applications, I guess I could be = convinced, but I would like to see a clear justification in the form of req= uirements from nvo3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante= <shane@castl= epoint.net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlep= oint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012= =C4=EA12=D4=C219=C8= =D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.c= om>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively r= ecent past, in requesting a core router vendor to support changes to the in= put-keys used in hash calculations in _existing_ hardware, already deployed (extensively) throughout my network.=  Further, I suspect that most large network operators are savvy folks= and understand the internal architecture of their HW fairly well.  As= a result, those same operators know what is and is not technically possible in this regard.  Thus, it may be a= question of "methods" necessary to convince their HW supplier(s)= to make appropriate changes in their equipment to achieve their business g= oals.  :-)  However, this may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulat= e the traffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com&g= t; wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
>>>>>> mpls-chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpl= s@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758CA81szxeml525mbschi_-- From prvs=698fdfcdd=B.Nagaraj@ril.com Mon Dec 24 02:33:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B8E21F8860 for ; Mon, 24 Dec 2012 02:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHdSSE76uELr for ; Mon, 24 Dec 2012 02:33:21 -0800 (PST) Received: from gwsmtp020.ril.com (gwsmtp020.ril.com [203.199.41.250]) by ietfa.amsl.com (Postfix) with ESMTP id C494C21F884F for ; Mon, 24 Dec 2012 02:33:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,346,1355077800"; d="scan'208";a="587753484" Received: from unknown (HELO outpostfix01.ril.com) ([10.66.8.167]) by gwsmtp020.ril.com with ESMTP; 24 Dec 2012 16:03:19 +0530 Received: from SIDCEXHUB03.in.ril.com (sidcexhub03.in.ril.com [10.66.15.13]) by outpostfix01.ril.com (Postfix) with SMTP id 9BE4712FBC2 for ; Mon, 24 Dec 2012 15:32:37 +0530 (IST) Received: from SIDCMBX01.in.ril.com ([10.66.15.21]) by SIDCEXHUB03.in.ril.com ([10.66.15.13]) with mapi; Mon, 24 Dec 2012 16:03:19 +0530 From: To: Date: Mon, 24 Dec 2012 16:03:18 +0530 Thread-Topic: Welcome to the "mpls" mailing list Thread-Index: Ac3hwd8dnZthuriyT86FPBGNOo7RAAAADSZg Message-ID: <535880CE4DA34C46ACCE610DC45B9D4602CD72D8D9@SIDCMBX01.in.ril.com> References: In-Reply-To: Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-IN Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [mpls] FW: Welcome to the "mpls" mailing list X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 10:35:19 -0000 With regards, = B.Nagaraj Cabin 3, 2A, 2nd floor, = RCP complex, = Thane Belapur Road Ghonsoli, Navi Mumbai-400701 Phone: = Work: +912244773047 Mobile: +919867564147 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of mpl= s-request@ietf.org Sent: Monday, December 24, 2012 4:02 PM To: B Nagaraj Subject: Welcome to the "mpls" mailing list Welcome to the mpls@ietf.org mailing list! To post to this list, send your email to: mpls@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/mpls If you ever want to unsubscribe or change your options (eg, switch to or fr= om digest mode, change your password, etc.), visit your subscription page a= t: https://www.ietf.org/mailman/options/mpls/b.nagaraj%40ril.com You can also make such adjustments via email by sending a message to: mpls-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and= you will get back a message with instructions. You must know your password to change your options (including changing the = password, itself) or to unsubscribe. It is: radha1964 Normally, Mailman will remind you of your ietf.org mailing list passwords o= nce every month, although you can disable this if you prefer. This reminde= r will also include instructions on how to unsubscribe or change your accou= nt options. There is also a button on your options page that will email yo= ur current password to you. "Confidentiality Warning: This message and any attachments are intended onl= y for the use of the intended recipient(s). = are confidential and may be privileged. If you are not the intended recipie= nt. you are hereby notified that any = review. re-transmission. conversion to hard copy. copying. circulation or o= ther use of this message and any attachments is = strictly prohibited. If you are not the intended recipient. please notify t= he sender immediately by return email. = and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ens= ure no viruses are present in this email. = The company cannot accept responsibility for any loss or damage arising fro= m the use of this email or attachment." From stephane.litkowski@orange.com Wed Dec 26 05:24:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D41121F8756 for ; Wed, 26 Dec 2012 05:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNH0-wWeE9wS for ; Wed, 26 Dec 2012 05:24:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6321F86BE for ; Wed, 26 Dec 2012 05:24:22 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BF038264736; Wed, 26 Dec 2012 14:24:20 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A1822238061; Wed, 26 Dec 2012 14:24:20 +0100 (CET) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.101.44.53]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 26 Dec 2012 14:24:20 +0100 From: To: Loa Andersson , "mpls@ietf.org" Date: Wed, 26 Dec 2012 14:24:19 +0100 Thread-Topic: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Thread-Index: Ac3dwnSLLTYetga4Qn+ajKACjBTzJgFqdkQg Message-ID: <29847_1356528260_50DAFA84_29847_9297_1_EEE55384044474429A926C625D0FCC8106306E0157@PUEXCB2F.nanterre.francetelecom.fr> References: <50D17A08.8050109@pi.nu> In-Reply-To: <50D17A08.8050109@pi.nu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.26.120326 Cc: "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 13:24:23 -0000 Support =20 -----Message d'origine----- De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De la part de Loa= Andersson Envoy=E9 : mercredi 19 d=E9cembre 2012 09:26 =C0 : mpls@ietf.org Cc : mpls-chairs@tools.ietf.org; Objet : [mpls] Working Group Last Call on draft-ietf-mpls-ldp-dod Working Group, This is to start a working group last call on draft-ietf-mpls-ldp-dod-03. T= his working last call is extended due to the upcoming holidays. Please send your comments to the mpls working group mailing list (mpls@ietf= .org). Please send both technical comments, and if you are happy with the document= as is also indications of support. There are no IPR claims against this draft. All the co-authors has stated that they are not ware of any IPRs. This working group last call will end on January 15, 2013. /Loa for the wg co-chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ____________= ___________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, 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, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From lucy.yong@huawei.com Wed Dec 26 07:09:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D728121F8CCB for ; Wed, 26 Dec 2012 07:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-2.188, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgNZah7Vj3i2 for ; Wed, 26 Dec 2012 07:09:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4CF721F8CC8 for ; Wed, 26 Dec 2012 07:08:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMW10935; Wed, 26 Dec 2012 15:08:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Dec 2012 15:08:31 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Dec 2012 15:08:53 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 26 Dec 2012 07:08:41 -0800 From: Lucy yong To: Pat Thaler , Lucy yong , "Andrew G. Malis" Thread-Topic: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Thread-Index: AQHN3baG6lNZW4xfyUOAvM96G0N/cZggt7EAgANl+4D//4fyUIAAnmiAgAYDNmA= Date: Wed, 26 Dec 2012 15:08:40 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44865162@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D44864DED@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.225] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D44865162dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 15:09:03 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D44865162dfweml505mbx_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGF0LA0KDQpJdCBpcyBmYWlyIHRvIHBvaW50IG91dCB0aGlzLCBhbmQgaXQgaXMgbXkgYmFk IHRvIGJyaW5nIE5WTzMgdXAgaW4gdGhpcyB0aHJlYWQuIEdpdmVuIGN1cnJlbnQgTlZPMyBjaGFy dGVyZWQgdGFzaywgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhpcyB0byBudm8zIGlzIGZvciBmdXJ0 aGVyIHN0dWR5Lg0KDQpIb3dldmVyLCBib3RoIEwyVlBOIGFuZCBMM1ZQTiBXRyBhcmUgd29ya2lu ZyBvbiB0aGUgSVAgVlBOIGFuZCBFVlBOIGV4dGVuc2lvbnMgaW50byBEQyBmb3IgbXVsdGktdGVu YW5jeSBhbmQgc2V2ZXJhbCBtYWpvciBvcGVyYXRvcnMgYW5kIHZlbmRvcnMgYXJlIGludGVyZXN0 ZWQgaW4gYW5kIHdvcmtpbmcgb24gaXQgbm93LiBBcyBwYXJ0IG9mIHRoZSBleHRlbnNpb24gd29y aywgYm90aCBJUCBWUE4gYW5kIEVWUE4gZXh0ZW5zaW9uIHByb3Bvc2FscyBzdGF0ZSB0aGUgbmVl ZCB0byBsZXQgQkdQL01QTFMgYmFzZWQgVlBOIG92ZXIgYW4gY29tbW9uIElQIHVuZGVybHlpbmcg aW5mcmFzdHJ1Y3R1cmUgaW5zdGVhZCBvZiB1c2luZyBNUExTIHNlcnZlciBsYXllciwgaS5lLiBM U1AgdHVubmVsLCBzaW5jZSB0aGUgTVBMUyBiYXNlZCBjb3JlIHN3aXRjaCBpcyBiYXJlbHkgdXNl ZCBpbiBEQ3MuIEJhc2VkIG9uIGN1cnJlbnQgYXZhaWxhYmxlIHN0YW5kYXJkLCB0aGVzZSBwcm9w b3NhbHMgcmVjb21tZW5kIHRvIHVzZSBHUkUgZW5jYXBzdWxhdGlvbi4gQnV0IHRvZGF5IERDIHN3 aXRjaGVzL3JvdXRlcnMgZG8gbm90IHN1cHBvcnQgR1JFIGJhc2VkIGxvYWQgYmFsYW5jaW5nLiBE QyB0cmFmZmljIGlzIG1haW5seSBnZW5lcmF0ZWQgYnkgdGhlIGhvc3RzIHRoYXQgc3VwcG9ydHMg VENQL1VEUC4gVGh1cyAgREMgc3dpdGNoZXMgY29tbW9ubHkgc3VwcG9ydCBVRFAgYmFzZWQgbG9h ZCBiYWxhbmNpbmcuIFRoZXJlZm9yZSwgdGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBhZHZhbmNlZCBl bmNhcHN1bGF0aW9uLCB3aGljaCBjYW4gYXBwbHkgdG8gdGhlIElQIFZQTiBhbmQgRVZQTiBleHRl bnNpb24gaW4gZGF0YSBjZW50ZXJzIGFuZCBtaW5pbWl6ZSB0aGUgY2hhbmdlcyBpbiBEQyBpbmZy YXN0cnVjdHVyZS4NCg0KUmVnYXJkcywNCkx1Y3kNCg0KRnJvbTogUGF0IFRoYWxlciBbbWFpbHRv OnB0aGFsZXJAYnJvYWRjb20uY29tXQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAy OjQ5IFBNDQpUbzogTHVjeSB5b25nOyBBbmRyZXcgRy4gTWFsaXM7IFNoYW5lIEFtYW50ZQ0KQ2M6 IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBwb2xsIHRvIHNlZSBp ZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS1tcGxzLWluLXVkcCBhbiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQNCg0KTHVjeSwNCg0KSWYgeW91ciBkcmFmdCBpcyBpbnRlbmRl ZCB0byBhZGRyZXNzIHRoZSBOVk8zIHJlcXVpcmVtZW50cywgdGhlbiBpdCBzaG91bGQgYmUgY29u c2lkZXJlZCBpbiBOVk8zIGFsb25nIHdpdGggdGhlIG90aGVyIHByb3Bvc2VkIHNvbHV0aW9ucyBy YXRoZXIgdGhhbiBieXBhc3NpbmcgdGhhdCBwcm9jZXNzIGJ5IHN1Ym1pdHRpbmcgaXQgdG8gTVBM Uy4NCg0KVGhlIE5WTyBjaGFydGVyIHJlcXVpcmVzIHRoYXQgdGhlIHByZWxpbWluYXJ5IGFuYWx5 c2lzIHdvcmsgYmUgY29tcGxldGVkIGJlZm9yZSBjb21wbGV0aW5nIHNvbHV0aW9uczoNClRoZSBO Vk8zIFdHIHdpbGwgd3JpdGUgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbmFsIFJGQ3MsIHdoaWNo DQptdXN0IGhhdmUgY29tcGxldGVkIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGJlZm9yZSByZWNo YXJ0ZXJpbmcgY2FuIGJlDQpjb25zaWRlcmVkOg0KDQpQcm9ibGVtIFN0YXRlbWVudA0KRnJhbWV3 b3JrIGRvY3VtZW50DQpDb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBkb2N1bWVudA0KRGF0YSBw bGFuZSByZXF1aXJlbWVudHMgZG9jdW1lbnQNCk9wZXJhdGlvbmFsIFJlcXVpcmVtZW50cw0KR2Fw IEFuYWx5c2lzDQoNCkRyaXZlbiBieSB0aGUgcmVxdWlyZW1lbnRzIGFuZCBjb25zaXN0ZW50IHdp dGggdGhlIGdhcCBhbmFseXNpcywNCnRoZSBOVk8zIFdHIG1heSByZXF1ZXN0IGJlaW5nIHJlY2hh cnRlcmVkIHRvIGRvY3VtZW50IHNvbHV0aW9ucw0KY29uc2lzdGluZyBvZiBvbmUgb3IgbW9yZSBk YXRhIHBsYW5lIGVuY2Fwc3VsYXRpb25zIGFuZA0KY29udHJvbCBwbGFuZSBwcm90b2NvbHMgYXMg YXBwbGljYWJsZS4NCg0KQmFzZWQgb24gdGhlIE5WTzMgY2hhcnRlciwgaXQgaXMgcHJlbWF0dXJl IHRvIGNvbnNpZGVyIHNvbHV0aW9ucyBhdCB0aGlzIHBvaW50IGFuZCBzdWdnZXN0aW5nIHRoYXQg c29tZXRoaW5nIHNob3VsZCBnbyBmb3J3YXJkIGJlY2F1c2UgaXQgc3VwcG9ydHMgb25lIGl0ZW0g aW4gYSBkcmFmdCBOVk8zIHJlcXVpcmVtZW50cyBkb2N1bWVudCBpcyBub3QganVzdGlmaWVkLg0K DQpSZWdhcmRzLA0KUGF0DQoNCkZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kgeW9uZw0KU2VudDogRnJpZGF5 LCBEZWNlbWJlciAyMSwgMjAxMiAxMToyNyBBTQ0KVG86IEFuZHJldyBHLiBNYWxpczsgU2hhbmUg QW1hbnRlDQpDYzogZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIHBv bGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRw IGFuIG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KDQpBbmR5LA0KDQpIZXJlIGlzIHRoZSB0 ZXh0IGZyb20gZHJhZnQtaWV0Zi1udm8zLWRhdGFwbGFuZS1yZXF1aXJlbWVudHMtMDAudHh0DQoN CiAgMy4zLjIuMS4gTEFHIGFuZCBFQ01QDQoNCiAgICAgICBGb3IgcGVyZm9ybWFuY2UgcmVhc29u cywgbXVsdGlwYXRoIG92ZXIgTEFHIGFuZCBFQ01QIHBhdGhzIFNIT1VMRCBiZQ0KICAgICAgIHN1 cHBvcnRlZC4NCg0KICAgICAgIExBRyAoTGluayBBZ2dyZWdhdGlvbiBHcm91cCkgW0lFRUUgODAy LjFBWC0yMDA4XSBhbmQgRUNNUCAoRXF1YWwNCiAgICAgICBDb3N0IE11bHRpIFBhdGgpIGFyZSBj b21tb25seSB1c2VkIHRlY2huaXF1ZXMgdG8gcGVyZm9ybSBsb2FkLQ0KICAgICAgIGJhbGFuY2lu ZyBvZiBtaWNyb2Zsb3dzIG92ZXIgYSBzZXQgb2YgYSBwYXJhbGxlbCBsaW5rcyBlaXRoZXIgYXQN CiAgICAgICBMYXllci0yIChMQUcpIG9yIExheWVyLTMgKEVDTVApLiBFeGlzdGluZyBkZXBsb3ll ZCBoYXJkd2FyZQ0KICAgICAgIGltcGxlbWVudGF0aW9ucyBvZiBMQUcgYW5kIEVDTVAgdXNlcyBh IGhhc2ggb2YgdmFyaW91cyBmaWVsZHMgaW4gdGhlDQogICAgICAgIGVuY2Fwc3VsYXRpb24gKG91 dGVybW9zdCkgaGVhZGVyKHMpIChlLmcuIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gTUFDDQogICAg ICAgYWRkcmVzc2VzIGZvciBub24tSVAgdHJhZmZpYywgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzZXMsDQogICAgICAgTDQgcHJvdG9jb2wsIEw0IHNvdXJjZSBhbmQgZGVzdGluYXRp b24gcG9ydCBudW1iZXJzLCBldGMpLg0KICAgICAgIEZ1cnRoZXJtb3JlLCBoYXJkd2FyZSBkZXBs b3llZCBmb3IgdGhlIHVuZGVybGF5IG5ldHdvcmsocykgd2lsbCBiZQ0KICAgICAgIG1vc3Qgb2Z0 ZW4gdW5hd2FyZSBvZiB0aGUgY2FycmllZCwgaW5uZXJtb3N0IEwyIGZyYW1lcyBvciBMMyBwYWNr ZXRzDQogICAgICAgdHJhbnNtaXR0ZWQgYnkgdGhlIFRTLiBUaHVzLCBpbiBvcmRlciB0byBwZXJm b3JtIGZpbmUtZ3JhaW5lZCBsb2FkLQ0KICAgICAgIGJhbGFuY2luZyBvdmVyIExBRyBhbmQgRUNN UCBwYXRocyBpbiB0aGUgdW5kZXJseWluZyBuZXR3b3JrLCB0aGUNCiAgICAgICBlbmNhcHN1bGF0 aW9uIE1VU1QgcmVzdWx0IGluIHN1ZmZpY2llbnQgZW50cm9weSB0byBleGVyY2lzZSBhbGwNCiAg ICAgICBwYXRocyB0aHJvdWdoIHNldmVyYWwgTEFHL0VDTVAgaG9wcy4gVGhlIGVudHJvcHkgaW5m b3JtYXRpb24gTUFZIGJlDQogICAgICAgaW5mZXJyZWQgZnJvbSB0aGUgTlZPMyBvdmVybGF5IGhl YWRlciBvciB1bmRlcmxheSBoZWFkZXIuDQoNCk91ciBkcmFmdCBwcm92aWRlcyBhbiBhZHZhbmNl ZCBzb2x1dGlvbiBpbiB0aGlzIHNwYWNlLg0KDQpMdWN5DQoNCkZyb206IG1wbHMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVo YWxmIE9mIEFuZHJldyBHLiBNYWxpcw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAx MjozMiBQTQ0KVG86IFNoYW5lIEFtYW50ZQ0KQ2M6IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRm Lm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMt aW4tdWRwIGFuIG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVudA0KDQpJJ3ZlIGNvbW1lbnRlZCBl YXJsaWVyIG9uIHRoaXMgZHJhZnQsIGFuZCBsaWtlIFNoYW5lLCBJIHJlbWFpbiB1bmNvbnZpbmNl ZCBvZiBpdHMgdXRpbGl0eS4gSSBzdGlsbCBkb24ndCB0aGluayBpdCBoYXMgYW55IHV0aWxpdHkg YXQgYWxsIGZvciBjb3JlIGJhY2tib25lIG5ldHdvcmtzIC0ganVzdCB1c2UgbmF0aXZlIE1QTFMs IG9yIGlmIHlvdSBtdXN0IHR1bm5lbCBNUExTIG92ZXIgSVAsIHRoZSBHUkUgb3IgTDJUUHYzIGVu Y2Fwc3VsYXRpb25zLiBSZWdhcmRpbmcgZGF0YSBjZW50ZXIgYXBwbGljYXRpb25zLCBJIGd1ZXNz IEkgY291bGQgYmUgY29udmluY2VkLCBidXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIGNsZWFyIGp1 c3RpZmljYXRpb24gaW4gdGhlIGZvcm0gb2YgcmVxdWlyZW1lbnRzIGZyb20gbnZvMyB0aGF0IGNv dWxkIG9ubHkgYmUgbWV0IGJ5IHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCkFuZHkNCg0KT24gV2Vk LCBEZWMgMTksIDIwMTIgYXQgOTozOCBBTSwgU2hhbmUgQW1hbnRlIDxzaGFuZUBjYXN0bGVwb2lu dC5uZXQ8bWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldD4+IHdyb3RlOg0KWGlhb2h1LA0KDQpP biBEZWMgMTgsIDIwMTIsIGF0IDExOjUwIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNv bTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KLS0tLS3Tyrz+1K28/i0tLS0t DQo+PiC3orz+yMs6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNhc3RsZXBvaW50Lm5ldDxt YWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTnI 1SAxMTo1OA0KPj4gytW8/sjLOiBSb2dlcnMsIEpvc2gNCj4+ILOty806IFNoYWhyYW0gRGF2YXJp OyBYdXhpYW9odTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsNCj4+IG1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2Vl IGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuDQo+PiBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+DQo+Pg0KPj4gT24gRGVjIDE4LCAyMDEyLCBh dCA4OjUwIEFNLCAiUm9nZXJzLCBKb3NoIiA8am9zaC5yb2dlcnNAdHdjYWJsZS5jb208bWFpbHRv Ompvc2gucm9nZXJzQHR3Y2FibGUuY29tPj4NCj4+IHdyb3RlOg0KPj4+IEkgc2hhcmUgeW91ciBT UCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gdGhpcyBzb2x1dGlvbg0K Pj4+IGFkZHJlc3NlcyBpbiBwcmFjdGljZSBhbnkgbG9uZ2VyLg0KPj4NCj4+ICsxLiAgUGxlYXNl IGRvIG5vdCBkZWZpbmUgeWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uICBU aGUgSUVURg0KPj4gYWxyZWFkeSBzdGFuZGFyZGl6ZWQgTVBMUyBvdmVyIEdSRS4gIFRoZSBJRVRG IGhhcyBhbHNvIHN0YW5kYXJkaXplZCBNUExTDQo+PiBvdmVyIEwyVFB2My9VRFAvSVAsIHdoaWNo IGhhZCBzZWVuIHNvbWUgZGVwbG95bWVudCBpbiBhdCBsZWFzdCBvbmUsIHZlcnkNCj4+IGxhcmdl IG9wZXJhdG9yIG5ldHdvcmsgdGhhdCBJJ20gYXdhcmUgb2YgdG8gc3VwcG9ydCBjYXJyaWFnZSBv ZiBMM1ZQTiBvdmVyIGFuDQo+PiBJUC1vbmx5IG5ldHdvcmsuDQo+DQo+IEhpIFNoYW5lLA0KPg0K PiBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBv ZiBNUExTIG92ZXIgSVAgaW4gYXQgbGVhc3Qgb25lLCB2ZXJ5IGxhcmdlIG9wZXJhdG9yIG5ldHdv cmsuIFRoaXMgZmFjdCBtdXN0IGJlIHZlcnkgdmFsdWFibGUgdG8gdGhvc2UgcGVvcGxlIHdobyBo YWQgYmVsaWV2ZWQgdGhlcmUgaXMgbm8gYXBwbGljYXRpb24gb2YgTVBMUyBvdmVyIElQIGluIHRv ZGF5J3MgU1AgbmV0d29ya3MuDQo+DQo+PiBTZWU6IFJGQydzIDQ0NTQsIDQ3MTksIDQ1OTEsIDQz NDkgZm9yIFBXRTMgb3ZlciBMMlRQdjMNCj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3ZlIHdl cmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2IHRpbWVmcmFtZSFdDQo+PiAgICAgUkZD IDQ2NjUgZm9yIHJlcXVpcmVtZW50cyByZWxhdGVkIHRvIFZQTFMgdGhhdCBzYXkgdGhhdCBWUExT IG1heSBiZQ0KPj4gY2FycmllZCBvdmVyIEwyVFB2Mw0KPj4gICAgIEFuZCwgaGVyZSdzIGV2aWRl bmNlIHNob3dpbmcgdGhhdCBhdCBsZWFzdCBvbmUgdmVuZG9yIGhhcyBpbXBsZW1lbnRlZA0KPj4g SVBWUE4ncyBvdmVyIEwyVFB2MzoNCj4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2VuL1VTL2RvY3Mv aW9zLzEyXzBzL2ZlYXR1cmUvZ3VpZGUvY3NnbDN2cG4uaHRtbA0KPg0KPiBUaGFua3MgYWdhaW4g Zm9yIHNoYXJpbmcgdGhlIGFib3ZlIGluZm9ybWF0aW9uLiBBcyBtZW50aW9uZWQgaW4gdGhpcyBk cmFmdCBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVjaGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBj YWxjdWxhdGlvbiBvbiB0aGUgU2Vzc2lvbiBJRCBmaWVsZCBpbiB0aGUgTDJUUHYzIGhlYWRlciBv ciB0aGUgS2V5IGZpZWxkIGluIHRoZSBHUkUgaGVhZGVyIGFzIGRlZmluZWQgaW4gW1JGQyA1NjQw XSBpcyBub3Qgd2lkZWx5IHN1cHBvcnRlZCBieSBleGlzdGluZyBjb3JlIHJvdXRlcnMgc28gZmFy Lg0KRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFz dCwgaW4gcmVxdWVzdGluZyBhIGNvcmUgcm91dGVyIHZlbmRvciB0byBzdXBwb3J0IGNoYW5nZXMg dG8gdGhlIGlucHV0LWtleXMgdXNlZCBpbiBoYXNoIGNhbGN1bGF0aW9ucyBpbiBfZXhpc3Rpbmdf IGhhcmR3YXJlLCBhbHJlYWR5IGRlcGxveWVkIChleHRlbnNpdmVseSkgdGhyb3VnaG91dCBteSBu ZXR3b3JrLiAgRnVydGhlciwgSSBzdXNwZWN0IHRoYXQgbW9zdCBsYXJnZSBuZXR3b3JrIG9wZXJh dG9ycyBhcmUgc2F2dnkgZm9sa3MgYW5kIHVuZGVyc3RhbmQgdGhlIGludGVybmFsIGFyY2hpdGVj dHVyZSBvZiB0aGVpciBIVyBmYWlybHkgd2VsbC4gIEFzIGEgcmVzdWx0LCB0aG9zZSBzYW1lIG9w ZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBpbiB0 aGlzIHJlZ2FyZC4gIFRodXMsIGl0IG1heSBiZSBhIHF1ZXN0aW9uIG9mICJtZXRob2RzIiBuZWNl c3NhcnkgdG8gY29udmluY2UgdGhlaXIgSFcgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0 ZSBjaGFuZ2VzIGluIHRoZWlyIGVxdWlwbWVudCB0byBhY2hpZXZlIHRoZWlyIGJ1c2luZXNzIGdv YWxzLiAgOi0pICBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3NhcnkgLi4uIHNl ZSBiZWxvdy4NCg0KDQo+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBh cmUgYWxyZWFkeSBjYXBhYmxlIG9mIGJhbGFuY2luZyBJUCB0cmFmZmljIGZsb3dzIGJhc2VkIG9u IHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVEUCBwYWNrZXRzLiBCeSB1c2luZyB0aGUg TVBMUy1pbi1VRFAgZW5jYXBzdWxhdGlvbiwgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGxvYWQtYmFs YW5jaW5nIGNhcGFiaWxpdHkgb2YgbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxl dmVyYWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkgY2hhbmdlIHRvIHRoZW0uIFRoYXQgaXMgdGhl IG1ham9yIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdC4NCklmIHRoaXMgaXMgYSBjb25jZXJuLCB0 aGVuIHdoeSBub3QgZW5jYXBzdWxhdGUgdGhlIHRyYWZmaWMgaW4gTVBMUy9MMlRQdjMsIHdoaWNo IHVzZXMgVURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQoNCklNSE8sIGEgYmV0dGVyIHByb3Bv c2FsIG1heSBiZSB0byBjb25zaWRlciBhIFttaW5vcl0gKD8pIGNoYW5nZSB0byBSRkMgMzkzMSwg d2hpY2ggd291bGQgYWxsb3cgdGhlIGNvbm5lY3Rpb24gdXNlZCBmb3IgZGF0YSBwYWNrZXRzIChu b3QgY29udHJvbCBwYWNrZXRzKSB0byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMg KG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwgYmFzZWQgb24gYSBoYXNoIGNhbGN1bGF0aW9uLCB0 byBhY2hpZXZlIGJldHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nIGVxdWlwbWVudCBp biBhbiBJUC1vbmx5IGNvcmUuICBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zIHdvdWxk IGJlIGJldHRlciBvZmYganVzdCB1c2luZyB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNvb2tpZSIp IGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0byBhc3NvY2lhdGUgaW5jb21pbmcgcGFja2V0 cyB3aXRoIHRoZSBhc3NvY2lhdGVkIEwyVFAgQ29udHJvbCBDaGFubmVsLiAgSW4gZmFjdCwgaXQn cyBub3QgY2xlYXIgdG8gbWUgdGhhdCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgbWF5IC9hbHJl YWR5LyBkbyB0aGlzLCBtYWtpbmcgYW55ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBw b3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW0gaW1wbGVtZW50YXRpb25zLg0KDQpU aGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBpczoNCjEpIEkgd291bGQgdGhpbmsgdGhh dCB0aGUgYWJvdmUgaXMgbW9zdCBsaWtlbHkgYSBjaGFuZ2UgdGhhdCBpcyBsaW1pdGVkIHRvIHRo ZSAiY29udHJvbCBjaGFubmVsIiAoc29mdHdhcmUpIG9mIGV4aXN0aW5nIEwyVFAgZW5kLXN5c3Rl bSBpbXBsZW1lbnRhdGlvbnMuICBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNrd2FyZHMgY29tcGF0 aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2MyBpbXBsZW1lbnRhdGlvbnMuICAoTDJUUHYzIGltcGxl bWVudG9ycyB3b3VsZCBuZWVkIHRvIGNvbW1lbnQgb24gdGhhdCkuDQoyKSBUaGVyZSBpcyBhIHN1 YnN0YW50aWFsIGFkZGVkIHNlY3VyaXR5IG9uZSBnZXRzIGJ5IHVzaW5nICJTZXNzaW9uIElEIiBh bmQgIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2ZWQgTDJUUHYzIHBhY2tldCBp cyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4gIFF1b3RpbmcgZnJvbSBTZWN0 aW9uIDguMiBvZiBSRkMgMzkzMToNCi0tLXNuaXAtLS0NCiAgIEwyVFB2MyBwcm92aWRlcyB0cmFm ZmljIHNlcGFyYXRpb24gZm9yIGl0cyBWUE5zIHZpYSBhIDMyLWJpdCBTZXNzaW9uDQogICBJRCBp biB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUgTDJUUHYzIENvb2tp ZQ0KICAgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwg Y2hlY2sgdG8gZW5zdXJlDQogICB0aGF0IGFuIGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBm b3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4NCiAgIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRo IHRoZSBTZXNzaW9uIElEIHByb3ZpZGVzIGFuIGV4dHJhIGd1YXJhbnRlZQ0KICAgdGhhdCB0aGUg U2Vzc2lvbiBJRCBsb29rdXAgd2FzIHBlcmZvcm1lZCBwcm9wZXJseSBhbmQgdGhhdCB0aGUNCiAg IFNlc3Npb24gSUQgaXRzZWxmIHdhcyBub3QgY29ycnVwdGVkIGluIHRyYW5zaXQuDQotLS1zbmlw LS0tDQouLi4gaW4gcmVnYXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUsIEkga25vdyB0aGUgU2Vj dXJpdHkgQXJlYSBmb2xrcyBoYXZlLCBpbiB0aGUgcGFzdCwgaGFkIC9zdWJzdGFudGlhbC8gY29u Y2VybnMgYWJvdXQgZW5jYXBzdWxhdGlvbiBvZiBNUExTIG92ZXIgSVAgdHJhbnNwb3J0LiAgSW4g ZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJpdHki LCBvZiBSRkMgNDY2NS4gIChUaGVyZSdzIGxpa2VseSBzaW1pbGFyIGxhbmd1YWdlIGluIG90aGVy IGRyYWZ0cyB0aGF0IHVzZSBNUExTIGZvciB0cmFuc3BvcnQpLiAgV2hpbGUgSSdtIG5vdCBzdXJl IHRoYXQgU2VjdXJpdHkgQXJlYSBmb2xrcyBwYXkgbXVjaCBhdHRlbnRpb24gdG8gZGFpbHkgdHJh ZmZpYyBvbiB0aGUgTVBMUyBXRyBtYWlsaW5nIGxpc3QsIEknbSBmYWlybHkgY29uZmlkZW50IHRo aXMgY29uY2VybiB3aWxsIGFyaXNlIGlmL3doZW4gdGhpcyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNH IC4uLg0KMykgRmluYWxseSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0 ZW1zIHRoYXQgaW1wbGVtZW50IEwyVFAsIGZvciB0dW5uZWxpbmcgb2YgTVBMUy9JUCwgYW5kIGRv ZXMgbm90IHJlcXVpcmUgYW4gZW50aXJlIGluZHVzdHJ5IHRvIHN1cHBvcnQgTVBMUy9VRFAgZW5j YXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLg0KDQotc2hhbmUNCg0KDQo+DQo+IEJl c3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+PiBJZiB0aGVyZSB3YXMgbWFya2V0IGRlbWFuZCBm b3IgTVBMUyBvdmVyIElQLCB0aGVuIGNsZWFybHkgaXQgd291bGQgaGF2ZSBiZWVuDQo+PiBtb3Jl IHdpZGVseSBpbXBsZW1lbnRlZCBieSBlcXVpcG1lbnQgdmVuZG9ycywgd2l0aCBlaXRoZXIgTVBM UyBvdmVyIEdSRSBvcg0KPj4gTVBMUyBvdmVyIEwyVFB2My4gIChXaGVyZSB0aGVyZSdzIGEgd2ls bCwgdGhlcmUncyBhIHdheSkuICBJIHdvdWxkIG5vdGUgdGhhdA0KPj4gdGhlIG1vc3QgbGlrZWx5 IHJlYXNvbnMgdGhpcyBkaWQgbm90IHBhbiBvdXQgd2FzIHRoZXJlIGFyZSBzZXZlcmFsLCBwcmFj dGljYWwNCj4+IG9wZXJhdGlvbmFsIGJlbmVmaXRzIG9uZSBnZXRzIGZyb20gZ29pbmcgd2l0aCBu YXRpdmUgTVBMUw0KPj4gZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBs YW5lLCBuYW1lbHk6DQo+PiAtIE1QTFMgRmFzdCBSZS1Sb3V0ZQ0KPj4gLSBNUExTIFRyYWZmaWMg RW5naW5lZXJpbmcNCj4+IC4uLiB0byBuYW1lLCBidXQgYSBmZXcuICBUaG9zZSBoYXZlIHRlbmRl ZCB0byBiZSBxdWl0ZSBjb21wZWxsaW5nIGFyZ3VtZW50cw0KPj4gdG8gJ3VwZ3JhZGUnIG5ldHdv cmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPj4NCj4+IC1z aGFuZQ0KPj4NCj4+DQo+Pj4gLUpvc2gNCj4+Pg0KPj4+DQo+Pj4gT24gMTIvMTgvMTIgMTI6MzEg QU0sICJTaGFocmFtIERhdmFyaSIgPGRhdmFyaUBicm9hZGNvbS5jb208bWFpbHRvOmRhdmFyaUBi cm9hZGNvbS5jb20+PiB3cm90ZToNCj4+Pg0KPj4+PiBGb3Igc2VydmljZSBwcm92aWRlciBkb21h aW4sIE1QTFMgb3ZlciBJUCBpcyBsZWdhY3kgYW5kIHRoZXJlIGlzIG5vIG5lZWQNCj4+Pj4gdG8g aW1wcm92ZSBpdC4NCj4+Pj4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gU2hhaHJhbQ0KPj4+Pg0KPj4+ Pg0KPj4+PiBPbiBEZWMgMTcsIDIwMTIsIGF0IDg6MDIgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1 QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiB3cm90ZToNCj4+Pj4NCj4+ Pj4+IFNoYWhyYW0sDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBkcmFmdCBpcyBPTkxZIGludGVuZGVkIHRv IHByb3ZpZGUgYSBNUExTLW92ZXItSVAgZW5jYXBzdWxhdGlvbg0KPj4+Pj4gbWV0aG9kIHdpdGgg YSBiZXR0ZXIgbG9hZC1iYWxhbmNpbmcgYXBwbGljYWJpbGl0eSBzbyBmYXIgdG8gdGhvc2UNCj4+ Pj4+IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVpcmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBw bGljYXRpb24gdHJhZmZpYw0KPj4+Pj4gYWNyb3NzIElQIG5ldHdvcmtzLiBJIGJlbGlldmUgTVBM Uy1iYXNlZCBWUE4gb3ZlciBJUCwgTlZHUkUgYW5kIFZYTEFODQo+Pj4+PiBlYWNoIGhhdmUgdGhl aXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91IGFic29sdXRlbHkgYmVsaWV2 ZQ0KPj4+Pj4gaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlv biB0cmFmZmljIGFjcm9zcyBJUA0KPj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBl eGlzdGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUyBvdmVyIElQDQo+Pj4+PiB0dW5uZWxpbmcgbWVj aGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3RhdHVzLCBwbGVhc2Ugc2F5IHNv Lg0KPj4+Pj4NCj4+Pj4+IEJ5IHRoZSB3YXksIGl0IHNlZW1zIHRoaXMNCj4+Pj4+IChodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwp IGlzDQo+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3VpdGFibGUgZm9yIHlvdSB0byBtYWtl IHRoZSBmb2xsb3dpbmcgYXJndW1lbnQNCj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExT LWJhc2VkIFZQTiBpcyBhcHBsaWNhYmxlIHRvIGRhdGEgY2VudGVycykuIEkNCj4+Pj4+IGhhZCB0 aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LCBzdXJwcmlzaW5n bHkgc2lsZW50DQo+Pj4+PiB0aWxsIG5vdy4NCj4+Pj4+DQo+Pj4+PiBTaWdoLCBJIGRpZG4ndCBp bnRlbmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuDQo+Pj4+Pg0KPj4+Pj4gWGlhb2h1DQo+ Pj4+Pg0KPj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+Pj4+ILeivP7IyzogbXBscy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtDQo+PiBT Lg0KPj4+Pj4+IERhdmFyaQ0KPj4+Pj4+ILeiy83KsbzkOiAyMDEyxOoxMtTCMTXI1SAxMzozNA0K Pj4+Pj4+IMrVvP7IyzogTG9hIEFuZGVyc3Nvbg0KPj4+Pj4+ILOty806IGRyYWZ0LXh1LW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5p ZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+Ow0KPj4+Pj4+IG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zz4NCj4+Pj4+PiDW98ziOiBSZTogW21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9y dCB0byBtYWtlDQo+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAgYW4NCj4+Pj4+PiBtcGxzIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4+Pj4+Pg0KPj4+Pj4+IEkgZG9uJ3Qgc3VwcG9ydCB0aGlz IGRyYWZ0IHNpbmNlIGl0IGhhcyBubyBhcHBsaWNhdGlvbiBpbiB0b2RheSdzDQo+Pj4+Pj4gbW9k ZXJuIG1ldHJvDQo+Pj4+Pj4gYW5kIGNvcmUsIHdoZXJlIE1QTFMgaXMgZG9taW5hbnQsIGFuZCBp dHMgb25seSBwcmFjdGljYWwgYXBwbGljYXRpb24NCj4+Pj4+PiBpbiBpbiBkYXRhDQo+Pj4+Pj4g Y2VudGVyLCB3aGljaCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3Vj aCBhcyBOVkdSRSBhbmQNCj4+Pj4+PiBWWExBTi4NCj4+Pj4+Pg0KPj4+Pj4+IEl0IHNlZW1zIHRo ZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNzIHRoZSBOVk8zIHNvbHV0aW9uIHNlbGVjdGlv bg0KPj4+Pj4+IHByb2Nlc3MNCj4+Pj4+PiBieSBhZHZhbmNpbmcgdGhlIGRyYWZ0IGluIE1QTFMg V0cuDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+IFNoYWhyYW0NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gT24gRGVjIDE0LCAyMDEyLCBhdCAxOjAxIEFNLCBMb2EgQW5kZXJzc29uIDxs b2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFdvcmtp bmcgZ3JvdXAsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoaXMgaXMgdG8gc3RhcnQgYSAidHdvIHdlZWsi IHBvbGwgb24gYWRvcHRpbmcNCj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4g TVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPj4+Pj4+PiBEdWUgdG8gdGhlIGhvbGlkYXkg c2Vhc29uIHRoaXMgcG9sbCBoYXMgYmVlbiBleHRlbmRlZCB3aXRoIG9uZSB3ZWVrLg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0 KSB0byB0aGUgbXBscyB3b3JraW5nDQo+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBh dCBpZXRmLm9yZzxodHRwOi8vaWV0Zi5vcmc+KS4gUGxlYXNlIGdpdmUgYW4gdGVjaG5pY2FsDQo+ Pj4+Pj4+IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxs eSBpZiB5b3UgdGhpbmsgdGhhdA0KPj4+Pj4+PiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBh ZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhp cyBwb2xsIGVuZHMgSmFudWFyeSAwNywgMjAxMy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhlcmUgaXMg b25lIElQUiBjbGFpbSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQgLQ0KPj4+Pj4+PiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyAuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFsbCB0aGUg YWN0aXZlIGNvLWF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4gdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBj bGFpbXMgdGhhbiB0aG9zZSBhbHJlYWR5DQo+Pj4+Pj4+IGRpc2Nsb3NlZC4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVz ZWQgZm9yIHRoZSBJUFINCj4+Pj4+Pj4gcG9sbCkNCj4+Pj4+Pj4gTWFyc2hhbGwgRXViYW5rcyB3 YXMgbGlzdGVkIGFzIG9uZSBvZiB0aGUgYXV0aG9ycy4gTWFyc2hhbGwgaGFzDQo+Pj4+Pj4+IGRp c2NvbnRpbnVlZCBhbGwgaW50ZXJhY3Rpb25zIHdpdGggdGhlIElFVEYsIGluY2x1ZGluZyB0aGUg YXV0aG9yIHRlYW0NCj4+Pj4+Pj4gb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3Jr aW5nIGdyb3VwIGNoYWlycyBoYXMgdHJpZWQgdG8NCj4+Pj4+Pj4gY29udGFjdCBNYXJzaGFsbCBi eSBvdGhlciBtZWFucywgdG8gdHJ5IGdldCBhIHJlc3BvbnNlIG9uIHRoZSBJUFINCj4+Pj4+Pj4g cG9sbC4NCj4+Pj4+Pj4gV2UgaGF2ZSBoYWQgbm8gc3VjY2VzcyBpbiB0aGlzLg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBGcm9tIHZlcnNpb24gLTA0IHRoZSBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIE1h cnNoYWxsIGFzIGENCj4+Pj4+Pj4gY28tYXV0aG9yLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAvTG9hDQo+ Pj4+Pj4+IChtcGxzIHdnIGNvLWNoYWlyKQ0KPj4+Pj4+PiAtLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOg0KPj4+ Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29uQGVyaWNz c29uLmNvbT4NCj4+Pj4+Pj4gU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2VyICAgICAg ICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQo+Pj4+Pj4+IEVyaWNzc29uIEluYyAg ICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIgMTM8dGVsOiUyQjQ2 JTIwMTAlMjA3MTclMjA1MiUyMDEzPg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICs0NiA3NjcgNzIgOTIgMTM8dGVsOiUyQjQ2JTIwNzY3JTIwNzIlMjA5 MiUyMDEzPg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBtcGxzQGlldGYub3Jn PG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+Pj4gbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBtcGxzIG1haWxpbmcgbGlzdA0KPj4+PiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4+Pg0KPj4+DQo+Pj4gVGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+IHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8NCj4+IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2Fi bGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlDQo+PiB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFy ZSBub3QgdGhlDQo+PiBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQo+PiBkaXN0cmlidXRpb24s IGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2Yg YW5kDQo+PiBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdQ0KPj4gaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4g cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+Pj4gbXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCj4+DQo+DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t cGxzDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D44865162dfweml505mbx_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Pat,

 

It is fair to point out this, and it is my bad to bring = NVO3 up in this thread. Given current NVO3 chartered task, the applicabilit= y of this to nvo3 is for further study.

 

However, both L2VPN and L3VPN WG are working on the IP V= PN and EVPN extensions into DC for multi-tenancy and several major operator= s and vendors are interested in and working on it now. As part of the extension work, both IP VPN and EVPN extension proposals state= the need to let BGP/MPLS based VPN over an common IP underlying infrastruc= ture instead of using MPLS server layer, i.e. LSP tunnel, since the MPLS ba= sed core switch is barely used in DCs. Based on current available standard, these proposals recommend to use= GRE encapsulation. But today DC switches/routers do not support GRE based = load balancing. DC traffic is mainly generated by the hosts that supports T= CP/UDP. Thus  DC switches commonly support UDP based load balancing. Therefore, this draft proposes an advanc= ed encapsulation, which can apply to the IP VPN and EVPN extension in data = centers and minimize the changes in DC infrastructure.  

 

Regards,

Lucy

 <= /p>

From: Pat Thal= er [mailto:pthaler@broadcom.com]
Sent: Friday, December 21, 2012 2:49 PM
To: Lucy yong; Andrew G. Malis; Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@= tools.ietf.org
Subject: RE: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

Lucy,

 <= /p>

If your draft is intended= to address the NVO3 requirements, then it should be considered in NVO3 alo= ng with the other proposed solutions rather than bypassing that process by submitting it to MPLS.

 <= /p>

The NVO charter requires = that the preliminary analysis work be completed before completing solutions= :

The NVO3 WG will write the following info= rmational RFCs, which
must have completed Working Group Last Call before rechartering can be
considered:

Problem Statement
Framework document
Control plane requirements document
Data plane requirements document
Operational Requirements
Gap Analysis

Driven by the requirements and consistent with the gap analysis,
the NVO3 WG may request being rechartered to document solutions
consisting of one or more data plane encapsulations and
control plane protocols as applicable.

 <= /p>

Based on the NVO3 charter= , it is premature to consider solutions at this point and suggesting that s= omething should go forward because it supports one item in a draft NVO3 requirements document is not justified.<= /p>

 <= /p>

Regards,

Pat

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lucy yong
Sent: Friday, December 21, 2012 11:27 AM
To: Andrew G. Malis; Shane Amante
Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@= tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

Andy,

 <= /p>

Here is the text from draft-ietf-nvo3-dataplane-requirements-00.txt

 <= /p>

  3.3.2.1. LAG and ECMP=  

 

    &nbs= p;  For performance reasons, multipath over LAG and ECMP paths SHOULD = be

    &nbs= p;  supported.

 

    &nbs= p;  LAG (Link Aggregation Group) [IEEE 802.1AX-2008] and ECMP (Equal

    &nbs= p;  Cost Multi Path) are commonly used techniques to perform load= -

    &nbs= p;  balancing of microflows over a set of a parallel links either at

    &nbs= p;  Layer-2 (LAG) or Layer-3 (ECMP). Existing deployed hardware

    &nbs= p;  implementations of LAG and ECMP uses a hash of various fields= in the

    &nbs= p;   encapsulation (outermost) header(s) (e.g. source and de= stination MAC

    &nbs= p;  addresses for non-IP traffic, source and destination IP addre= sses,

    &nbs= p;  L4 protocol, L4 source and destination port numbers, etc).

    &nbs= p;  Furthermore, hardware deployed for the underlay network(s) wi= ll be

    &nbs= p;  most often unaware of the carried, innermost L2 frames or L3 = packets

    &nbs= p;  transmitted by the TS. Thus, in order to perform fine-grained= load-

    &nbs= p;  balancing over LAG and ECMP paths in the underlying network, the

    &nbs= p;  encapsulation MUST result in sufficient entropy to exercise a= ll

    &nbs= p;  paths through several LAG/ECMP hops. The entropy information = MAY be

    &nbs= p;  inferred from the NVO3 overlay header or underlay header.

 

Our draft provides an advanc= ed solution in this space.

 <= /p>

Lucy

 <= /p>

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Friday, December 21, 2012 12:32 PM
To: Shane Amante
Cc: draft-xu-= mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-chairs@tools.ietf.org
Subject: Re: [mpls] poll to see if we have support to make draft-xu-= mpls-in-udp an mpls working group document

 

I've commented earlier on this draft, and like Shane= , I remain unconvinced of its utility. I still don't think it has any utili= ty at all for core backbone networks - just use native MPLS, or if you must= tunnel MPLS over IP, the GRE or L2TPv3 encapsulations. Regarding data center applications, I guess I could be con= vinced, but I would like to see a clear justification in the form of requir= ements from nvo3 that could only be met by this draft.

Thanks,
Andy

 

On Wed, Dec 19, 2012 at 9:38 AM, Shane Amante <shane@castlepoint.= net> wrote:

Xiaohu,


On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
-----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: Shane Amante [mail= to:shane@castlepoint.net]
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C219=C8=D5 11:58
>> =CA=D5=BC=FE=C8=CB: Rogers, Josh
>> =B3=AD=CB=CD: Shahram Davari; Xuxiaohu= ; draft-xu-mpls-in-udp@tools.ietf.org;
>> mpls@ietf.org; mpls-chairs@tools.ietf.org
>> =D6=F7=CC=E2: Re: [mpls] poll to see i= f we have support to make draft-xu-mpls-in-udp an
>> mpls working group document
>>
>>
>> On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com>
>> wrote:
>>> I share your SP perspective, and do not see the problem this s= olution
>>> addresses in practice any longer.
>>
>> +1.  Please do not define yet another MPLS-over-IP encaps= ulation.  The IETF
>> already standardized MPLS over GRE.  The IETF has also standa= rdized MPLS
>> over L2TPv3/UDP/IP, which had seen some deployment in at least one= , very
>> large operator network that I'm aware of to support carriage of L3= VPN over an
>> IP-only network.
>
> Hi Shane,
>
> Thank you for telling us there are actual deployments of MPLS over IP = in at least one, very large operator network. This fact must be very valuab= le to those people who had believed there is no application of MPLS over IP= in today's SP networks.
>
>> See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3
>> [NOTE: the dates the above were published was back in the 2006 tim= eframe!]
>>     RFC 4665 for requirements related to VPLS that say t= hat VPLS may be
>> carried over L2TPv3
>>     And, here's evidence showing that at least one vendo= r has implemented
>> IPVPN's over L2TPv3:
>> http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html >
> Thanks again for sharing the above information. As mentioned in this d= raft AND other drafts, the mechanism of performing hash calculation on the = Session ID field in the L2TPv3 header or the Key field in the GRE header as= defined in [RFC 5640] is not widely supported by existing core routers so far.

FWIW, I have had success, in the relatively recent p= ast, in requesting a core router vendor to support changes to the input-key= s used in hash calculations in _existing_ hardware, already deployed (exten= sively) throughout my network.  Further, I suspect that most large network operators are savvy folks and understand= the internal architecture of their HW fairly well.  As a result, thos= e same operators know what is and is not technically possible in this regar= d.  Thus, it may be a question of "methods" necessary to convince their HW supplier(s) to make appropriate changes in = their equipment to achieve their business goals.  :-)  However, t= his may not even be necessary ... see below.



> In contrast, most existing core routers are already capable of balanci= ng IP traffic flows based on the hash of the five-tuple of UDP packets. By = using the MPLS-in-UDP encapsulation, the already available load-balancing c= apability of most existing core routers can be leveraged without requiring any change to them. That is the major m= otivation of this draft.

If this is a concern, then why not encapsulate the t= raffic in MPLS/L2TPv3, which uses UDP/IP, in the first place?

IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931= , which would allow the connection used for data packets (not control packe= ts) to use a varying set of source ports (or, source IP addresses), based o= n a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core.  L2= TP end-system implementations would be better off just using the "Sess= ion ID" (and "Cookie") fields as the demultiplexor to associ= ate incoming packets with the associated L2TP Control Channel.  In fact, it's not clear to me that existing implementations may /alr= eady/ do this, making any "check" on the incoming source port unn= ecessary for L2TP end-system implementations.

The beauty of the above approach is:
1) I would think that the above is most likely a change that is limited to = the "control channel" (software) of existing L2TP end-system impl= ementations.  Heck, it may even be backwards compatible with existing = L2TPv3 implementations.  (L2TPv3 implementors would need to comment on that).
2) There is a substantial added security one gets by using "Session ID= " and "Cookie" fields to ensure the received L2TPv3 packet i= s intended for the identified session.  Quoting from Section 8.2 of RF= C 3931:
---snip---
   L2TPv3 provides traffic separation for its VPNs via a 32-bit S= ession
   ID in the L2TPv3 data header.  When present, the L2TPv3 C= ookie
   (described in Section 4.1), provides an additional check to en= sure
   that an arriving packet is intended for the identified session= .
   Thus, use of a Cookie with the Session ID provides an extra gu= arantee
   that the Session ID lookup was performed properly and that the=
   Session ID itself was not corrupted in transit.
---snip---
... in regard to this question alone, I know the Security Area folks have, = in the past, had /substantial/ concerns about encapsulation of MPLS over IP= transport.  In fact, this is why you see text in Section 7.6, "S= ecurity", of RFC 4665.  (There's likely similar language in other drafts that use MPLS for transport).  While I'm not= sure that Security Area folks pay much attention to daily traffic on the M= PLS WG mailing list, I'm fairly confident this concern will arise if/when t= his draft goes to the IESG ...
3) Finally, this approach only affects the end-systems that implement L2TP,= for tunneling of MPLS/IP, and does not require an entire industry to suppo= rt MPLS/UDP encapsulation in their product lines.

-shane



>
> Best regards,
> Xiaohu
>
>> If there was market demand for MPLS over IP, then clearly it would= have been
>> more widely implemented by equipment vendors, with either MPLS ove= r GRE or
>> MPLS over L2TPv3.  (Where there's a will, there's a way). &nb= sp;I would note that
>> the most likely reasons this did not pan out was there are several= , practical
>> operational benefits one gets from going with native MPLS
>> encapsulation/switching within the data plane, namely:
>> - MPLS Fast Re-Route
>> - MPLS Traffic Engineering
>> ... to name, but a few.  Those have tended to be quite compel= ling arguments
>> to 'upgrade' network HW to support MPLS encapsulation/switching. >>
>> -shane
>>
>>
>>> -Josh
>>>
>>>
>>> On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com> wrote:
>>>
>>>> For service provider domain, MPLS over IP is legacy and th= ere is no need
>>>> to improve it.
>>>>
>>>> Regards,
>>>> Shahram
>>>>
>>>>
>>>> On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com> wrote:
>>>>
>>>>> Shahram,
>>>>>
>>>>> This draft is ONLY intended to provide a MPLS-over-IP = encapsulation
>>>>> method with a better load-balancing applicability so f= ar to those
>>>>> operators who happen to require transporting MPLS appl= ication traffic
>>>>> across IP networks. I believe MPLS-based VPN over IP, = NVGRE and VXLAN
>>>>> each have their own advocators and use cases. If you a= bsolutely believe
>>>>> it's meaningless of transporting MPLS application traf= fic across IP
>>>>> networks and therefore those existing RFCs related to = MPLS over IP
>>>>> tunneling mechanisms should be moved to Historic statu= s, please say so.
>>>>>
>>>>> By the way, it seems this
>>>>> (http://www.ietf.org/mail-archive/w= eb/nvo3/current/msg01864.html) is
>>>>> just the right thread suitable for you to make the fol= lowing argument
>>>>> (i.e., whether or not MPLS-based VPN is applicable to = data centers). I
>>>>> had thought you would speak up at that time. Sadly, su= rprisingly silent
>>>>> till now.
>>>>>
>>>>> Sigh, I didn't intend to say the above otherwise.
>>>>>
>>>>> Xiaohu
>>>>>
>>>>>> -----=D3=CA=BC=FE=D4=AD=BC=FE= -----
>>>>>> =B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED
>> S.
>>>>>> Davari
>>>>>> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA12=D4=C215=C8=D5 13:34
>>>>>> =CA=D5=BC=FE=C8=CB: Lo= a Andersson
>>>>>> =B3=AD=CB=CD: draft-xu-mpls-in-udp@tools.ietf.org; m= pls@ietf.org;
>>>>>> mpls= -chairs@tools.ietf.org
>>>>>> =D6=F7=CC=E2: Re: [mpl= s] poll to see if we have support to make
>>>>>> draft-xu-mpls-in-udp an
>>>>>> mpls working group document
>>>>>>
>>>>>> I don't support this draft since it has no applica= tion in today's
>>>>>> modern metro
>>>>>> and core, where MPLS is dominant, and its only pra= ctical application
>>>>>> in in data
>>>>>> center, which already is crowded with other soluti= ons such as NVGRE and
>>>>>> VXLAN.
>>>>>>
>>>>>> It seems the authors are trying to bypass the NVO3= solution selection
>>>>>> process
>>>>>> by advancing the draft in MPLS WG.
>>>>>>
>>>>>> Regards,
>>>>>> Shahram
>>>>>>
>>>>>>
>>>>>> On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>>
>>>>>>> Working group,
>>>>>>>
>>>>>>> This is to start a "two week" poll o= n adopting
>>>>>>> draft-xu-mpls-in-udp-06 as an MPLS working gro= up document.
>>>>>>> Due to the holiday season this poll has been e= xtended with one week.
>>>>>>>
>>>>>>> Please send your comments (support/not support= ) to the mpls working
>>>>>>> group mailing list (mpls at ietf.org). Please give an technical
>>>>>>> motivation for your support/not support, espec= ially if you think that
>>>>>>> the document should not be adopted as a workin= g group document.
>>>>>>>
>>>>>>> This poll ends January 07, 2013.
>>>>>>>
>>>>>>> There is one IPR claim against this document -=
>>>>>>> https://datatracker.ietf.org/ipr/1941/ .
>>>>>>>
>>>>>>> All the active co-authors has stated on the wo= rking group mailing list
>>>>>>> that they are not aware of any other IPR claim= s than those already
>>>>>>> disclosed.
>>>>>>>
>>>>>>> However, up to version -03 (the document that = we used for the IPR
>>>>>>> poll)
>>>>>>> Marshall Eubanks was listed as one of the auth= ors. Marshall has
>>>>>>> discontinued all interactions with the IETF, i= ncluding the author team
>>>>>>> of draft-xu-mpls-in-udp-06. The working group = chairs has tried to
>>>>>>> contact Marshall by other means, to try get a = response on the IPR
>>>>>>> poll.
>>>>>>> We have had no success in this.
>>>>>>>
>>>>>>> From version -04 the authors decided to remove= Marshall as a
>>>>>>> co-author.
>>>>>>>
>>>>>>> /Loa
>>>>>>> (mpls wg co-chair)
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson         &nbs= p;               email:
>>>>>> loa.= andersson@ericsson.com
>>>>>>> Sr Strategy and Standards Manager    = ;        loa@pi.nu
>>>>>>> Ericsson Inc          = ;                phone: +46 10 717 52 13
>>>>>>>             &nbs= p;                     &n= bsp;      +46= 767 72 92 13
>>>>>>> ______________________________________________= _
>>>>>>> mpls mailing list
>>>>>>> mpls@ietf.org=
>>>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>>> _______________________________________________ >>>>>> mpls mailing list
>>>>>> mpls@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>> _______________________________________________
>>>>> mpls mailing list
>>>>> mpls@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>> _______________________________________________
>>>> mpls mailing list
>>>> mpls@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
>>> This E-mail and any of its attachments may contain Time Warner= Cable
>> proprietary information, which is privileged, confidential, or sub= ject to
>> copyright belonging to Time Warner Cable. This E-mail is intended = solely for the
>> use of the individual or entity to which it is addressed. If you a= re not the
>> intended recipient of this E-mail, you are hereby notified that an= y dissemination,
>> distribution, copying, or action taken in relation to the contents= of and
>> attachments to this E-mail is strictly prohibited and may be unlaw= ful. If you
>> have received this E-mail in error, please notify the sender immed= iately and
>> permanently delete the original and any copy of this E-mail and an= y printout.
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_2691CE0099834E4A9C5044EEC662BB9D44865162dfweml505mbx_-- From lucy.yong@huawei.com Wed Dec 26 08:02:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55421F8CB4 for ; Wed, 26 Dec 2012 08:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoeC74OU9BpX for ; Wed, 26 Dec 2012 08:02:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B37521F88D6 for ; Wed, 26 Dec 2012 08:02:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMW13498; Wed, 26 Dec 2012 16:01:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Dec 2012 16:01:35 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Dec 2012 16:01:56 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 26 Dec 2012 08:01:44 -0800 From: Lucy yong To: "S. Davari" , Xuxiaohu , Shahram Davari Thread-Topic: [mpls] MPLS client layer over an IGP underlying network Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiaAqA//99ORCAAJLQgIAAjTqAgABoZ4CAAF2yAIAAlXeAgAbj88A= Date: Wed, 26 Dec 2012 16:01:44 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448651CA@dfweml505-mbx> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com>, <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <9F9F2325-40B1-40BD-87D2-15E38447EBC5@broadcom.com>, <2691CE0099834E4A9C5044EEC662BB9D44864745@dfweml505-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758A33E@szxeml525-mbs.china.huawei.com> <1356077403.99620.YahooMailNeo@web162502.mail.bf1.yahoo.com> <2691CE0099834E4A9C5044EEC662BB9D44864E6B@dfweml505-mbx> <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com> In-Reply-To: <1356129621.73091.YahooMailNeo@web162504.mail.bf1.yahoo.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.225] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D448651CAdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-xu-mpls-in-udp@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS client layer over an IGP underlying network X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 16:02:09 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D448651CAdfweml505mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2hhaHJhbSwNCg0KRnJvbTogUy4gRGF2YXJpIFttYWlsdG86ZGF2YXJpc2hAeWFob28uY29tXQ0K U2VudDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiA0OjQwIFBNDQpUbzogTHVjeSB5b25nOyBY dXhpYW9odTsgU2hhaHJhbSBEYXZhcmkNCkNjOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5p ZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBu ZXR3b3JrDQoNCkx1Y3ksDQoNCkkgY2FuIG9ubHkgc2VlIENoaW5hIFRlbGVjb20gYXMgY28tYXV0 aG9yLCBhbmQgdGhlIEFwcGxpY2FiaWxpdHkgc2VjdGlvbiBzYXlzIEwyVlBOIGFuZCBMM1ZQTi4g U28gaXMgQ2hpbmEgVGVsZWNvbSB1c2luZyBpdCBmb3IgdGhlaXIgRW50ZXJwcmlzZSBWUE4gc2Vy dmljZT8gYnV0IHlvdXIgZWFybGllciBlbWFpbHMgc3VnZ2VzdHMgdGhhdCB0aGlzIGlzIG5vdCB0 aGUgaW50ZW5kZWQgdXNhZ2UgcmF0aGVyIGl0IGlzIGZvciBEYXRhIENlbnRlci4gU28gd2hpY2gg b25lIGlzIGl0PyBXaHkgaXNuJ3QgQ2hpbmEgVGVsZWNvbSBzcGVha2luZyBvbiB0aGUgbGlzdCBh bmQgZXhwbGFpbmluZyB0aGVpciB1c2FnZSBtb2RlbD8NCltMdWN5XSBDaGluYSBUZWxlY29tIGlz IGFsc28gYSBEQyBwcm92aWRlciBub3cgYW5kIG9mZmVyIHZhcmlvdXMgY2xvdWQgc2VydmljZXMg dGhyb3VnaCB0aGVpciBEQ3MuIElmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiwgcGxlYXNlIGNvbnRh Y3QgdGhlIG9wZXJhdG9yIGRpcmVjdGx5Lg0KDQoNCkFsc28gcmVnYXJkaW5nIE11bHRpY2FzdCwg dGhpcyBtZWFucyB5b3UgbmVlZCB0byBtYXAgTXVsdGljYXN0IHRyYWZmaWMgdG8gUDJQIFBXLCB3 aGljaCBpcyBpbmZlcmlvciB0byBvdGhlciBtZXRob2RzIHN1Y2ggYXMgTlZHUkUgYW5kIFZYTEFO IHNpbmNlIHRoZXkgbmF0aXZlbHkgc3VwcG9ydCBlZmZpY2llbnQgTXVsdGljYXN0Lg0KW0x1Y3ld IGJvdGggSVBWUE4gYW5kIEVWUE4gZG8gbm90IHVzZSBQVyBhdCBhbGwgYW5kIGJvdGggcHJvcG9z YWxzIGdpdmUgb3B0aW9ucyBmb3IgbXVsdGljYXN0IHRyYWZmaWMuIEkgZG9u4oCZdCBrbm93IHdo YXQgeW91IG1lYW4gdGhhdCBOVkdSRSBhbmQgVlhMQU4gbmF0aXZlbHkgc3VwcG9ydCBlZmZpY2ll bnQgbXVsdGljYXN0LiBQbGVhc2UgZXhwbGFpbi4NClRoYW5rcywNCkx1Y3kNCg0KDQpUaGFua3Ms DQpTaGFocmFtDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog THVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbT4NClRvOiBTLiBEYXZhcmkgPGRhdmFyaXNo QHlhaG9vLmNvbT47IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPjsgU2hhaHJhbSBEYXZh cmkgPGRhdmFyaUBicm9hZGNvbS5jb20+DQpDYzogImRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xz LmlldGYub3JnIiA8ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc+OyAibXBsc0Bp ZXRmLm9yZyIgPG1wbHNAaWV0Zi5vcmc+OyAibXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIDxt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjEsIDIw MTIgMTo1NToxMCBQTQ0KU3ViamVjdDogUkU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVy IGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCg0KDQpTaGFocmFtLA0KDQpQbGVhc2Ugc2VlIGlu bGluZS4NCg0KRnJvbTogUy4gRGF2YXJpIFttYWlsdG86ZGF2YXJpc2hAeWFob28uY29tXQ0KU2Vu dDogRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiAyOjEwIEFNDQpUbzogWHV4aWFvaHU7IFNoYWhy YW0gRGF2YXJpOyBMdWN5IHlvbmcNCkNjOiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbbXBsc10gTVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3 b3JrDQoNCkhpLA0KDQpJIHRoaW5rIHdlIGFyZSBpbiBhIHZpY2lvdXMgY3ljbGUuIENvdWxkIHlv dSBwbGVhc2UgY2xhcmlmeSB3aGljaCBuZXR3b3JrIG9wZXJhdG9yIGlzIGFza2luZyBmb3IgTVBM UyBvdmVyIFVEUCBhbmQgd2hhdCBpcyB0aGUgYXBwbGljYXRpb24uDQpbTHVjeV0gaXQgaXMgaW5k aWNhdGVkIGluIHRoZSBkcmFmdC4NCkFsc28gaG93IGRvIHlvdSBwbGFuIHRvIGFkZHJlc3MgdGhl IE1QTFMgTXVsdGljYXN0ICh3aGljaCBpcyBwcm9iYWJseSBtb3JlIGltcG9ydGFudCB0aGFuIGlt cHJvdmluZyB0aGUgbG9hZCBiYWxhbmNpbmcpLCBnaXZlbiB0aGF0IFJGQzQwMjMgZG9lcyBub3Qg c3VwcG9ydCBNdWx0aWNhc3QuDQpbTHVjeV0gTVBMUyBDbGllbnQgTGF5ZXIgaXMgcmVzcG9uc2li bGUgdG8gbWFwIG11bHRpY2FzdCB0cmFmZmljIHRvIHVuZGVybHlpbmcgdHJhbnNwb3J0LCB3aGlj aCBpcyBzcGVjaWZpZWQgaW4gRVZQTiBhbmQgSVAgVlBOLiBUaGlzIHByb3Bvc2FsIGp1c3QgcmVx dWVzdHMgaW5ncmVzcyBQRSB0byBmaWxsIHRoZSBmbG93IGVudHJvcHkgaW50byBVRFAgc291cmNl IHBvcnQsIGluIHdoaWNoIHRoZSBmbG93IGNhbiBiZSB1bmljYXN0IG9yIG11bHRpY2FzdC4NCg0K UmVnYXJkcywNCkx1Y3kNCg0KDQoNClRoYW5rcywNClNoYWhyYW0NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRnJvbTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+ DQpUbzogU2hhaHJhbSBEYXZhcmkgPGRhdmFyaUBicm9hZGNvbS5jb20+OyBMdWN5IHlvbmcgPGx1 Y3kueW9uZ0BodWF3ZWkuY29tPg0KQ2M6ICJkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRm Lm9yZyIgPGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsgIm1wbHNAaWV0Zi5v cmciIDxtcGxzQGlldGYub3JnPjsgIm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiA8bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIg NTo1NjoyMyBQTQ0KU3ViamVjdDogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFu IElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCg0KDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K PiDlj5Hku7bkuro6IG1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2Vz QGlldGYub3JnPl0g5Luj6KGoDQo+IFNoYWhyYW0gRGF2YXJpDQo+IOWPkemAgeaXtumXtDogMjAx MuW5tDEy5pyIMjHml6UgMTozMQ0KPiDmlLbku7bkuro6IEx1Y3kgeW9uZw0KPiDmioTpgIE6IGRy YWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxzLWlu LXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz47DQo+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQo+IOS4u+mimDogUmU6IFttcGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFu IElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCj4NCj4gUGxlYXNlIGRvbid0IG1peCB1cCB0aGluZ3Mu IFRoZSBNUExTIHByb3RvY29sIGRlc2lnbiBJIGFncmVlIG11c3QgYmUgZG9uZSBieQ0KPiBNUExT IFdHLiBCdXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91ciBwcm9wb3NhbCBtZWV0cyB0aGUg bmV0d29yaw0KPiB2aXJ0dWFsaXphdGlvbiByZXF1aXJlbWVudHMuDQoNCkNhbiB5b3UgdGVsbCB1 cyB3aGVyZSBNUExTLWluLUdSRS9JUCBbUkZDNDAyM10gYW5kIG90aGVyIE1QTFMgb3ZlciBJUCBl bmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmU/DQoNClNp bmNlIE1QTFMtaW4tVURQIGlzIGp1c3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiB0aGUgc2NlbmFy aW9zIHdoZXJlIE1QTFMtaW4tR1JFL0lQIGhhcyBiZWVuIHVzZWQgYW5kIGlzIHRvIGJlIHVzZWQs IE1QTFMtaW4tVURQIHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhlIHNhbWUgV0cgd2hlcmUgTVBM Uy1pbi1HUkUvSVAgaGFzIGJlZW4gZGlzY3Vzc2VkLg0KDQpYaWFvaHUNCg0KPiBUaGUgTlZPMyB0 YXNrIGlzIHRvIGRvY3VtZW50IHRoZSBpc3N1ZXMsIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3Jr IGZvcg0KPiBOdk8zLiBUaGVuIGlmIE1QTFMgb3ZlciBJUCBsb29rcyBsaWtlIGEgc3VpdGFibGUg c29sdXRpb24gdGhhdCBtZWV0cyB0aGUNCj4gcmVxdWlyZW1lbnRzIHN1Y2ggYXMgdGhlIHNjYWxl LCBtb2JpbGl0eSwgZXRjLCB0aGVuIHRoZXkgd2lsbCBhc2sgTVBMUyBXRyBmb3INCj4gcHJvdG9j b2wgZGVzaWduLg0KPg0KPiBTbyBiZWZvcmUgcHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJIHRoaW5r IHlvdSBzaG91bGQgdGFrZSBpdCB0byBOVk8zIFdHIGFuZA0KPiBjb252aW5jZSB0aGVtIHRoaXMg c29sdXRpb24gbWVldHMgdGhlaXIgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsuDQo+DQo+IFdl IGRvbid0IHdhbnQgSUVURiBkbyBkZXNpZ24gTiBudW1iZXIgb2Ygc29sdXRpb25zIGZvciB0aGUg c2FtZSBwcm9ibGVtLCBkbw0KPiB3ZT8NCj4NCj4gLVNoYWhyYW0NCj4NCj4NCj4NCj4gUmVnYXJk cywNCj4gU2hhaHJhbQ0KPg0KPg0KPiBPbiBEZWMgMjAsIDIwMTIsIGF0IDg6NTYgQU0sICJMdWN5 IHlvbmciIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4NCj4gPiBOZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgaXMgZGlzY3Vz c2VkIHVuZGVyIG52bzMgV0cuIFRoaXMgZG9lcyBub3QNCj4gbWVhbiB0aGF0IG52bzMgV0cgaGFz IHRvIGRlc2lnbiBhIG5ldyBwcm90b2NvbCBmb3IgYSB1bmRlcmx5aW5nIG5ldHdvcmsgb3IgYQ0K PiBuZXcgcHJvdG9jb2wgZm9yIGEgb3ZlcmxheSBuZXR3b3JrLiBJbiBmYWN0LCBwZW9wbGUgdGhl cmUgYWltIG9uIGxldmVyYWdlDQo+IHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xzIHRvIGFjY29t cGxpc2ggdGhlbS4gSU1POiB0aGVzZSBleHBhbnNpb25zIG9uIGFuDQo+IGV4aXN0aW5nIHN0YW5k YXJkIHByb3RvY29sIGhhdmUgdG8gYmUgd29ya2VkIG91dCBpbiB0aGUgcHJvdG9jb2wgV0cgZ3Jv dXAsIGl0DQo+IHNob3VsZCBub3QgZ2l2ZSBudm8zIFdHIGZyZWUgcmlnaHQgdG8gZW5oYW5jZSB0 aGVzZSBwcm90b2NvbHMuIEZvciBhIGJyYW5kDQo+IG5ldyBwcm90b2NvbCBmb3IgbmV0d29yayB2 aXJ0dWFsaXphdGlvbiBvdmVybGF5LCBudm8zIFdHIG1heSBiZSB0aGUgcGxhY2UgdG8NCj4gc3Rh cnQuDQo+ID4NCj4gPiBMdWN5DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogU2hhaHJhbSBEYXZhcmkgW21haWx0bzpkYXZhcmlAYnJvYWRjb20uY29tPG1h aWx0bzpkYXZhcmlAYnJvYWRjb20uY29tPl0NCj4gPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVy IDIwLCAyMDEyIDEwOjM0IEFNDQo+ID4+IFRvOiBMdWN5IHlvbmcNCj4gPj4gQ2M6IFNoYW5lIEFt YW50ZTsgZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXh1 LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPjsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz47DQo+ID4+IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNo YWlyc0B0b29scy5pZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFttcGxzXSBNUExTIGNsaWVu dCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcmsNCj4gPj4NCj4gPj4gTmV0d29y ayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBjb25zZW50ZWQg IGluIE5WTzMNCj4gPj4gV0cuDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IFNoYWhyYW0NCj4g Pj4NCj4gPj4NCj4gPj4gT24gRGVjIDIwLCAyMDEyLCBhdCA3OjM5IEFNLCAiTHVjeSB5b25nIiA8 bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4gd3JvdGU6 DQo+ID4+DQo+ID4+PiBIaSBTaGFuZSwNCj4gPj4+DQo+ID4+PiBJIHVuZGVyc3RhbmQgb3BlcmF0 b3IgY29uY2VybiBvbiBhIG5ldyBlbmNhcHN1bGF0aW9uIHRvIGFuIGV4aXN0aW5nDQo+ID4+IG5l dHdvcmsuDQo+ID4+Pg0KPiA+Pj4gSG93ZXZlciwgTVBMUy1pbi1VRFAgZG9lcyBub3QgYWltIG9u IGNoYW5naW5nIGV4aXN0aW5nIFNQIElQL01QTFMNCj4gPj4gbmV0d29yayBhdCBhbGwuDQo+ID4+ PiBNUExTLWluLVVEUCBpcyB0byBlbmFibGUgTVBMUyBjbGllbnQgbGF5ZXIgdG8gYmUgZGVjb3Vw bGVkIGZyb20gTVBMUw0KPiA+PiBzZXJ2ZXIgbGF5ZXIgYW5kIHVzZSBNUExTIGNsaWVudCBsYXll ciBhcyBvdmVybGF5IG5ldHdvcmsgYW5kIGFuIElHUCBhcw0KPiA+PiBhIHVuZGVybHlpbmcgbmV0 d29yayBmb3IgdHJhbnNwb3J0LiBTdWNoIGFwcGxpY2F0aW9uIGlzIGZvciBEQy4gWW91IG1heQ0K PiA+PiBhcmd1ZSB3aHkgbm90IHVzZSB0aGUgR1JFIHdoaWNoIGlzIGZvciBNUExTIGxheWVyIG92 ZXIgYW4gSUdQIHVuZGVybGluZw0KPiA+PiBuZXR3b3JrLiBXZSBoYXZlIHBvaW50ZWQgb3V0IGlu IHRoZSBkcmFmdCB0aGF0IGN1cnJlbnQgcm91dGVycyBpbiBEQw0KPiA+PiBiYXJlbHkgc3VwcG9y dCBHUkUgYmFzZWQgbG9hZCBiYWxhbmNpbmcgYW5kIE1QTFMtaW4tR1JFIGFyZSBiYXJlbHkgdXNl ZA0KPiA+PiBpbiBTUCBuZXR3b3JrcyB0b28uIE1vc3Qgb2Ygcm91dGVycyBpbiBEQyBwZXJmb3Jt IHVwZCBwb3J0IGJhc2VkIGxvYWQNCj4gPj4gYmFsYW5jaW5nIG5vdy4NCj4gPj4+DQo+ID4+PiBG cm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUsIHRoZSBVRFAgZW5jYXBzdWxhdGlvbiBo YXMNCj4gPj4gYWR2YW50YWdlIG92ZXIgR1JFIGVuY2Fwc3VsYXRpb24gdG9vLiBJbiBVRFAgZW5j YXBzdWxhdGlvbiwgdGhlIGZyYW1lDQo+ID4+IGhlYWRlciBkZWNvdXBsZXMgdGhlIG92ZXJsYXkg YW5kIHVuZGVybHlpbmcgbmV0d29yayBjbGVhcmx5LCBpLmUuIG91dGVyDQo+ID4+IGhlYWRlciBh bmQgb3ZlcmxheSBoZWFkZXIuIFVEUCBiZWxvbmdzIHRvIG91dGVyIGhlYWRlciwgd2hpY2gNCj4g Pj4gdW5kZXJseWluZyBuZXR3b3JrIHVzZXMgb25seS4gSG93ZXZlciwgR1JFIGhlYWRlciBoYXMg dGhlIGZpZWxkcyBmb3INCj4gPj4gdGhlIG92ZXJsYXkgbmV0d29yayBhbmQgdXNlcyB0aGUga2V5 IGZpZWxkIGZvciBmbG93IGVudHJvcHkuIEZvciBsb2FkDQo+ID4+IGJhbGFuY2luZywgaXQgcmVx dWlyZXMgdGhlIHVuZGVybHlpbmcgbmV0d29yayB1c2VzIEdSRSBoZWFkZXIgdG9vLiBJbg0KPiA+ PiBzaG9ydCwgR1JFIHRpZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlpbmcgbmV0d29ya3MgdG9n ZXRoZXIuIFNpbmNlIGl0DQo+ID4+IGhhcyBub3QgdXNlZCBhIGxvdCwgcGVvcGxlIGFyZSBub3Qg YXdhcmUgb2YgdGhlIGRpc2FkdmFudGFnZSBvZiBzdWNoDQo+ID4+IGNvdXBsaW5nLg0KPiA+Pj4N Cj4gPj4+IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlv biBvdmVybGF5IGFuZA0KPiA+PiBkZWNvdXBsZXMgb3ZlcmxheSBuZXR3b3JrcyBmcm9tIHRoZSB1 bmRlcmx5aW5nIG5ldHdvcmsuIEEgY2xlYXINCj4gPj4gc2VwYXJhdGlvbiBvZiBvdmVybGF5IGhl YWRlciBhbmQgdW5kZXJseWluZyBoZWFkZXIgaXMgYSAiTVVTVCIgaW4gbXkNCj4gPj4gb3Bpbmlv bi4gSWYgd2UgY291bnQgR1JFIGFzIHRoZSBvdmVybGF5IGhlYWRlciwgdGhlbiBmb3IgSVB2NA0K PiA+PiB1bmRlcmx5aW5nIG5ldHdvcmssIHRoZXJlIGlzIG5vIGZpZWxkIGZvciB0aGUgZmxvdyBl bnRyb3B5LiBUaGlzIGlzIHRoZQ0KPiA+PiByZWFzb24gd2UgcHJvcG9zZSB0aGUgVURQIGVuY2Fw c3VsYXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZw0KPiA+PiBuZXR3b3JrLiBJbiBm YWN0LCBpdCBjYW4gc3VwcG9ydCBhbnkgb3ZlcmxheSBuZXR3b3JrIGJlc2lkZSBNUExTIGNsaWVu dA0KPiA+PiBsYXllciAoZS5nLiBWWExBTiwgTDJUUC1pbi1VRFAsIGV0YykuDQo+ID4+Pg0KPiA+ Pj4gWW91IHBvaW50IG91dCB1c2luZyBNUExTLWluLUwyVFAtaW4tVURQIGluc3RlYWQuIFllcywg TVBMUy1pbi1MMlRQLQ0KPiA+PiBpbi1VRFAgc2NoZW1hIGFsc28gcHJvdmlkZXMgYSBvdmVybGF5 IChMMlRQKSBhbmQgdW5kZXJseWluZyAoSVApDQo+ID4+IG5ldHdvcmsgZGVjb3VwbGluZy4gTDJU UCBwcm90b2NvbCAocmZjMzkzMSkgcHJvdmlkZXMgZ29vZCBzZWN1cml0eQ0KPiA+PiBtZWNoYW5p c20gYW5kIGhhcyB0aGUgZW1iZWRkZWQgY29udHJvbCBmdW5jdGlvbiB0b28uIFRoZXJlZm9yZSwN Cj4gc29tZW9uZQ0KPiA+PiBjYW4gdXNlIGl0IGZvciBNUExTIGNsaWVudCBsYXllciBvdmVyIElu dGVybmV0LiBUbyBoYXZlIE1QTFMgY2xpZW50DQo+ID4+IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVy bGluZyBuZXR3b3JrLCBJTU86IE1QTFMtaW4tTDJUUC1pbi1VRFAgaXMgYQ0KPiA+PiBvdmVya2ls bCBhbmQgdG9vIGNvbXBsZXguIEhlcmUgd2UgbmVlZCBhIHNjaGVtYSB0byBzdXBwb3J0IElHUA0K PiA+PiB1bmRlcmx5aW5nIHRyYW5zcG9ydCB3aXRob3V0IHRvdWNoaW5nIGEgb3ZlcmxheSBoZWFk ZXIuIFVEUA0KPiA+PiBlbmNhcHN1bGF0aW9uIGlzIHRoZSBiZXN0IGNob2ljZSB0byBhY2NvbXBs aXNoIHRoYXQgYW5kIG1pbmltaXplIHRoZQ0KPiA+PiBjaGFuZ2VzIG9uIGV4aXN0aW5nIHJvdXRl cnMsIGUuZy4gY2hhbmdlIGF0IGVkZ2Ugcm91dGVycywgbm8gY2hhbmdlIG9uDQo+ID4+IHRyYW5z aXQgcm91dGVycy4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4gTHVjeQ0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJv bTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tPl0NCj4gPj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNDox NCBBTQ0KPiA+Pj4+IFRvOiBTaGFuZSBBbWFudGUNCj4gPj4+PiBDYzogUm9nZXJzLCBKb3NoOyBT aGFocmFtIERhdmFyaTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPj4gdWRwQHRvb2xzLmlldGYub3Jn PG1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmc+Ow0KPiA+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+Pj4gU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cg dG8gdHJhbnNwb3J0IE1QTFMgb3ZlciBVRFAgdHVubmVscw0KPiA+Pj4+DQo+ID4+Pj4gSGkgU2hh bmUsDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cyBhbmQg cGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmUuDQo+ID4+Pj4NCj4gPj4+PiBOb3RlOiBJIGNo YW5nZWQgdGhlIHN1YmplY3QgbGluZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi4NCj4g Pj4+Pg0KPiA+Pj4+PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+Pj4+IOWPkeS7tuS6ujog U2hhbmUgQW1hbnRlIFttYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0PG1haWx0bzpzaGFuZUBj YXN0bGVwb2ludC5uZXQ+XQ0KPiA+Pj4+PiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMuaciDE55pel IDIyOjM4DQo+ID4+Pj4+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4gPj4+Pj4g5oqE6YCBOiBSb2dl cnMsIEpvc2g7IFNoYWhyYW0gRGF2YXJpOyBkcmFmdC14dS1tcGxzLWluLQ0KPiA+Pj4+IHVkcEB0 b29scy5pZXRmLm9yZzxtYWlsdG86dWRwQHRvb2xzLmlldGYub3JnPjsNCj4gPj4+Pj4gbXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NCj4gPj4+Pj4g5Li76aKYOiBSZTog W21wbHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LQ0K PiA+Pj4+IG1wbHMtaW4tdWRwIGFuDQo+ID4+Pj4+IG1wbHMgd29ya2luZyBncm91cCBkb2N1bWVu dA0KPiA+Pj4+Pg0KPiA+Pj4+PiBYaWFvaHUsDQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIERlYyAxOCwg MjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tPj4NCj4gd3JvdGU6DQo+ID4+Pj4+IC0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCj4gPj4+Pj4+PiDlj5Hku7bkuro6IFNoYW5lIEFtYW50ZSBbbWFpbHRvOnNoYW5lQGNh c3RsZXBvaW50Lm5ldDxtYWlsdG86c2hhbmVAY2FzdGxlcG9pbnQubmV0Pl0NCj4gPj4+Pj4+PiDl j5HpgIHml7bpl7Q6IDIwMTLlubQxMuaciDE55pelIDExOjU4DQo+ID4+Pj4+Pj4g5pS25Lu25Lq6 OiBSb2dlcnMsIEpvc2gNCj4gPj4+Pj4+PiDmioTpgIE6IFNoYWhyYW0gRGF2YXJpOyBYdXhpYW9o dTsgZHJhZnQteHUtbXBscy1pbi0NCj4gPj4+PiB1ZHBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnVk cEB0b29scy5pZXRmLm9yZz47DQo+ID4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0Bp ZXRmLm9yZz47IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZz4NCj4gPj4+Pj4+PiDkuLvpopg6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUg aWYgd2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2UgZHJhZnQteHUtDQo+ID4+Pj4gbXBscy1pbi11ZHAN Cj4gPj4+Pj4gYW4NCj4gPj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQNCj4gPj4+ Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gRGVjIDE4LCAyMDEyLCBhdCA4OjUwIEFNLCAi Um9nZXJzLCBKb3NoIg0KPiA+Pj4+IDxqb3NoLnJvZ2Vyc0B0d2NhYmxlLmNvbTxtYWlsdG86am9z aC5yb2dlcnNAdHdjYWJsZS5jb20+Pg0KPiA+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBJIHNo YXJlIHlvdXIgU1AgcGVyc3BlY3RpdmUsIGFuZCBkbyBub3Qgc2VlIHRoZSBwcm9ibGVtIHRoaXMN Cj4gPj4+PiBzb2x1dGlvbg0KPiA+Pj4+Pj4+PiBhZGRyZXNzZXMgaW4gcHJhY3RpY2UgYW55IGxv bmdlci4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICsxLiAgUGxlYXNlIGRvIG5vdCBkZWZpbmUgeWV0 IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uDQo+ID4+Pj4gVGhlDQo+ID4+Pj4+ IElFVEYNCj4gPj4+Pj4+PiBhbHJlYWR5IHN0YW5kYXJkaXplZCBNUExTIG92ZXIgR1JFLiAgVGhl IElFVEYgaGFzIGFsc28NCj4gPj4+PiBzdGFuZGFyZGl6ZWQNCj4gPj4+Pj4gTVBMUw0KPiA+Pj4+ Pj4+IG92ZXIgTDJUUHYzL1VEUC9JUCwgd2hpY2ggaGFkIHNlZW4gc29tZSBkZXBsb3ltZW50IGlu IGF0IGxlYXN0DQo+ID4+IG9uZSwNCj4gPj4+PiB2ZXJ5DQo+ID4+Pj4+Pj4gbGFyZ2Ugb3BlcmF0 b3IgbmV0d29yayB0aGF0IEknbSBhd2FyZSBvZiB0byBzdXBwb3J0IGNhcnJpYWdlIG9mDQo+ID4+ Pj4gTDNWUE4gb3Zlcg0KPiA+Pj4+PiBhbg0KPiA+Pj4+Pj4+IElQLW9ubHkgbmV0d29yay4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBIaSBTaGFuZSwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFuayB5b3Ug Zm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJlIGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXIN Cj4gPj4+PiBJUCBpbiBhdA0KPiA+Pj4+PiBsZWFzdCBvbmUsIHZlcnkgbGFyZ2Ugb3BlcmF0b3Ig bmV0d29yay4gVGhpcyBmYWN0IG11c3QgYmUgdmVyeQ0KPiA+Pj4+IHZhbHVhYmxlIHRvIHRob3Nl DQo+ID4+Pj4+IHBlb3BsZSB3aG8gaGFkIGJlbGlldmVkIHRoZXJlIGlzIG5vIGFwcGxpY2F0aW9u IG9mIE1QTFMgb3ZlciBJUCBpbg0KPiA+Pj4+IHRvZGF5J3MgU1ANCj4gPj4+Pj4gbmV0d29ya3Mu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IFNlZTogUkZDJ3MgNDQ1NCwgNDcxOSwgNDU5MSwgNDM0OSBm b3IgUFdFMyBvdmVyIEwyVFB2Mw0KPiA+Pj4+Pj4+IFtOT1RFOiB0aGUgZGF0ZXMgdGhlIGFib3Zl IHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2DQo+ID4+Pj4+IHRpbWVmcmFtZSFd DQo+ID4+Pj4+Pj4gIFJGQyA0NjY1IGZvciByZXF1aXJlbWVudHMgcmVsYXRlZCB0byBWUExTIHRo YXQgc2F5IHRoYXQgVlBMUw0KPiA+Pj4+IG1heSBiZQ0KPiA+Pj4+Pj4+IGNhcnJpZWQgb3ZlciBM MlRQdjMNCj4gPj4+Pj4+PiAgQW5kLCBoZXJlJ3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxl YXN0IG9uZSB2ZW5kb3IgaGFzDQo+ID4+Pj4+IGltcGxlbWVudGVkDQo+ID4+Pj4+Pj4gSVBWUE4n cyBvdmVyIEwyVFB2MzoNCj4gPj4gaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3Mv MTJfMHMvZmVhdHVyZS9ndWlkZS9jc2dsM3Zwbi5odG1sDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhh bmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4gQXMgbWVudGlvbmVk IGluDQo+ID4+Pj4gdGhpcyBkcmFmdA0KPiA+Pj4+PiBBTkQgb3RoZXIgZHJhZnRzLCB0aGUgbWVj aGFuaXNtIG9mIHBlcmZvcm1pbmcgaGFzaCBjYWxjdWxhdGlvbiBvbg0KPiA+PiB0aGUNCj4gPj4+ PiBTZXNzaW9uDQo+ID4+Pj4+IElEIGZpZWxkIGluIHRoZSBMMlRQdjMgaGVhZGVyIG9yIHRoZSBL ZXkgZmllbGQgaW4gdGhlIEdSRSBoZWFkZXIgYXMNCj4gPj4+PiBkZWZpbmVkIGluDQo+ID4+Pj4+ IFtSRkMgNTY0MF0gaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgYnkgZXhpc3RpbmcgY29yZSByb3V0 ZXJzIHNvIGZhci4NCj4gPj4+Pj4NCj4gPj4+Pj4gRldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBp biB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwgaW4NCj4gPj4+PiByZXF1ZXN0aW5nIGEgY29y ZQ0KPiA+Pj4+PiByb3V0ZXIgdmVuZG9yIHRvIHN1cHBvcnQgY2hhbmdlcyB0byB0aGUgaW5wdXQt a2V5cyB1c2VkIGluIGhhc2gNCj4gPj4+PiBjYWxjdWxhdGlvbnMgaW4NCj4gPj4+Pj4gX2V4aXN0 aW5nXyBoYXJkd2FyZSwgYWxyZWFkeSBkZXBsb3llZCAoZXh0ZW5zaXZlbHkpIHRocm91Z2hvdXQg bXkNCj4gPj4+PiBuZXR3b3JrLg0KPiA+Pj4+PiBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0 IGxhcmdlIG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBzYXZ2eQ0KPiA+PiBmb2xrcw0KPiA+Pj4+IGFu ZA0KPiA+Pj4+PiB1bmRlcnN0YW5kIHRoZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIg SFcgZmFpcmx5IHdlbGwuICBBcyBhDQo+ID4+Pj4gcmVzdWx0LCB0aG9zZQ0KPiA+Pj4+PiBzYW1l IG9wZXJhdG9ycyBrbm93IHdoYXQgaXMgYW5kIGlzIG5vdCB0ZWNobmljYWxseSBwb3NzaWJsZSBp biB0aGlzDQo+ID4+Pj4gcmVnYXJkLg0KPiA+Pj4+PiBUaHVzLCBpdCBtYXkgYmUgYSBxdWVzdGlv biBvZiAibWV0aG9kcyIgbmVjZXNzYXJ5IHRvIGNvbnZpbmNlIHRoZWlyDQo+ID4+Pj4gSFcNCj4g Pj4+Pj4gc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVx dWlwbWVudCB0bw0KPiA+PiBhY2hpZXZlDQo+ID4+Pj4gdGhlaXINCj4gPj4+Pj4gYnVzaW5lc3Mg Z29hbHMuICA6LSkgIEhvd2V2ZXIsIHRoaXMgbWF5IG5vdCBldmVuIGJlIG5lY2Vzc2FyeSAuLi4N Cj4gPj4gc2VlDQo+ID4+Pj4gYmVsb3cuDQo+ID4+Pj4NCj4gPj4+PiBDb3VsZCB5b3UgcGxlYXNl IGJyaWVmbHkgZXhwbGFpbiBob3cgdG8gbWFrZSB0aGUgYWJvdmUgY2hhbmdlIGluDQo+ID4+Pj4g RVhJU1RJTkcgaGFyZHdhcmUgb2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/DQo+ID4+ Pj4NCj4gPj4+Pj4+IEluIGNvbnRyYXN0LCBtb3N0IGV4aXN0aW5nIGNvcmUgcm91dGVycyBhcmUg YWxyZWFkeSBjYXBhYmxlIG9mDQo+ID4+Pj4gYmFsYW5jaW5nIElQDQo+ID4+Pj4+IHRyYWZmaWMg Zmxvd3MgYmFzZWQgb24gdGhlIGhhc2ggb2YgdGhlIGZpdmUtdHVwbGUgb2YgVURQIHBhY2tldHMu DQo+ID4+IEJ5DQo+ID4+Pj4gdXNpbmcgdGhlDQo+ID4+Pj4+IE1QTFMtaW4tVURQIGVuY2Fwc3Vs YXRpb24sIHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBsb2FkLWJhbGFuY2luZw0KPiA+Pj4+IGNhcGFi aWxpdHkgb2YNCj4gPj4+Pj4gbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVy YWdlZCB3aXRob3V0IHJlcXVpcmluZyBhbnkNCj4gPj4+PiBjaGFuZ2UgdG8NCj4gPj4+Pj4gdGhl bS4gVGhhdCBpcyB0aGUgbWFqb3IgbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+Pj4+Pg0K PiA+Pj4+PiBJZiB0aGlzIGlzIGEgY29uY2VybiwgdGhlbiB3aHkgbm90IGVuY2Fwc3VsYXRlIHRo ZSB0cmFmZmljIGluDQo+ID4+Pj4gTVBMUy9MMlRQdjMsIHdoaWNoDQo+ID4+Pj4+IHVzZXMgVURQ L0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/DQo+ID4+Pj4NCj4gPj4+PiBJZiBJIHVuZGVyc3RhbmQg aXQgY29ycmVjdGx5LCB5b3UgcHJlZmVyIHRvIHVzZSBNUExTLWluLUwyVFB2My1pbi0NCj4gPj4g VURQDQo+ID4+Pj4gaW5zdGVhZCBvZiBNUExTLWluLVVEUCwgcmlnaHQ/DQo+ID4+Pj4NCj4gPj4+ Pj4gSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAo PykgY2hhbmdlIHRvDQo+ID4+Pj4gUkZDIDM5MzEsDQo+ID4+Pj4+IHdoaWNoIHdvdWxkIGFsbG93 IHRoZSBjb25uZWN0aW9uIHVzZWQgZm9yIGRhdGEgcGFja2V0cyAobm90IGNvbnRyb2wNCj4gPj4+ PiBwYWNrZXRzKQ0KPiA+Pj4+PiB0byB1c2UgYSB2YXJ5aW5nIHNldCBvZiBzb3VyY2UgcG9ydHMg KG9yLCBzb3VyY2UgSVAgYWRkcmVzc2VzKSwNCj4gPj4gYmFzZWQNCj4gPj4+PiBvbiBhIGhhc2gN Cj4gPj4+Pj4gY2FsY3VsYXRpb24sIHRvIGFjaGlldmUgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIG92 ZXIgZXhpc3RpbmcNCj4gPj4gZXF1aXBtZW50DQo+ID4+Pj4gaW4gYW4NCj4gPj4+Pj4gSVAtb25s eSBjb3JlLiAgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIg b2ZmDQo+ID4+Pj4ganVzdCB1c2luZw0KPiA+Pj4+PiB0aGUgIlNlc3Npb24gSUQiIChhbmQgIkNv b2tpZSIpIGZpZWxkcyBhcyB0aGUgZGVtdWx0aXBsZXhvciB0bw0KPiA+Pj4+IGFzc29jaWF0ZQ0K PiA+Pj4+PiBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQgTDJUUCBDb250cm9s IENoYW5uZWwuICBJbiBmYWN0LA0KPiA+Pj4+IGl0J3Mgbm90DQo+ID4+Pj4+IGNsZWFyIHRvIG1l IHRoYXQgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG1heSAvYWxyZWFkeS8gZG8gdGhpcywNCj4g Pj4+PiBtYWtpbmcgYW55DQo+ID4+Pj4+ICJjaGVjayIgb24gdGhlIGluY29taW5nIHNvdXJjZSBw b3J0IHVubmVjZXNzYXJ5IGZvciBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+Pj4gaW1wbGVtZW50YXRp b25zLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGUgYmVhdXR5IG9mIHRoZSBhYm92ZSBhcHByb2FjaCBp czoNCj4gPj4+Pj4gMSkgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBhYm92ZSBpcyBtb3N0IGxpa2Vs eSBhIGNoYW5nZSB0aGF0IGlzDQo+ID4+Pj4gbGltaXRlZCB0byB0aGUNCj4gPj4+Pj4gImNvbnRy b2wgY2hhbm5lbCIgKHNvZnR3YXJlKSBvZiBleGlzdGluZyBMMlRQIGVuZC1zeXN0ZW0NCj4gPj4+ PiBpbXBsZW1lbnRhdGlvbnMuDQo+ID4+Pj4+IEhlY2ssIGl0IG1heSBldmVuIGJlIGJhY2t3YXJk cyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgTDJUUHYzDQo+ID4+Pj4+IGltcGxlbWVudGF0aW9u cy4gIChMMlRQdjMgaW1wbGVtZW50b3JzIHdvdWxkIG5lZWQgdG8gY29tbWVudCBvbg0KPiA+PiB0 aGF0KS4NCj4gPj4+Pg0KPiA+Pj4+IElNSE8sIG5vIG1hdHRlciBNUExTLWluLUwyVFB2My1pbi1V RFAgb3IgTVBMUy1pbi1VRFAsICB0aGUgaGFyZHdhcmUNCj4gPj4gb2YNCj4gPj4+PiBQRSByb3V0 ZXJzIG5lZWRzIHRvIGJlIHVwZ3JhZGVkLCBlLmcuLCBpbmdyZXNzIFBFIHJvdXRlcnMgbmVlZCB0 bw0KPiA+PiBmaWxsDQo+ID4+Pj4gaW4gYW4gZW50cm9weSB2YWx1ZSBpbiB0aGUgc291cmNlIHBv cnQgZmllbGQgb2YgVURQIGhlYWRlcnMuDQo+ID4+Pj4NCj4gPj4+Pj4gMikgVGhlcmUgaXMgYSBz dWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBieSB1c2luZyAiU2Vzc2lvbg0KPiA+ Pj4+IElEIiBhbmQNCj4gPj4+Pj4gIkNvb2tpZSIgZmllbGRzIHRvIGVuc3VyZSB0aGUgcmVjZWl2 ZWQgTDJUUHYzIHBhY2tldCBpcyBpbnRlbmRlZA0KPiA+PiBmb3INCj4gPj4+PiB0aGUNCj4gPj4+ Pj4gaWRlbnRpZmllZCBzZXNzaW9uLiAgUXVvdGluZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAz OTMxOg0KPiA+Pj4+PiAtLS1zbmlwLS0tDQo+ID4+Pj4+ICBMMlRQdjMgcHJvdmlkZXMgdHJhZmZp YyBzZXBhcmF0aW9uIGZvciBpdHMgVlBOcyB2aWEgYSAzMi1iaXQNCj4gPj4+PiBTZXNzaW9uDQo+ ID4+Pj4+ICBJRCBpbiB0aGUgTDJUUHYzIGRhdGEgaGVhZGVyLiAgV2hlbiBwcmVzZW50LCB0aGUg TDJUUHYzIENvb2tpZQ0KPiA+Pj4+PiAgKGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSksIHByb3Zp ZGVzIGFuIGFkZGl0aW9uYWwgY2hlY2sgdG8NCj4gPj4gZW5zdXJlDQo+ID4+Pj4+ICB0aGF0IGFu IGFycml2aW5nIHBhY2tldCBpcyBpbnRlbmRlZCBmb3IgdGhlIGlkZW50aWZpZWQgc2Vzc2lvbi4N Cj4gPj4+Pj4gIFRodXMsIHVzZSBvZiBhIENvb2tpZSB3aXRoIHRoZSBTZXNzaW9uIElEIHByb3Zp ZGVzIGFuIGV4dHJhDQo+ID4+Pj4gZ3VhcmFudGVlDQo+ID4+Pj4+ICB0aGF0IHRoZSBTZXNzaW9u IElEIGxvb2t1cCB3YXMgcGVyZm9ybWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZQ0KPiA+Pj4+PiAg U2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC4NCj4gPj4+Pj4g LS0tc25pcC0tLQ0KPiA+Pj4+PiAuLi4gaW4gcmVnYXJkIHRvIHRoaXMgcXVlc3Rpb24gYWxvbmUs IEkga25vdyB0aGUgU2VjdXJpdHkgQXJlYQ0KPiA+PiBmb2xrcw0KPiA+Pj4+IGhhdmUsIGluIHRo ZQ0KPiA+Pj4+PiBwYXN0LCBoYWQgL3N1YnN0YW50aWFsLyBjb25jZXJucyBhYm91dCBlbmNhcHN1 bGF0aW9uIG9mIE1QTFMgb3Zlcg0KPiA+PiBJUA0KPiA+Pj4+IHRyYW5zcG9ydC4NCj4gPj4+Pj4g SW4gZmFjdCwgdGhpcyBpcyB3aHkgeW91IHNlZSB0ZXh0IGluIFNlY3Rpb24gNy42LCAiU2VjdXJp dHkiLCBvZg0KPiA+PiBSRkMNCj4gPj4+PiA0NjY1Lg0KPiA+Pj4+PiAoVGhlcmUncyBsaWtlbHkg c2ltaWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhhdCB1c2UgTVBMUyBmb3INCj4gPj4+ PiB0cmFuc3BvcnQpLg0KPiA+Pj4+PiBXaGlsZSBJJ20gbm90IHN1cmUgdGhhdCBTZWN1cml0eSBB cmVhIGZvbGtzIHBheSBtdWNoIGF0dGVudGlvbiB0bw0KPiA+Pj4+IGRhaWx5IHRyYWZmaWMgb24N Cj4gPj4+Pj4gdGhlIE1QTFMgV0cgbWFpbGluZyBsaXN0LCBJJ20gZmFpcmx5IGNvbmZpZGVudCB0 aGlzIGNvbmNlcm4gd2lsbA0KPiA+Pj4+IGFyaXNlIGlmL3doZW4gdGhpcw0KPiA+Pj4+PiBkcmFm dCBnb2VzIHRvIHRoZSBJRVNHIC4uLg0KPiA+Pj4+DQo+ID4+Pj4gSWYgSSB1bmRlcnN0YW5kIGl0 IGNvcnJlY3RseSwgdGhlIHJlYXNvbiBmb3IgeW91ciBwcmVmZXJlbmNlIG9mDQo+ID4+IE1QTFMt DQo+ID4+Pj4gaW4tTDJUUHYzLWluLVVEUCBpcyB0aGF0IGl0IGhhcyBhbiBhZGRlZCBzZWN1cml0 eSBmZWF0dXJlLiBJZiB0aGF0DQo+ID4+IGlzDQo+ID4+Pj4gc28gY29uY2VybmVkLCBjYW4geW91 IGV4cGxhaW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXINCj4gPj4gdGhhbg0K PiA+Pj4+IE1QTFMtaW4tTDJUUCBpbiBwcmFjdGljZT8NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QgcmVn YXJkcywNCj4gPj4+PiBYaWFvaHUNCj4gPj4+Pg0KPiA+Pj4+PiAzKSBGaW5hbGx5LCB0aGlzIGFw cHJvYWNoIG9ubHkgYWZmZWN0cyB0aGUgZW5kLXN5c3RlbXMgdGhhdA0KPiA+PiBpbXBsZW1lbnQN Cj4gPj4+PiBMMlRQLCBmb3INCj4gPj4+Pj4gdHVubmVsaW5nIG9mIE1QTFMvSVAsIGFuZCBkb2Vz IG5vdCByZXF1aXJlIGFuIGVudGlyZSBpbmR1c3RyeSB0bw0KPiA+Pj4+IHN1cHBvcnQNCj4gPj4+ Pj4gTVBMUy9VRFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLg0KPiA+Pj4+ Pg0KPiA+Pj4+PiAtc2hhbmUNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBC ZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gSWYgdGhl cmUgd2FzIG1hcmtldCBkZW1hbmQgZm9yIE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0DQo+ ID4+IHdvdWxkDQo+ID4+Pj4gaGF2ZQ0KPiA+Pj4+PiBiZWVuDQo+ID4+Pj4+Pj4gbW9yZSB3aWRl bHkgaW1wbGVtZW50ZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMsIHdpdGggZWl0aGVyIE1QTFMNCj4g Pj4+PiBvdmVyDQo+ID4+Pj4+IEdSRSBvcg0KPiA+Pj4+Pj4+IE1QTFMgb3ZlciBMMlRQdjMuICAo V2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkpLiAgSQ0KPiA+PiB3b3VsZA0KPiA+ Pj4+IG5vdGUNCj4gPj4+Pj4gdGhhdA0KPiA+Pj4+Pj4+IHRoZSBtb3N0IGxpa2VseSByZWFzb25z IHRoaXMgZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmUNCj4gPj4gc2V2ZXJhbCwNCj4gPj4+ PiBwcmFjdGljYWwNCj4gPj4+Pj4+PiBvcGVyYXRpb25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9t IGdvaW5nIHdpdGggbmF0aXZlIE1QTFMNCj4gPj4+Pj4+PiBlbmNhcHN1bGF0aW9uL3N3aXRjaGlu ZyB3aXRoaW4gdGhlIGRhdGEgcGxhbmUsIG5hbWVseToNCj4gPj4+Pj4+PiAtIE1QTFMgRmFzdCBS ZS1Sb3V0ZQ0KPiA+Pj4+Pj4+IC0gTVBMUyBUcmFmZmljIEVuZ2luZWVyaW5nDQo+ID4+Pj4+Pj4g Li4uIHRvIG5hbWUsIGJ1dCBhIGZldy4gIFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNv bXBlbGxpbmcNCj4gPj4+Pj4gYXJndW1lbnRzDQo+ID4+Pj4+Pj4gdG8gJ3VwZ3JhZGUnIG5ldHdv cmsgSFcgdG8gc3VwcG9ydCBNUExTIGVuY2Fwc3VsYXRpb24vc3dpdGNoaW5nLg0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4gLXNoYW5lDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtSm9z aA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBPbiAxMi8xOC8xMiAxMjozMSBB TSwgIlNoYWhyYW0gRGF2YXJpIiA8ZGF2YXJpQGJyb2FkY29tLmNvbTxtYWlsdG86ZGF2YXJpQGJy b2FkY29tLmNvbT4+DQo+ID4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gRm9y IHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCBNUExTIG92ZXIgSVAgaXMgbGVnYWN5IGFuZCB0aGVy ZQ0KPiA+PiBpcw0KPiA+Pj4+IG5vIG5lZWQNCj4gPj4+Pj4+Pj4+IHRvIGltcHJvdmUgaXQuDQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+IFNoYWhyYW0NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gT24gRGVjIDE3LCAyMDEyLCBhdCA4 OjAyIFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tPj4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFNo YWhyYW0sDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50 ZW5kZWQgdG8gcHJvdmlkZSBhIE1QTFMtb3Zlci1JUA0KPiA+Pj4+IGVuY2Fwc3VsYXRpb24NCj4g Pj4+Pj4+Pj4+PiBtZXRob2Qgd2l0aCBhIGJldHRlciBsb2FkLWJhbGFuY2luZyBhcHBsaWNhYmls aXR5IHNvIGZhciB0bw0KPiA+Pj4+IHRob3NlDQo+ID4+Pj4+Pj4+Pj4gb3BlcmF0b3JzIHdobyBo YXBwZW4gdG8gcmVxdWlyZSB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbg0KPiA+Pj4+IHRy YWZmaWMNCj4gPj4+Pj4+Pj4+PiBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJh c2VkIFZQTiBvdmVyIElQLCBOVkdSRQ0KPiA+PiBhbmQNCj4gPj4+Pj4gVlhMQU4NCj4gPj4+Pj4+ Pj4+PiBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91 DQo+ID4+IGFic29sdXRlbHkNCj4gPj4+PiBiZWxpZXZlDQo+ID4+Pj4+Pj4+Pj4gaXQncyBtZWFu aW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFmZmljDQo+ID4+Pj4g YWNyb3NzIElQDQo+ID4+Pj4+Pj4+Pj4gbmV0d29ya3MgYW5kIHRoZXJlZm9yZSB0aG9zZSBleGlz dGluZyBSRkNzIHJlbGF0ZWQgdG8gTVBMUw0KPiA+PiBvdmVyDQo+ID4+Pj4gSVANCj4gPj4+Pj4+ Pj4+PiB0dW5uZWxpbmcgbWVjaGFuaXNtcyBzaG91bGQgYmUgbW92ZWQgdG8gSGlzdG9yaWMgc3Rh dHVzLA0KPiA+PiBwbGVhc2UNCj4gPj4+PiBzYXkNCj4gPj4+Pj4gc28uDQo+ID4+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+PiBCeSB0aGUgd2F5LCBpdCBzZWVtcyB0aGlzDQo+ID4+Pj4+Pj4+Pj4gKGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4gPj4+PiBhcmNoaXZlL3dlYi9udm8zL2N1cnJlbnQv bXNnMDE4NjQuaHRtbCkgaXMNCj4gPj4+Pj4+Pj4+PiBqdXN0IHRoZSByaWdodCB0aHJlYWQgc3Vp dGFibGUgZm9yIHlvdSB0byBtYWtlIHRoZSBmb2xsb3dpbmcNCj4gPj4+PiBhcmd1bWVudA0KPiA+ Pj4+Pj4+Pj4+IChpLmUuLCB3aGV0aGVyIG9yIG5vdCBNUExTLWJhc2VkIFZQTiBpcyBhcHBsaWNh YmxlIHRvIGRhdGENCj4gPj4+PiBjZW50ZXJzKS4gSQ0KPiA+Pj4+Pj4+Pj4+IGhhZCB0aG91Z2h0 IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LA0KPiA+Pj4+IHN1cnByaXNp bmdseSBzaWxlbnQNCj4gPj4+Pj4+Pj4+PiB0aWxsIG5vdy4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+IFNpZ2gsIEkgZGlkbid0IGludGVuZCB0byBzYXkgdGhlIGFib3ZlIG90aGVyd2lzZS4N Cj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IFhpYW9odQ0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4+Pj4+Pj4+Pj4g5Y+R5Lu25Lq6OiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dDQo+ ID4+IOS7ow0KPiA+Pj4+IOihqA0KPiA+Pj4+Pj4+IFMuDQo+ID4+Pj4+Pj4+Pj4+IERhdmFyaQ0K PiA+Pj4+Pj4+Pj4+PiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMuaciDE15pelIDEzOjM0DQo+ID4+ Pj4+Pj4+Pj4+IOaUtuS7tuS6ujogTG9hIEFuZGVyc3Nvbg0KPiA+Pj4+Pj4+Pj4+PiDmioTpgIE6 IGRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC14dS1tcGxz LWluLXVkcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+Ow0KPiA+Pj4+Pj4+Pj4+PiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQo+ID4+Pj4+Pj4+Pj4+IOS4u+mimDogUmU6IFttcGxz XSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZQ0KPiA+Pj4+Pj4+Pj4+PiBk cmFmdC14dS1tcGxzLWluLXVkcCBhbg0KPiA+Pj4+Pj4+Pj4+PiBtcGxzIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gSSBkb24ndCBzdXBwb3J0IHRo aXMgZHJhZnQgc2luY2UgaXQgaGFzIG5vIGFwcGxpY2F0aW9uIGluDQo+ID4+Pj4gdG9kYXkncw0K PiA+Pj4+Pj4+Pj4+PiBtb2Rlcm4gbWV0cm8NCj4gPj4+Pj4+Pj4+Pj4gYW5kIGNvcmUsIHdoZXJl IE1QTFMgaXMgZG9taW5hbnQsIGFuZCBpdHMgb25seSBwcmFjdGljYWwNCj4gPj4+PiBhcHBsaWNh dGlvbg0KPiA+Pj4+Pj4+Pj4+PiBpbiBpbiBkYXRhDQo+ID4+Pj4+Pj4+Pj4+IGNlbnRlciwgd2hp Y2ggYWxyZWFkeSBpcyBjcm93ZGVkIHdpdGggb3RoZXIgc29sdXRpb25zIHN1Y2ggYXMNCj4gPj4+ PiBOVkdSRQ0KPiA+Pj4+PiBhbmQNCj4gPj4+Pj4+Pj4+Pj4gVlhMQU4uDQo+ID4+Pj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+Pj4+IEl0IHNlZW1zIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdG8gYnlwYXNz IHRoZSBOVk8zIHNvbHV0aW9uDQo+ID4+Pj4gc2VsZWN0aW9uDQo+ID4+Pj4+Pj4+Pj4+IHByb2Nl c3MNCj4gPj4+Pj4+Pj4+Pj4gYnkgYWR2YW5jaW5nIHRoZSBkcmFmdCBpbiBNUExTIFdHLg0KPiA+ Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pj4+Pj4+PiBTaGFocmFt DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IE9uIERlYyAxNCwg MjAxMiwgYXQgMTowMSBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGku bnU+PiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFdvcmtpbmcgZ3JvdXAs DQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyB0byBzdGFydCBhICJ0d28g d2VlayIgcG9sbCBvbiBhZG9wdGluZw0KPiA+Pj4+Pj4+Pj4+Pj4gZHJhZnQteHUtbXBscy1pbi11 ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+Pj4+Pj4+Pj4+Pj4g RHVlIHRvIHRoZSBob2xpZGF5IHNlYXNvbiB0aGlzIHBvbGwgaGFzIGJlZW4gZXh0ZW5kZWQgd2l0 aA0KPiA+Pj4+IG9uZSB3ZWVrLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFBsZWFz ZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzDQo+ ID4+Pj4+IHdvcmtpbmcNCj4gPj4+Pj4+Pj4+Pj4+IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBh dCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuDQo+ID4+Pj4gdGVjaG5pY2FsDQo+ID4+Pj4+Pj4+ Pj4+PiBtb3RpdmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkg aWYgeW91DQo+ID4+Pj4gdGhpbmsgdGhhdA0KPiA+Pj4+Pj4+Pj4+Pj4gdGhlIGRvY3VtZW50IHNo b3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXANCj4gPj4+PiBkb2N1bWVudC4N Cj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIHBvbGwgZW5kcyBKYW51YXJ5IDA3 LCAyMDEzLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IFRoZXJlIGlzIG9uZSBJUFIg Y2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50IC0NCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvIC4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ Pj4+PiBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcg Z3JvdXANCj4gPj4+PiBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IHRoYXQgdGhleSBhcmUg bm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIHRoYW4gdGhvc2UNCj4gPj4+PiBhbHJl YWR5DQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjbG9zZWQuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4+Pj4gSG93ZXZlciwgdXAgdG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVz ZWQgZm9yDQo+ID4+IHRoZQ0KPiA+Pj4+IElQUg0KPiA+Pj4+Pj4+Pj4+Pj4gcG9sbCkNCj4gPj4+ Pj4+Pj4+Pj4+IE1hcnNoYWxsIEV1YmFua3Mgd2FzIGxpc3RlZCBhcyBvbmUgb2YgdGhlIGF1dGhv cnMuIE1hcnNoYWxsDQo+ID4+Pj4gaGFzDQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjb250aW51ZWQgYWxs IGludGVyYWN0aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlDQo+ID4+Pj4gYXV0aG9y IHRlYW0NCj4gPj4+Pj4+Pj4+Pj4+IG9mIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTA2LiBUaGUgd29y a2luZyBncm91cCBjaGFpcnMgaGFzDQo+ID4+Pj4gdHJpZWQgdG8NCj4gPj4+Pj4+Pj4+Pj4+IGNv bnRhY3QgTWFyc2hhbGwgYnkgb3RoZXIgbWVhbnMsIHRvIHRyeSBnZXQgYSByZXNwb25zZSBvbg0K PiA+PiB0aGUNCj4gPj4+PiBJUFINCj4gPj4+Pj4+Pj4+Pj4+IHBvbGwuDQo+ID4+Pj4+Pj4+Pj4+ PiBXZSBoYXZlIGhhZCBubyBzdWNjZXNzIGluIHRoaXMuDQo+ID4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4+Pj4gRnJvbSB2ZXJzaW9uIC0wNCB0aGUgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSBN YXJzaGFsbCBhcyBhDQo+ID4+Pj4+Pj4+Pj4+PiBjby1hdXRob3IuDQo+ID4+Pj4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+Pj4gL0xvYQ0KPiA+Pj4+Pj4+Pj4+Pj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+ ID4+Pj4+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+PiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6DQo+ID4+ Pj4+Pj4+Pj4+IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpsb2EuYW5kZXJzc29u QGVyaWNzc29uLmNvbT4NCj4gPj4+Pj4+Pj4+Pj4+IFNyIFN0cmF0ZWd5IGFuZCBTdGFuZGFyZHMg TWFuYWdlciAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KPiA+Pj4+Pj4+ Pj4+Pj4gRXJpY3Nzb24gSW5jICAgICAgICAgICAgICAgICAgICAgICAgICBwaG9uZTogKzQ2IDEw IDcxNw0KPiA1Mg0KPiA+PiAxMw0KPiA+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5Mg0KPiAxMw0KPiA+Pj4+Pj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+ Pj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+ID4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+Pj4+Pj4+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+ID4+ Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+ Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+PiBtcGxzQGlldGYu b3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KPiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+IG1wbHMgbWFpbGluZyBs aXN0DQo+ID4+Pj4+Pj4+PiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyDQo+ID4+Pj4gQ2FibGUNCj4gPj4+ Pj4+PiBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlk ZW50aWFsLCBvcg0KPiA+Pj4+IHN1YmplY3QgdG8NCj4gPj4+Pj4+PiBjb3B5cmlnaHQgYmVsb25n aW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZA0KPiA+Pj4+ IHNvbGVseSBmb3INCj4gPj4+Pj4gdGhlDQo+ID4+Pj4+Pj4gdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0KPiA+Pj4+IGFyZSBu b3QgdGhlDQo+ID4+Pj4+Pj4gaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0DQo+ID4+Pj4gYW55DQo+ID4+Pj4+IGRpc3NlbWluYXRp b24sDQo+ID4+Pj4+Pj4gZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4g cmVsYXRpb24gdG8gdGhlDQo+ID4+IGNvbnRlbnRzDQo+ID4+Pj4gb2YgYW5kDQo+ID4+Pj4+Pj4g YXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlDQo+ID4+Pj4gdW5sYXdmdWwuIElmIHlvdQ0KPiA+Pj4+Pj4+IGhhdmUgcmVjZWl2ZWQgdGhp cyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+Pj4+IGltbWVk aWF0ZWx5IGFuZA0KPiA+Pj4+Pj4+IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZA0KPiA+Pj4+IGFueSBwcmludG91dC4NCj4gPj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4+Pj4+Pj4gbXBscyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz4NCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4+PiBtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbXBscw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D448651CAdfweml505mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2MjAzOTM3MzAyNm1zb25v cm1hbCwgbGkueWl2MjAzOTM3MzAyNm1zb25vcm1hbCwgZGl2LnlpdjIwMzkzNzMwMjZtc29ub3Jt YWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3MzAyNm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXYyMDM5MzczMDI2bXNvY2hwZGVm YXVsdCwgbGkueWl2MjAzOTM3MzAyNm1zb2NocGRlZmF1bHQsIGRpdi55aXYyMDM5MzczMDI2bXNv Y2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTp5aXYyMDM5MzczMDI2bXNvY2hwZGVmYXVsdDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYyMDM5 MzczMDI2bXNvaHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjIwMzkzNzMwMjZtc29oeXBl cmxpbms7fQ0Kc3Bhbi55aXYyMDM5MzczMDI2bXNvaHlwZXJsaW5rZm9sbG93ZWQNCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MjAzOTM3MzAyNm1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2MjAz OTM3MzAyNmVtYWlsc3R5bGUxNw0KCXttc28tc3R5bGUtbmFtZTp5aXYyMDM5MzczMDI2ZW1haWxz dHlsZTE3O30NCnAueWl2MjAzOTM3MzAyNm1zb25vcm1hbDEsIGxpLnlpdjIwMzkzNzMwMjZtc29u b3JtYWwxLCBkaXYueWl2MjAzOTM3MzAyNm1zb25vcm1hbDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2 MjAzOTM3MzAyNm1zb25vcm1hbDE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4ueWl2MjAzOTM3MzAyNm1zb2h5cGVybGluazENCgl7bXNvLXN0eWxlLW5h bWU6eWl2MjAzOTM3MzAyNm1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MjAzOTM3MzAyNm1zb2h5cGVybGlua2ZvbGxvd2Vk MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYyMDM5MzczMDI2bXNvaHlwZXJsaW5rZm9sbG93ZWQxOw0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4ueWl2MjAz OTM3MzAyNmVtYWlsc3R5bGUxNzENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MjAzOTM3MzAyNmVtYWls c3R5bGUxNzE7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnAueWl2MjAzOTM3MzAyNm1zb2NocGRlZmF1bHQxLCBsaS55aXYyMDM5MzczMDI2 bXNvY2hwZGVmYXVsdDEsIGRpdi55aXYyMDM5MzczMDI2bXNvY2hwZGVmYXVsdDENCgl7bXNvLXN0 eWxlLW5hbWU6eWl2MjAzOTM3MzAyNm1zb2NocGRlZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TaGFocmFtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBTLiBEYXZhcmkgW21haWx0bzpkYXZhcmlzaEB5YWhvby5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAyMSwgMjAxMiA0OjQwIFBNPGJyPg0KPGI+ VG86PC9iPiBMdWN5IHlvbmc7IFh1eGlhb2h1OyBTaGFocmFtIERhdmFyaTxicj4NCjxiPkNjOjwv Yj4gZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10g TVBMUyBjbGllbnQgbGF5ZXIgb3ZlciBhbiBJR1AgdW5kZXJseWluZyBuZXR3b3JrPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkx1Y3ksPGJyPg0KPGJyPg0KSSBjYW4gb25seSBzZWUgQ2hpbmEgVGVsZWNvbSBhcyBjby1h dXRob3IsIGFuZCB0aGUgQXBwbGljYWJpbGl0eSBzZWN0aW9uIHNheXMgTDJWUE4gYW5kIEwzVlBO LiBTbyBpcyBDaGluYSBUZWxlY29tIHVzaW5nIGl0IGZvciB0aGVpciBFbnRlcnByaXNlIFZQTiBz ZXJ2aWNlPyBidXQgeW91ciBlYXJsaWVyIGVtYWlscyBzdWdnZXN0cyB0aGF0IHRoaXMgaXMgbm90 IHRoZSBpbnRlbmRlZCB1c2FnZSByYXRoZXIgaXQgaXMgZm9yIERhdGEgQ2VudGVyLg0KIFNvIHdo aWNoIG9uZSBpcyBpdD8gV2h5IGlzbid0IENoaW5hIFRlbGVjb20gc3BlYWtpbmcgb24gdGhlIGxp c3QgYW5kIGV4cGxhaW5pbmcgdGhlaXIgdXNhZ2UgbW9kZWw/PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMdWN5XSBDaGluYSBUZWxl Y29tIGlzIGFsc28gYSBEQyBwcm92aWRlciBub3cgYW5kIG9mZmVyIHZhcmlvdXMgY2xvdWQgc2Vy dmljZXMgdGhyb3VnaCB0aGVpciBEQ3MuIElmIHlvdQ0KIGFyZSBpbnRlcmVzdGVkIGluLCBwbGVh c2UgY29udGFjdCB0aGUgb3BlcmF0b3IgZGlyZWN0bHkuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0K PGJyPg0KQWxzbyByZWdhcmRpbmcgTXVsdGljYXN0LCB0aGlzIG1lYW5zIHlvdSBuZWVkIHRvIG1h cCBNdWx0aWNhc3QgdHJhZmZpYyB0byBQMlAgUFcsIHdoaWNoIGlzIGluZmVyaW9yIHRvIG90aGVy IG1ldGhvZHMgc3VjaCBhcyBOVkdSRSBhbmQgVlhMQU4gc2luY2UgdGhleSBuYXRpdmVseSBzdXBw b3J0IGVmZmljaWVudCBNdWx0aWNhc3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMdWN5XSBib3RoIElQVlBOIGFuZCBFVlBOIGRv IG5vdCB1c2UgUFcgYXQgYWxsIGFuZCBib3RoIHByb3Bvc2FscyBnaXZlIG9wdGlvbnMgZm9yIG11 bHRpY2FzdCB0cmFmZmljLiBJDQogZG9u4oCZdCBrbm93IHdoYXQgeW91IG1lYW4gdGhhdCBOVkdS RSBhbmQgVlhMQU4gbmF0aXZlbHkgc3VwcG9ydCBlZmZpY2llbnQgbXVsdGljYXN0LiBQbGVhc2Ug ZXhwbGFpbi48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MdWN5PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KU2hhaHJhbTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjEwMCUi IGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4gTHVjeSB5b25nICZsdDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5Ubzo8 L2I+IFMuIERhdmFyaSAmbHQ7ZGF2YXJpc2hAeWFob28uY29tJmd0OzsgWHV4aWFvaHUgJmx0O3h1 eGlhb2h1QGh1YXdlaS5jb20mZ3Q7OyBTaGFocmFtIERhdmFyaSAmbHQ7ZGF2YXJpQGJyb2FkY29t LmNvbSZndDsNCjxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9v bHMuaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3Jn Jmd0OzsgJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBsc0BpZXRmLm9yZyZndDs7ICZx dW90O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJnF1b3Q7ICZsdDttcGxzLWNoYWlyc0B0b29s cy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDIxLCAy MDEyIDE6NTU6MTAgUE08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFttcGxzXSBNUExTIGNsaWVu dCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcms8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9InlpdjIwMzkz NzMwMjYiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPlNoYWhyYW0sPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj5QbGVhc2Ugc2VlIGlubGluZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+IFMuIERhdmFyaSBbbWFpbHRvOmRhdmFyaXNoQHlhaG9vLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDIxLCAyMDEyIDI6MTAgQU08YnI+ DQo8Yj5Ubzo8L2I+IFh1eGlhb2h1OyBTaGFocmFtIERhdmFyaTsgTHVjeSB5b25nPGJyPg0KPGI+ Q2M6PC9iPiBkcmFmdC14dS1tcGxzLWluLXVkcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9y ZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtt cGxzXSBNUExTIGNsaWVudCBsYXllciBvdmVyIGFuIElHUCB1bmRlcmx5aW5nIG5ldHdvcms8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpLDxi cj4NCjxicj4NCkkgdGhpbmsgd2UgYXJlIGluIGEgdmljaW91cyBjeWNsZS4gQ291bGQgeW91IHBs ZWFzZSBjbGFyaWZ5IHdoaWNoIG5ldHdvcmsgb3BlcmF0b3IgaXMgYXNraW5nIGZvciBNUExTIG92 ZXIgVURQIGFuZCB3aGF0IGlzIHRoZSBhcHBsaWNhdGlvbi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj5bTHVjeV0gaXQgaXMgaW5kaWNhdGVkIGluIHRoZSBkcmFmdC48L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFsc28gaG93IGRvIHlvdSBwbGFuIHRvIGFkZHJlc3Mg dGhlIE1QTFMgTXVsdGljYXN0ICh3aGljaCBpcyBwcm9iYWJseSBtb3JlIGltcG9ydGFudCB0aGFu IGltcHJvdmluZyB0aGUgbG9hZCBiYWxhbmNpbmcpLCBnaXZlbiB0aGF0IFJGQzQwMjMgZG9lcyBu b3Qgc3VwcG9ydCBNdWx0aWNhc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPltMdWN5XSBNUExTIENs aWVudCBMYXllciBpcyByZXNwb25zaWJsZSB0byBtYXAgbXVsdGljYXN0IHRyYWZmaWMgdG8gdW5k ZXJseWluZyB0cmFuc3BvcnQsIHdoaWNoIGlzIHNwZWNpZmllZCBpbiBFVlBOIGFuZCBJUCBWUE4u IFRoaXMgcHJvcG9zYWwganVzdCByZXF1ZXN0cyBpbmdyZXNzDQogUEUgdG8gZmlsbCB0aGUgZmxv dyBlbnRyb3B5IGludG8gVURQIHNvdXJjZSBwb3J0LCBpbiB3aGljaCB0aGUgZmxvdyBjYW4gYmUg dW5pY2FzdCBvciBtdWx0aWNhc3QuDQo8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48 L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkx1 Y3k8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpTaGFocmFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPiBYdXhpYW9odSAmbHQ7eHV4aWFvaHVAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5Ubzo8L2I+ IFNoYWhyYW0gRGF2YXJpICZsdDtkYXZhcmlAYnJvYWRjb20uY29tJmd0OzsgTHVjeSB5b25nICZs dDtsdWN5LnlvbmdAaHVhd2VpLmNvbSZndDsNCjxicj4NCjxiPkNjOjwvYj4gJnF1b3Q7ZHJhZnQt eHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LXh1LW1wbHMtaW4t dWRwQHRvb2xzLmlldGYub3JnJmd0OzsgJnF1b3Q7bXBsc0BpZXRmLm9yZyZxdW90OyAmbHQ7bXBs c0BpZXRmLm9yZyZndDs7ICZxdW90O21wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJnF1b3Q7ICZs dDttcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgRGVjZW1iZXIgMjAsIDIwMTIgNTo1NjoyMyBQTTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29y azwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0t LS0tPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4t LS0tLTxicj4NCiZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1p bHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj46DQo8YSBocmVmPSJtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6 U2ltU3VuO2NvbG9yOmJsYWNrIj7ku6Pooag8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YnI+DQomZ3Q7IFNoYWhyYW0gRGF2YXJpPGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0i WkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkemAgeaXtumX tDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjIxPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4NCiAxOjMxPGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjogTHVjeSB5b25nPGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0i WkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaKhOmAgTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjoNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC14dS1t cGxzLWluLXVkcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LXh1LW1wbHMt aW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0 b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3Jn PC9hPjs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVyIG92 ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yazxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ug ZG9uJ3QgbWl4IHVwIHRoaW5ncy4gVGhlIE1QTFMgcHJvdG9jb2wgZGVzaWduIEkgYWdyZWUgbXVz dCBiZSBkb25lIGJ5PGJyPg0KJmd0OyBNUExTIFdHLiBCdXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRo ZXIgeW91ciBwcm9wb3NhbCBtZWV0cyB0aGUgbmV0d29yazxicj4NCiZndDsgdmlydHVhbGl6YXRp b24gcmVxdWlyZW1lbnRzLjxicj4NCjxicj4NCkNhbiB5b3UgdGVsbCB1cyB3aGVyZSBNUExTLWlu LUdSRS9JUCBbUkZDNDAyM10gYW5kIG90aGVyIE1QTFMgb3ZlciBJUCBlbmNhcHN1bGF0aW9uIG1l Y2hhbmlzbXMgaGF2ZSBiZWVuIGRpc2N1c3NlZCBiZWZvcmU/PGJyPg0KPGJyPg0KU2luY2UgTVBM Uy1pbi1VRFAgaXMganVzdCBpbnRlbmRlZCB0byBiZSB1c2VkIGluIHRoZSBzY2VuYXJpb3Mgd2hl cmUgTVBMUy1pbi1HUkUvSVAgaGFzIGJlZW4gdXNlZCBhbmQgaXMgdG8gYmUgdXNlZCwgTVBMUy1p bi1VRFAgc2hvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aGUgc2FtZSBXRyB3aGVyZSBNUExTLWluLUdS RS9JUCBoYXMgYmVlbiBkaXNjdXNzZWQuPGJyPg0KPGJyPg0KWGlhb2h1PGJyPg0KPGJyPg0KJmd0 OyBUaGUgTlZPMyB0YXNrIGlzIHRvIGRvY3VtZW50IHRoZSBpc3N1ZXMsIHJlcXVpcmVtZW50cyBh bmQgZnJhbWV3b3JrIGZvcjxicj4NCiZndDsgTnZPMy4gVGhlbiBpZiBNUExTIG92ZXIgSVAgbG9v a3MgbGlrZSBhIHN1aXRhYmxlIHNvbHV0aW9uIHRoYXQgbWVldHMgdGhlPGJyPg0KJmd0OyByZXF1 aXJlbWVudHMgc3VjaCBhcyB0aGUgc2NhbGUsIG1vYmlsaXR5LCBldGMsIHRoZW4gdGhleSB3aWxs IGFzayBNUExTIFdHIGZvcjxicj4NCiZndDsgcHJvdG9jb2wgZGVzaWduLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBTbyBiZWZvcmUgcHJvY2VlZGluZyB0aGlzIGRyYWZ0LCBJIHRoaW5rIHlvdSBzaG91 bGQgdGFrZSBpdCB0byBOVk8zIFdHIGFuZDxicj4NCiZndDsgY29udmluY2UgdGhlbSB0aGlzIHNv bHV0aW9uIG1lZXRzIHRoZWlyIHJlcXVpcmVtZW50cyBhbmQgZnJhbWV3b3JrLjxicj4NCiZndDsg PGJyPg0KJmd0OyBXZSBkb24ndCB3YW50IElFVEYgZG8gZGVzaWduIE4gbnVtYmVyIG9mIHNvbHV0 aW9ucyBmb3IgdGhlIHNhbWUgcHJvYmxlbSwgZG88YnI+DQomZ3Q7IHdlPzxicj4NCiZndDsgPGJy Pg0KJmd0OyAtU2hhaHJhbTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgUmVnYXJkcyw8YnI+DQomZ3Q7IFNoYWhyYW08YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyBPbiBEZWMgMjAsIDIwMTIsIGF0IDg6NTYgQU0sICZxdW90O0x1Y3kgeW9uZyZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyBOZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXJsYXkgaXMgZGlzY3Vzc2VkIHVuZGVyIG52 bzMgV0cuIFRoaXMgZG9lcyBub3Q8YnI+DQomZ3Q7IG1lYW4gdGhhdCBudm8zIFdHIGhhcyB0byBk ZXNpZ24gYSBuZXcgcHJvdG9jb2wgZm9yIGEgdW5kZXJseWluZyBuZXR3b3JrIG9yIGE8YnI+DQom Z3Q7IG5ldyBwcm90b2NvbCBmb3IgYSBvdmVybGF5IG5ldHdvcmsuIEluIGZhY3QsIHBlb3BsZSB0 aGVyZSBhaW0gb24gbGV2ZXJhZ2U8YnI+DQomZ3Q7IHN0YW5kYXJkIG5ldHdvcmsgcHJvdG9jb2xz IHRvIGFjY29tcGxpc2ggdGhlbS4gSU1POiB0aGVzZSBleHBhbnNpb25zIG9uIGFuPGJyPg0KJmd0 OyBleGlzdGluZyBzdGFuZGFyZCBwcm90b2NvbCBoYXZlIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhl IHByb3RvY29sIFdHIGdyb3VwLCBpdDxicj4NCiZndDsgc2hvdWxkIG5vdCBnaXZlIG52bzMgV0cg ZnJlZSByaWdodCB0byBlbmhhbmNlIHRoZXNlIHByb3RvY29scy4gRm9yIGEgYnJhbmQ8YnI+DQom Z3Q7IG5ldyBwcm90b2NvbCBmb3IgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVybGF5LCBudm8z IFdHIG1heSBiZSB0aGUgcGxhY2UgdG88YnI+DQomZ3Q7IHN0YXJ0Ljxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBMdWN5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsgRnJvbTogU2hhaHJhbSBE YXZhcmkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGF2YXJpQGJyb2FkY29tLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmRhdmFyaUBicm9hZGNvbS5jb208L2E+XTxicj4NCiZndDsgJmd0OyZndDsgU2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDIwLCAyMDEyIDEwOjM0IEFNPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBUbzogTHVjeSB5b25nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDYzogU2hhbmUgQW1hbnRlOyA8YSBo cmVmPSJtYWlsdG86ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHNAaWV0Zi5vcmc8 L2E+Ozxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW21wbHNdIE1QTFMgY2xpZW50IGxheWVy IG92ZXIgYW4gSUdQIHVuZGVybHlpbmcgbmV0d29yazxicj4NCiZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7IE5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlcmxheSBtdXN0IGJlIGRpc2N1 c3NlZCBhbmQgY29uc2VudGVkJm5ic3A7IGluIE5WTzM8YnI+DQomZ3Q7ICZndDsmZ3Q7IFdHLjxi cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBTaGFocmFtPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IE9uIERlYyAyMCwgMjAxMiwgYXQgNzozOSBBTSwgJnF1b3Q7THVjeSB5 b25nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iIHRhcmdl dD0iX2JsYW5rIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgdW5kZXJzdGFuZCBvcGVyYXRvciBjb25j ZXJuIG9uIGEgbmV3IGVuY2Fwc3VsYXRpb24gdG8gYW4gZXhpc3Rpbmc8YnI+DQomZ3Q7ICZndDsm Z3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBIb3dldmVyLCBNUExTLWluLVVEUCBkb2VzIG5vdCBhaW0gb24gY2hhbmdpbmcgZXhpc3Rpbmcg U1AgSVAvTVBMUzxicj4NCiZndDsgJmd0OyZndDsgbmV0d29yayBhdCBhbGwuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgTVBMUy1pbi1VRFAgaXMgdG8gZW5hYmxlIE1QTFMgY2xpZW50IGxheWVyIHRv IGJlIGRlY291cGxlZCBmcm9tIE1QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNlcnZlciBsYXllciBh bmQgdXNlIE1QTFMgY2xpZW50IGxheWVyIGFzIG92ZXJsYXkgbmV0d29yayBhbmQgYW4gSUdQIGFz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhIHVuZGVybHlpbmcgbmV0d29yayBmb3IgdHJhbnNwb3J0LiBT dWNoIGFwcGxpY2F0aW9uIGlzIGZvciBEQy4gWW91IG1heTxicj4NCiZndDsgJmd0OyZndDsgYXJn dWUgd2h5IG5vdCB1c2UgdGhlIEdSRSB3aGljaCBpcyBmb3IgTVBMUyBsYXllciBvdmVyIGFuIElH UCB1bmRlcmxpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IG5ldHdvcmsuIFdlIGhhdmUgcG9pbnRlZCBv dXQgaW4gdGhlIGRyYWZ0IHRoYXQgY3VycmVudCByb3V0ZXJzIGluIERDPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBiYXJlbHkgc3VwcG9ydCBHUkUgYmFzZWQgbG9hZCBiYWxhbmNpbmcgYW5kIE1QTFMtaW4t R1JFIGFyZSBiYXJlbHkgdXNlZDxicj4NCiZndDsgJmd0OyZndDsgaW4gU1AgbmV0d29ya3MgdG9v LiBNb3N0IG9mIHJvdXRlcnMgaW4gREMgcGVyZm9ybSB1cGQgcG9ydCBiYXNlZCBsb2FkPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBiYWxhbmNpbmcgbm93Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlLCB0aGUg VURQIGVuY2Fwc3VsYXRpb24gaGFzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhZHZhbnRhZ2Ugb3ZlciBH UkUgZW5jYXBzdWxhdGlvbiB0b28uIEluIFVEUCBlbmNhcHN1bGF0aW9uLCB0aGUgZnJhbWU8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGhlYWRlciBkZWNvdXBsZXMgdGhlIG92ZXJsYXkgYW5kIHVuZGVybHlp bmcgbmV0d29yayBjbGVhcmx5LCBpLmUuIG91dGVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoZWFkZXIg YW5kIG92ZXJsYXkgaGVhZGVyLiBVRFAgYmVsb25ncyB0byBvdXRlciBoZWFkZXIsIHdoaWNoPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyB1bmRlcmx5aW5nIG5ldHdvcmsgdXNlcyBvbmx5LiBIb3dldmVyLCBH UkUgaGVhZGVyIGhhcyB0aGUgZmllbGRzIGZvcjxicj4NCiZndDsgJmd0OyZndDsgdGhlIG92ZXJs YXkgbmV0d29yayBhbmQgdXNlcyB0aGUga2V5IGZpZWxkIGZvciBmbG93IGVudHJvcHkuIEZvciBs b2FkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBiYWxhbmNpbmcsIGl0IHJlcXVpcmVzIHRoZSB1bmRlcmx5 aW5nIG5ldHdvcmsgdXNlcyBHUkUgaGVhZGVyIHRvby4gSW48YnI+DQomZ3Q7ICZndDsmZ3Q7IHNo b3J0LCBHUkUgdGllcyB0aGUgb3ZlcmxheSBhbmQgdW5kZXJseWluZyBuZXR3b3JrcyB0b2dldGhl ci4gU2luY2UgaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGhhcyBub3QgdXNlZCBhIGxvdCwgcGVvcGxl IGFyZSBub3QgYXdhcmUgb2YgdGhlIGRpc2FkdmFudGFnZSBvZiBzdWNoPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBjb3VwbGluZy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IEFzIHRoZSBpbmR1c3RyeSBtb3ZlcyB0b3dhcmQgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBv dmVybGF5IGFuZDxicj4NCiZndDsgJmd0OyZndDsgZGVjb3VwbGVzIG92ZXJsYXkgbmV0d29ya3Mg ZnJvbSB0aGUgdW5kZXJseWluZyBuZXR3b3JrLiBBIGNsZWFyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBz ZXBhcmF0aW9uIG9mIG92ZXJsYXkgaGVhZGVyIGFuZCB1bmRlcmx5aW5nIGhlYWRlciBpcyBhICZx dW90O01VU1QmcXVvdDsgaW4gbXk8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9waW5pb24uIElmIHdlIGNv dW50IEdSRSBhcyB0aGUgb3ZlcmxheSBoZWFkZXIsIHRoZW4gZm9yIElQdjQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHVuZGVybHlpbmcgbmV0d29yaywgdGhlcmUgaXMgbm8gZmllbGQgZm9yIHRoZSBmbG93 IGVudHJvcHkuIFRoaXMgaXMgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyByZWFzb24gd2UgcHJvcG9z ZSB0aGUgVURQIGVuY2Fwc3VsYXRpb246IGZvciBhbiBJR1AgYmFzZWQgdW5kZXJseWluZzxicj4N CiZndDsgJmd0OyZndDsgbmV0d29yay4gSW4gZmFjdCwgaXQgY2FuIHN1cHBvcnQgYW55IG92ZXJs YXkgbmV0d29yayBiZXNpZGUgTVBMUyBjbGllbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IGxheWVyIChl LmcuIFZYTEFOLCBMMlRQLWluLVVEUCwgZXRjKS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IFlvdSBwb2ludCBvdXQgdXNpbmcgTVBMUy1pbi1MMlRQLWluLVVE UCBpbnN0ZWFkLiBZZXMsIE1QTFMtaW4tTDJUUC08YnI+DQomZ3Q7ICZndDsmZ3Q7IGluLVVEUCBz Y2hlbWEgYWxzbyBwcm92aWRlcyBhIG92ZXJsYXkgKEwyVFApIGFuZCB1bmRlcmx5aW5nIChJUCk8 YnI+DQomZ3Q7ICZndDsmZ3Q7IG5ldHdvcmsgZGVjb3VwbGluZy4gTDJUUCBwcm90b2NvbCAocmZj MzkzMSkgcHJvdmlkZXMgZ29vZCBzZWN1cml0eTxicj4NCiZndDsgJmd0OyZndDsgbWVjaGFuaXNt IGFuZCBoYXMgdGhlIGVtYmVkZGVkIGNvbnRyb2wgZnVuY3Rpb24gdG9vLiBUaGVyZWZvcmUsPGJy Pg0KJmd0OyBzb21lb25lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjYW4gdXNlIGl0IGZvciBNUExTIGNs aWVudCBsYXllciBvdmVyIEludGVybmV0LiBUbyBoYXZlIE1QTFMgY2xpZW50PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBsYXllciBvdmVyIGFuIElHUCB1bmRlcmxpbmcgbmV0d29yaywgSU1POiBNUExTLWlu LUwyVFAtaW4tVURQIGlzIGE8YnI+DQomZ3Q7ICZndDsmZ3Q7IG92ZXJraWxsIGFuZCB0b28gY29t cGxleC4gSGVyZSB3ZSBuZWVkIGEgc2NoZW1hIHRvIHN1cHBvcnQgSUdQPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyB1bmRlcmx5aW5nIHRyYW5zcG9ydCB3aXRob3V0IHRvdWNoaW5nIGEgb3ZlcmxheSBoZWFk ZXIuIFVEUDxicj4NCiZndDsgJmd0OyZndDsgZW5jYXBzdWxhdGlvbiBpcyB0aGUgYmVzdCBjaG9p Y2UgdG8gYWNjb21wbGlzaCB0aGF0IGFuZCBtaW5pbWl6ZSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7 IGNoYW5nZXMgb24gZXhpc3Rpbmcgcm91dGVycywgZS5nLiBjaGFuZ2UgYXQgZWRnZSByb3V0ZXJz LCBubyBjaGFuZ2Ugb248YnI+DQomZ3Q7ICZndDsmZ3Q7IHRyYW5zaXQgcm91dGVycy48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgTHVjeTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBG cm9tOiBYdXhpYW9odSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29t IiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyMCwgMjAxMiA0OjE0IEFNPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBTaGFuZSBBbWFudGU8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgQ2M6IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7IGRyYWZ0LXh1LW1w bHMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86dWRwQHRvb2xzLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dWRwQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzwv YT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogRGlzY3Vzc2lvbiBvbiBob3cg dG8gdHJhbnNwb3J0IE1QTFMgb3ZlciBVRFAgdHVubmVsczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBIaSBTaGFuZSw8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB5b3VyIGZ1 cnRoZXIgY29tbWVudHMgYW5kIHBsZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW5saW5lLjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBOb3RlOiBJIGNo YW5nZWQgdGhlIHN1YmplY3QgbGluZSBhY2NvcmRpbmcgdG8gTG9hJ3Mgc3VnZ2VzdGlvbi48YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0t LS0tPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7pgq7ku7bljp/ku7Y8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4t LS0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7lj5Hku7bkuro8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFNoYW5lIEFtYW50ZSBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQiIHRhcmdldD0iX2JsYW5rIj5zaGFuZUBj YXN0bGVwb2ludC5uZXQ8L2E+XTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFu PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7lj5HpgIHml7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IDIwMTI8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjEyPC9zcGFuPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mnIg8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xOTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5pelPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+DQogMjI6Mzg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pS25Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiBYdXhp YW9odTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFJvZ2VycywgSm9zaDsgU2hhaHJhbSBEYXZhcmk7 IGRyYWZ0LXh1LW1wbHMtaW4tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1h aWx0bzp1ZHBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51ZHBAdG9vbHMuaWV0Zi5v cmc8L2E+Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1w bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxz LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5Li76aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+OiBSZTogW21w bHNdIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgc3VwcG9ydCB0byBtYWtlIGRyYWZ0LXh1LTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBtcGxzLWluLXVkcCBhbjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgbXBscyB3b3JraW5nIGdyb3VwIGRvY3VtZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWGlhb2h1LDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIERlYyAxOCwgMjAxMiwgYXQgMTE6NTAgUE0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWls dG86eHV4aWFvaHVAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5j b208L2E+Jmd0Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyAtLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1 bjtjb2xvcjpibGFjayI+6YKu5Lu25Y6f5Lu2PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+LS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7l j5Hku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFNoYW5lIEFtYW50ZSBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzaGFuZUBjYXN0bGVwb2ludC5uZXQiIHRhcmdldD0iX2Js YW5rIj5zaGFuZUBjYXN0bGVwb2ludC5uZXQ8L2E+XTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWls eTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFt aWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47 Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjE5PC9zcGFu PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCiAxMTo1ODxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaUtuS7tuS6ujwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjogUm9nZXJzLCBKb3NoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+OiBTaGFocmFtIERhdmFyaTsgWHV4aWFvaHU7IGRyYWZ0LXh1LW1wbHMtaW4tPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzp1ZHBAdG9vbHMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj51ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHMtY2hhaXJzQHRvb2xz LmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPuS4u+mimDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogUmU6IFttcGxzXSBw b2xsIHRvIHNlZSBpZiB3ZSBoYXZlIHN1cHBvcnQgdG8gbWFrZSBkcmFmdC14dS08YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgbXBscy1pbi11ZHA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgd29ya2lu ZyBncm91cCBkb2N1bWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTgsIDIwMTIsIGF0IDg6NTAgQU0sICZxdW90O1Jv Z2VycywgSm9zaCZxdW90Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpvc2gucm9nZXJzQHR3Y2FibGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9zaC5yb2dl cnNAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkg c2hhcmUgeW91ciBTUCBwZXJzcGVjdGl2ZSwgYW5kIGRvIG5vdCBzZWUgdGhlIHByb2JsZW0gdGhp czxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzb2x1dGlvbjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWRkcmVzc2VzIGluIHByYWN0aWNlIGFueSBsb25nZXIu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICYjNDM7MS4mbmJzcDsgUGxlYXNlIGRvIG5vdCBkZWZpbmUg eWV0IGFub3RoZXIgTVBMUy1vdmVyLUlQIGVuY2Fwc3VsYXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IFRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSUVURjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbHJlYWR5IHN0YW5kYXJkaXplZCBNUExT IG92ZXIgR1JFLiZuYnNwOyBUaGUgSUVURiBoYXMgYWxzbzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBzdGFuZGFyZGl6ZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1QTFM8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3ZlciBMMlRQdjMvVURQL0lQLCB3 aGljaCBoYWQgc2VlbiBzb21lIGRlcGxveW1lbnQgaW4gYXQgbGVhc3Q8YnI+DQomZ3Q7ICZndDsm Z3Q7IG9uZSw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdmVyeTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYXJnZSBvcGVyYXRvciBuZXR3b3JrIHRoYXQgSSdtIGF3 YXJlIG9mIHRvIHN1cHBvcnQgY2FycmlhZ2Ugb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg TDNWUE4gb3Zlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSVAtb25seSBuZXR3b3JrLjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg SGkgU2hhbmUsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIHRlbGxpbmcgdXMgdGhlcmUgYXJl IGFjdHVhbCBkZXBsb3ltZW50cyBvZiBNUExTIG92ZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgSVAgaW4gYXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXN0IG9uZSwgdmVy eSBsYXJnZSBvcGVyYXRvciBuZXR3b3JrLiBUaGlzIGZhY3QgbXVzdCBiZSB2ZXJ5PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVhYmxlIHRvIHRob3NlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBwZW9wbGUgd2hvIGhhZCBiZWxpZXZlZCB0aGVyZSBpcyBubyBhcHBsaWNhdGlv biBvZiBNUExTIG92ZXIgSVAgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdG9kYXkncyBT UDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV0d29ya3MuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgU2VlOiBSRkMncyA0NDU0LCA0NzE5LCA0NTkxLCA0MzQ5IGZvciBQV0UzIG92ZXIgTDJUUHYz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtOT1RFOiB0aGUgZGF0ZXMg dGhlIGFib3ZlIHdlcmUgcHVibGlzaGVkIHdhcyBiYWNrIGluIHRoZSAyMDA2PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aW1lZnJhbWUhXTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyBSRkMgNDY2NSBmb3IgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g VlBMUyB0aGF0IHNheSB0aGF0IFZQTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbWF5IGJl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhcnJpZWQgb3ZlciBMMlRQ djM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgQW5kLCBoZXJl J3MgZXZpZGVuY2Ugc2hvd2luZyB0aGF0IGF0IGxlYXN0IG9uZSB2ZW5kb3IgaGFzPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJUFZQTidzIG92ZXIgTDJUUHYzOjxicj4NCiZndDsgJmd0OyZndDsg PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vZW4vVVMvZG9jcy9pb3MvMTJfMHMvZmVhdHVy ZS9ndWlkZS9jc2dsM3Zwbi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmNpc2Nv LmNvbS9lbi9VUy9kb2NzL2lvcy8xMl8wcy9mZWF0dXJlL2d1aWRlL2NzZ2wzdnBuLmh0bWwgPC9h Pjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGFnYWluIGZvciBzaGFyaW5nIHRoZSBhYm92ZSBpbmZvcm1h dGlvbi4gQXMgbWVudGlvbmVkIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMgZHJh ZnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFORCBvdGhlciBkcmFmdHMsIHRoZSBt ZWNoYW5pc20gb2YgcGVyZm9ybWluZyBoYXNoIGNhbGN1bGF0aW9uIG9uPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2Vzc2lvbjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgSUQgZmllbGQgaW4gdGhlIEwyVFB2MyBoZWFkZXIgb3IgdGhlIEtl eSBmaWVsZCBpbiB0aGUgR1JFIGhlYWRlciBhczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBk ZWZpbmVkIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbUkZDIDU2NDBdIGlzIG5v dCB3aWRlbHkgc3VwcG9ydGVkIGJ5IGV4aXN0aW5nIGNvcmUgcm91dGVycyBzbyBmYXIuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg RldJVywgSSBoYXZlIGhhZCBzdWNjZXNzLCBpbiB0aGUgcmVsYXRpdmVseSByZWNlbnQgcGFzdCwg aW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVxdWVzdGluZyBhIGNvcmU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJvdXRlciB2ZW5kb3IgdG8gc3VwcG9ydCBjaGFuZ2VzIHRv IHRoZSBpbnB1dC1rZXlzIHVzZWQgaW4gaGFzaDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBj YWxjdWxhdGlvbnMgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9leGlzdGluZ18g aGFyZHdhcmUsIGFscmVhZHkgZGVwbG95ZWQgKGV4dGVuc2l2ZWx5KSB0aHJvdWdob3V0IG15PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG5ldHdvcmsuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBGdXJ0aGVyLCBJIHN1c3BlY3QgdGhhdCBtb3N0IGxhcmdlIG5ldHdvcmsgb3BlcmF0 b3JzIGFyZSBzYXZ2eTxicj4NCiZndDsgJmd0OyZndDsgZm9sa3M8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB1bmRlcnN0YW5kIHRo ZSBpbnRlcm5hbCBhcmNoaXRlY3R1cmUgb2YgdGhlaXIgSFcgZmFpcmx5IHdlbGwuJm5ic3A7IEFz IGE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgcmVzdWx0LCB0aG9zZTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgc2FtZSBvcGVyYXRvcnMga25vdyB3aGF0IGlzIGFuZCBpcyBub3Qg dGVjaG5pY2FsbHkgcG9zc2libGUgaW4gdGhpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBy ZWdhcmQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaHVzLCBpdCBtYXkgYmUgYSBx dWVzdGlvbiBvZiAmcXVvdDttZXRob2RzJnF1b3Q7IG5lY2Vzc2FyeSB0byBjb252aW5jZSB0aGVp cjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBIVzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc3VwcGxpZXIocykgdG8gbWFrZSBhcHByb3ByaWF0ZSBjaGFuZ2VzIGluIHRoZWlyIGVx dWlwbWVudCB0bzxicj4NCiZndDsgJmd0OyZndDsgYWNoaWV2ZTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyB0aGVpcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnVzaW5lc3MgZ29h bHMuJm5ic3A7IDotKSZuYnNwOyBIb3dldmVyLCB0aGlzIG1heSBub3QgZXZlbiBiZSBuZWNlc3Nh cnkgLi4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzZWU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg YmVsb3cuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IENvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBleHBsYWluIGhvdyB0byBtYWtlIHRoZSBhYm92 ZSBjaGFuZ2UgaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRVhJU1RJTkcgaGFyZHdhcmUg b2YgYWxyZWFkeSBkZXBsb3llZCBjb3JlIHJvdXRlcnM/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gY29udHJhc3QsIG1vc3Qg ZXhpc3RpbmcgY29yZSByb3V0ZXJzIGFyZSBhbHJlYWR5IGNhcGFibGUgb2Y8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgYmFsYW5jaW5nIElQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0cmFmZmljIGZsb3dzIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxlIG9mIFVE UCBwYWNrZXRzLjxicj4NCiZndDsgJmd0OyZndDsgQnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgdXNpbmcgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNUExTLWluLVVEUCBl bmNhcHN1bGF0aW9uLCB0aGUgYWxyZWFkeSBhdmFpbGFibGUgbG9hZC1iYWxhbmNpbmc8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2FwYWJpbGl0eSBvZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgbW9zdCBleGlzdGluZyBjb3JlIHJvdXRlcnMgY2FuIGJlIGxldmVyYWdlZCB3aXRo b3V0IHJlcXVpcmluZyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2hhbmdlIHRvPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGVtLiBUaGF0IGlzIHRoZSBtYWpvciBtb3Rp dmF0aW9uIG9mIHRoaXMgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhpcyBpcyBhIGNvbmNlcm4sIHRoZW4gd2h5 IG5vdCBlbmNhcHN1bGF0ZSB0aGUgdHJhZmZpYyBpbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBNUExTL0wyVFB2Mywgd2hpY2g8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVzZXMg VURQL0lQLCBpbiB0aGUgZmlyc3QgcGxhY2U/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElmIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHlv dSBwcmVmZXIgdG8gdXNlIE1QTFMtaW4tTDJUUHYzLWluLTxicj4NCiZndDsgJmd0OyZndDsgVURQ PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RlYWQgb2YgTVBMUy1pbi1VRFAsIHJpZ2h0 Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSU1ITywgYSBiZXR0ZXIgcHJvcG9zYWwgbWF5IGJlIHRvIGNvbnNpZGVyIGEgW21pbm9yXSAo PykgY2hhbmdlIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFJGQyAzOTMxLDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hpY2ggd291bGQgYWxsb3cgdGhlIGNvbm5lY3Rpb24g dXNlZCBmb3IgZGF0YSBwYWNrZXRzIChub3QgY29udHJvbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBwYWNrZXRzKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gdXNlIGEgdmFy eWluZyBzZXQgb2Ygc291cmNlIHBvcnRzIChvciwgc291cmNlIElQIGFkZHJlc3NlcyksPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBiYXNlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBvbiBhIGhhc2g8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhbGN1bGF0aW9uLCB0byBhY2hpZXZlIGJl dHRlciBsb2FkLWJhbGFuY2luZyBvdmVyIGV4aXN0aW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlcXVp cG1lbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgaW4gYW48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IElQLW9ubHkgY29yZS4mbmJzcDsgTDJUUCBlbmQtc3lzdGVtIGltcGxlbWVu dGF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIgb2ZmPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGp1 c3QgdXNpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSAmcXVvdDtTZXNzaW9u IElEJnF1b3Q7IChhbmQgJnF1b3Q7Q29va2llJnF1b3Q7KSBmaWVsZHMgYXMgdGhlIGRlbXVsdGlw bGV4b3IgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRlPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmNvbWluZyBwYWNrZXRzIHdpdGggdGhlIGFzc29jaWF0ZWQg TDJUUCBDb250cm9sIENoYW5uZWwuJm5ic3A7IEluIGZhY3QsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGl0J3Mgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjbGVhciB0byBt ZSB0aGF0IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBtYXkgL2FscmVhZHkvIGRvIHRoaXMsPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG1ha2luZyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZxdW90O2NoZWNrJnF1b3Q7IG9uIHRoZSBpbmNvbWluZyBzb3VyY2UgcG9ydCB1 bm5lY2Vzc2FyeSBmb3IgTDJUUCBlbmQtc3lzdGVtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGJlYXV0eSBvZiB0aGUgYWJvdmUgYXBwcm9h Y2ggaXM6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxKSBJIHdvdWxkIHRoaW5rIHRo YXQgdGhlIGFib3ZlIGlzIG1vc3QgbGlrZWx5IGEgY2hhbmdlIHRoYXQgaXM8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgbGltaXRlZCB0byB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZxdW90O2NvbnRyb2wgY2hhbm5lbCZxdW90OyAoc29mdHdhcmUpIG9mIGV4aXN0aW5nIEwy VFAgZW5kLXN5c3RlbTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbnMu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIZWNrLCBpdCBtYXkgZXZlbiBiZSBiYWNr d2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIEwyVFB2Mzxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb25zLiZuYnNwOyAoTDJUUHYzIGltcGxlbWVudG9ycyB3 b3VsZCBuZWVkIHRvIGNvbW1lbnQgb248YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoYXQpLjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJTUhPLCBubyBt YXR0ZXIgTVBMUy1pbi1MMlRQdjMtaW4tVURQIG9yIE1QTFMtaW4tVURQLCZuYnNwOyB0aGUgaGFy ZHdhcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFBF IHJvdXRlcnMgbmVlZHMgdG8gYmUgdXBncmFkZWQsIGUuZy4sIGluZ3Jlc3MgUEUgcm91dGVycyBu ZWVkIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmaWxsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGluIGFuIGVudHJvcHkgdmFsdWUgaW4gdGhlIHNvdXJjZSBwb3J0IGZpZWxkIG9mIFVEUCBoZWFk ZXJzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgMikgVGhlcmUgaXMgYSBzdWJzdGFudGlhbCBhZGRlZCBzZWN1cml0eSBvbmUgZ2V0cyBi eSB1c2luZyAmcXVvdDtTZXNzaW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElEJnF1b3Q7 IGFuZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7Q29va2llJnF1b3Q7IGZp ZWxkcyB0byBlbnN1cmUgdGhlIHJlY2VpdmVkIEwyVFB2MyBwYWNrZXQgaXMgaW50ZW5kZWQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGU8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlkZW50aWZpZWQgc2Vzc2lvbi4mbmJzcDsgUXVvdGlu ZyBmcm9tIFNlY3Rpb24gOC4yIG9mIFJGQyAzOTMxOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgLS0tc25pcC0tLTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgTDJU UHYzIHByb3ZpZGVzIHRyYWZmaWMgc2VwYXJhdGlvbiBmb3IgaXRzIFZQTnMgdmlhIGEgMzItYml0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFNlc3Npb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IElEIGluIHRoZSBMMlRQdjMgZGF0YSBoZWFkZXIuJm5ic3A7IFdoZW4g cHJlc2VudCwgdGhlIEwyVFB2MyBDb29raWU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7IChkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEpLCBwcm92aWRlcyBhbiBhZGRpdGlvbmFs IGNoZWNrIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBlbnN1cmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7IHRoYXQgYW4gYXJyaXZpbmcgcGFja2V0IGlzIGludGVuZGVkIGZvciB0 aGUgaWRlbnRpZmllZCBzZXNzaW9uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsgVGh1cywgdXNlIG9mIGEgQ29va2llIHdpdGggdGhlIFNlc3Npb24gSUQgcHJvdmlkZXMgYW4g ZXh0cmE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgZ3VhcmFudGVlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyB0aGF0IHRoZSBTZXNzaW9uIElEIGxvb2t1cCB3YXMgcGVy Zm9ybWVkIHByb3Blcmx5IGFuZCB0aGF0IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsgU2Vzc2lvbiBJRCBpdHNlbGYgd2FzIG5vdCBjb3JydXB0ZWQgaW4gdHJhbnNpdC48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLXNuaXAtLS08YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IC4uLiBpbiByZWdhcmQgdG8gdGhpcyBxdWVzdGlvbiBhbG9uZSwgSSBr bm93IHRoZSBTZWN1cml0eSBBcmVhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmb2xrczxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBoYXZlLCBpbiB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHBhc3QsIGhhZCAvc3Vic3RhbnRpYWwvIGNvbmNlcm5zIGFib3V0IGVuY2Fwc3VsYXRpb24g b2YgTVBMUyBvdmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBJUDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyB0cmFuc3BvcnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBmYWN0LCB0 aGlzIGlzIHdoeSB5b3Ugc2VlIHRleHQgaW4gU2VjdGlvbiA3LjYsICZxdW90O1NlY3VyaXR5JnF1 b3Q7LCBvZjxicj4NCiZndDsgJmd0OyZndDsgUkZDPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IDQ2NjUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoVGhlcmUncyBsaWtlbHkgc2lt aWxhciBsYW5ndWFnZSBpbiBvdGhlciBkcmFmdHMgdGhhdCB1c2UgTVBMUyBmb3I8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0KS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFdoaWxlIEknbSBub3Qgc3VyZSB0aGF0IFNlY3VyaXR5IEFyZWEgZm9sa3MgcGF5IG11Y2gg YXR0ZW50aW9uIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRhaWx5IHRyYWZmaWMgb248 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBNUExTIFdHIG1haWxpbmcgbGlzdCwg SSdtIGZhaXJseSBjb25maWRlbnQgdGhpcyBjb25jZXJuIHdpbGw8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsgYXJpc2UgaWYvd2hlbiB0aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBkcmFmdCBnb2VzIHRvIHRoZSBJRVNHIC4uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0 aGUgcmVhc29uIGZvciB5b3VyIHByZWZlcmVuY2Ugb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7IE1QTFMt PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGluLUwyVFB2My1pbi1VRFAgaXMgdGhhdCBpdCBo YXMgYW4gYWRkZWQgc2VjdXJpdHkgZmVhdHVyZS4gSWYgdGhhdDxicj4NCiZndDsgJmd0OyZndDsg aXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc28gY29uY2VybmVkLCBjYW4geW91IGV4cGxh aW4gd2h5IE1QTFMtaW4tR1JFIGlzIGZhciBtb3JlIHBvcHVsYXI8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHRoYW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgTVBMUy1pbi1MMlRQIGluIHByYWN0aWNl Pzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBC ZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMykgRmluYWxs eSwgdGhpcyBhcHByb2FjaCBvbmx5IGFmZmVjdHMgdGhlIGVuZC1zeXN0ZW1zIHRoYXQ8YnI+DQom Z3Q7ICZndDsmZ3Q7IGltcGxlbWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBMMlRQLCBm b3I8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHR1bm5lbGluZyBvZiBNUExTL0lQLCBh bmQgZG9lcyBub3QgcmVxdWlyZSBhbiBlbnRpcmUgaW5kdXN0cnkgdG88YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgc3VwcG9ydDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTVBMUy9V RFAgZW5jYXBzdWxhdGlvbiBpbiB0aGVpciBwcm9kdWN0IGxpbmVzLjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC1zaGFuZTxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWGlhb2h1PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSWYgdGhlcmUgd2FzIG1hcmtldCBkZW1hbmQg Zm9yIE1QTFMgb3ZlciBJUCwgdGhlbiBjbGVhcmx5IGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3b3Vs ZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBoYXZlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBiZWVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vcmUg d2lkZWx5IGltcGxlbWVudGVkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLCB3aXRoIGVpdGhlciBNUExT PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IG92ZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEdSRSBvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNUExT IG92ZXIgTDJUUHYzLiZuYnNwOyAoV2hlcmUgdGhlcmUncyBhIHdpbGwsIHRoZXJlJ3MgYSB3YXkp LiZuYnNwOyBJPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3b3VsZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBub3RlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBtb3N0IGxpa2VseSByZWFzb25zIHRoaXMg ZGlkIG5vdCBwYW4gb3V0IHdhcyB0aGVyZSBhcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNldmVyYWws PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByYWN0aWNhbDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvcGVyYXRpb25hbCBiZW5lZml0cyBvbmUgZ2V0cyBmcm9tIGdv aW5nIHdpdGggbmF0aXZlIE1QTFM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcgd2l0aGluIHRoZSBkYXRhIHBsYW5lLCBuYW1lbHk6 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gTVBMUyBGYXN0IFJlLVJv dXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gTVBMUyBUcmFmZmlj IEVuZ2luZWVyaW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC4uLiB0 byBuYW1lLCBidXQgYSBmZXcuJm5ic3A7IFRob3NlIGhhdmUgdGVuZGVkIHRvIGJlIHF1aXRlIGNv bXBlbGxpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZ3VtZW50czxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0byAndXBncmFkZScgbmV0d29yayBIVyB0 byBzdXBwb3J0IE1QTFMgZW5jYXBzdWxhdGlvbi9zd2l0Y2hpbmcuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IC1zaGFuZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLUpvc2g8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gMTIvMTgvMTIgMTI6MzEg QU0sICZxdW90O1NoYWhyYW0gRGF2YXJpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2YXJp QGJyb2FkY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmFyaUBicm9hZGNvbS5jb208L2E+Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZvciBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgTVBMUyBvdmVyIElQ IGlzIGxlZ2FjeSBhbmQgdGhlcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGlzPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IG5vIG5lZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyB0byBpbXByb3ZlIGl0Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBTaGFocmFtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIERlYyAxNywgMjAxMiwg YXQgODowMiBQTSwgJnF1b3Q7WHV4aWFvaHUmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhp YW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaGFocmFtLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGRyYWZ0IGlzIE9OTFkgaW50ZW5kZWQgdG8gcHJv dmlkZSBhIE1QTFMtb3Zlci1JUDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBlbmNhcHN1bGF0 aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1l dGhvZCB3aXRoIGEgYmV0dGVyIGxvYWQtYmFsYW5jaW5nIGFwcGxpY2FiaWxpdHkgc28gZmFyIHRv PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRob3NlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9wZXJhdG9ycyB3aG8gaGFwcGVuIHRvIHJlcXVp cmUgdHJhbnNwb3J0aW5nIE1QTFMgYXBwbGljYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgdHJhZmZpYzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhY3Jvc3MgSVAgbmV0d29ya3MuIEkgYmVsaWV2ZSBNUExTLWJhc2VkIFZQTiBvdmVyIElQ LCBOVkdSRTxicj4NCiZndDsgJmd0OyZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBWWExBTjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBlYWNoIGhhdmUgdGhlaXIgb3duIGFkdm9jYXRvcnMgYW5kIHVzZSBjYXNlcy4gSWYgeW91 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhYnNvbHV0ZWx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGJlbGlldmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaXQncyBtZWFuaW5nbGVzcyBvZiB0cmFuc3BvcnRpbmcgTVBMUyBhcHBsaWNhdGlvbiB0cmFm ZmljPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFjcm9zcyBJUDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXR3b3JrcyBhbmQgdGhlcmVmb3Jl IHRob3NlIGV4aXN0aW5nIFJGQ3MgcmVsYXRlZCB0byBNUExTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBv dmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElQPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHR1bm5lbGluZyBtZWNoYW5pc21zIHNob3VsZCBi ZSBtb3ZlZCB0byBIaXN0b3JpYyBzdGF0dXMsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBwbGVhc2U8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgc2F5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzby48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnkgdGhl IHdheSwgaXQgc2VlbXMgdGhpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCjwvYT48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsgYXJjaGl2ZS93ZWIvbnZvMy9jdXJyZW50L21zZzAxODY0Lmh0bWwpIGlzPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGp1c3QgdGhl IHJpZ2h0IHRocmVhZCBzdWl0YWJsZSBmb3IgeW91IHRvIG1ha2UgdGhlIGZvbGxvd2luZzxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcmd1bWVudDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoaS5lLiwgd2hldGhlciBvciBub3QgTVBMUy1iYXNl ZCBWUE4gaXMgYXBwbGljYWJsZSB0byBkYXRhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNl bnRlcnMpLiBJPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGhhZCB0aG91Z2h0IHlvdSB3b3VsZCBzcGVhayB1cCBhdCB0aGF0IHRpbWUuIFNhZGx5LDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzdXJwcmlzaW5nbHkgc2lsZW50PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRpbGwgbm93Ljxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaWdoLCBJIGRpZG4ndCBpbnRl bmQgdG8gc2F5IHRoZSBhYm92ZSBvdGhlcndpc2UuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFhpYW9odTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS08L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPumCruS7tuWOn+S7tjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPi0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkeS7tuS6ujwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjoNCjxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0i WkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuS7ozwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6Ymxh Y2siPuihqDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRGF2YXJpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjogMjAxMjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+MTI8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250 LWZhbWlseTpTaW1TdW47Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjE1PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCiAx MzozNDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IExv YSBBbmRlcnNzb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNp bVN1bjtjb2xvcjpibGFjayI+5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Og0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LXh1LW1wbHMtaW4tdWRwQHRvb2xzLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+ZHJhZnQteHUtbXBscy1pbi11ZHBAdG9vbHMuaWV0Zi5vcmc8L2E+Ow0K PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYu b3JnPC9hPjs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPC9zcGFuPjxzcGFuIGxhbmc9 IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7kuLvpopg8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj46IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYg d2UgaGF2ZSBzdXBwb3J0IHRvIG1ha2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LXh1LW1wbHMtaW4tdWRwIGFuPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtcGxzIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBJIGRvbid0IHN1cHBvcnQgdGhpcyBkcmFmdCBzaW5jZSBpdCBoYXMgbm8gYXBw bGljYXRpb24gaW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdG9kYXknczxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kZXJuIG1ldHJv PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh bmQgY29yZSwgd2hlcmUgTVBMUyBpcyBkb21pbmFudCwgYW5kIGl0cyBvbmx5IHByYWN0aWNhbDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBhcHBsaWNhdGlvbjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gaW4gZGF0YTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2VudGVyLCB3aGlj aCBhbHJlYWR5IGlzIGNyb3dkZWQgd2l0aCBvdGhlciBzb2x1dGlvbnMgc3VjaCBhczxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBOVkdSRTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg YW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBWWExBTi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBJdCBzZWVtcyB0aGUgYXV0aG9ycyBhcmUgdHJ5aW5nIHRvIGJ5cGFzcyB0aGUgTlZPMyBz b2x1dGlvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzZWxlY3Rpb248YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb2Nlc3M8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ5IGFkdmFu Y2luZyB0aGUgZHJhZnQgaW4gTVBMUyBXRy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2hhaHJhbTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBEZWMgMTQsIDIwMTIsIGF0IDE6MDEg QU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0i X2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV29ya2luZyBncm91cCw8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoaXMg aXMgdG8gc3RhcnQgYSAmcXVvdDt0d28gd2VlayZxdW90OyBwb2xsIG9uIGFkb3B0aW5nPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJh ZnQteHUtbXBscy1pbi11ZHAtMDYgYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IER1ZSB0byB0aGUgaG9saWRheSBzZWFzb24gdGhpcyBwb2xsIGhhcyBiZWVuIGV4dGVuZGVkIHdp dGg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb25lIHdlZWsuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBsczxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29ya2luZzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGdyb3VwIG1haWxpbmcgbGlzdCAobXBscyBh dCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGFuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRl Y2huaWNhbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG1vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNp YWxseSBpZiB5b3U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhpbmsgdGhhdDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBk b2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvY3VtZW50Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBwb2xsIGVuZHMgSmFudWFyeSAw NywgMjAxMy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIG9uZSBJUFIgY2xhaW0gYWdhaW5zdCB0aGlzIGRvY3VtZW50 IC08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xOTQxLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzE5NDEvPC9hPiAu PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBBbGwgdGhlIGFjdGl2ZSBjby1hdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcg Z3JvdXA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB0aGV5 IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiBjbGFpbXMgdGhhbiB0aG9zZTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyBhbHJlYWR5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzY2xvc2VkLjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgdXAg dG8gdmVyc2lvbiAtMDMgKHRoZSBkb2N1bWVudCB0aGF0IHdlIHVzZWQgZm9yPGJyPg0KJmd0OyAm Z3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSVBSPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcG9sbCk8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJz aGFsbCBFdWJhbmtzIHdhcyBsaXN0ZWQgYXMgb25lIG9mIHRoZSBhdXRob3JzLiBNYXJzaGFsbDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBoYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaXNjb250aW51ZWQgYWxsIGludGVyYWN0 aW9ucyB3aXRoIHRoZSBJRVRGLCBpbmNsdWRpbmcgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGF1dGhvciB0ZWFtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgb2YgZHJhZnQteHUtbXBscy1pbi11ZHAtMDYuIFRoZSB3b3JraW5n IGdyb3VwIGNoYWlycyBoYXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdHJpZWQgdG88YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBj b250YWN0IE1hcnNoYWxsIGJ5IG90aGVyIG1lYW5zLCB0byB0cnkgZ2V0IGEgcmVzcG9uc2Ugb248 YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJUFI8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBw b2xsLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFdlIGhhdmUgaGFkIG5vIHN1Y2Nlc3MgaW4gdGhpcy48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb20gdmVyc2lvbiAt MDQgdGhlIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgTWFyc2hhbGwgYXMgYTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvLWF1dGhv ci48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IC9Mb2E8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAobXBscyB3ZyBjby1jaGFpcik8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBMb2EgQW5kZXJzc29u Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bG9hLmFuZGVy c3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5sb2EuYW5kZXJzc29uQGVyaWNzc29u LmNvbTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXImbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0 YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRXJpY3Nzb24gSW5jJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBob25lOiAmIzQzOzQ2IDEwIDcxNzxicj4NCiZndDsgNTI8 YnI+DQomZ3Q7ICZndDsmZ3Q7IDEzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7NDYg NzY3IDcyIDkyPGJyPg0KJmd0OyAxMzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bXBs c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBscyA8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMgPC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXBscyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgPC9hPjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBU aW1lIFdhcm5lcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDYWJsZTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyBzdWJqZWN0IHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbGVseSBmb3I8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSBub3QgdGhlPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3NlbWluYXRpb24s PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3RyaWJ1dGlvbiwgY29w eWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZTxicj4NCiZndDsgJmd0OyZn dDsgY29udGVudHM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgb2YgYW5kPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyB1bmxhd2Z1bC4gSWYgeW91PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpbW1lZGlhdGVseSBhbmQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmln aW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IGFueSBwcmludG91dC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtcGxzIG1haWxpbmcgbGlz dDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo8L2E+PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IG1wbHMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cw0KPC9hPjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IG1wbHMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCjwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2691CE0099834E4A9C5044EEC662BB9D448651CAdfweml505mbx_--
Carlos,

On Sun= , Dec 16, 2012 at 11:16 AM, Carlos Pignataro (cpignata) &= lt;cpignata@cisco.c= om> wrote:
2.3.1.  Pseudowire Control Word

   Within the core of a network some form of multipath is almost certain
   to be used.  Multipath techniques deployed today are likely to be
   looking beneath the label stack for an opportunity to hash on IP
   addresses.

   A pseudowire encapsulated at a network edge must have a means to
   prevent reordering within the core if the pseudowire will be crossing
   a network core, or any part of a network topology where multipath is
   used.

   Not supporting the ability to encapsulate a pseudowire with a control
   word may lock a product out from consideration.  A pseudowire
   capability without control word support might be sufficient for
   applications which are strictly both intra-metro and low bandwidth.
   However a provider with other applications will very likely not
   tolerate having equipment which can only support a subset of their
   pseudowire needs.

While I agree with this text, I wonder if it is attempting to set up a= new requirement. For example, although not 2119-capitalized, "A pseud= owire encapsulated at a network edge must have a means to=A0prevent reorder= ing within the core". PWE3 has been discussing this topic, but today's specs include PW Types for which a CW is optio= nal. Similarly, recommendations are already at this=A0http://tools.ietf.org/= html/bcp128#section-3
=A0
.

I don't think this is a new requireme= nt at all, it's consistent with the "avoiding ECMP" section (= section 2) of RFC 4385. Perhaps just a reference to 4385 should be added he= re.

Cheers,
Andy